Orthanc бесплатный DICOM / PACS сервер для Windows и Linux
На днях закончил внедрение DICOM / PACS-сервера в одном Московском медицинском центре, эта задача для меня была совершенно новая и на её решение ушло пару недель времени. К моему сожалению опыт показал, что знания в области медицинских технологий в нашей стране взять просто неоткуда и практика это показала. Но не будем о грустном и перейдём ближе к делу. Клиника закупила магнитно-резонансный томограф, в связи с чем возникла необходимость организовать передачу и хранение медицинских изображений, получаемых при обследовании пациентов. Как многим уже известно, современная медицинская техника общается с внешними устройствами по стандартизированному протоколу DICOM, а для того, что бы наладить работу медицинской информационной системы желательно обзавестись DICOM / PACS сервером.
Так что же нам нужно для построения системы передачи и архивации медицинских изображений? DICOM-сервер или PACS-сервер? Этот вопрос наверняка задаст себе каждый, кто впервые сталкивается с ИТ в медицине. Вот что говорит на этот счёт Википедия:
PACS ( Picture Archiving and Communication System ) — система передачи и архивации медицинских изображений в формате DICOM, предполагают создание специальных удаленных архивов на DICOM серверах-ах, где весьма объемный архив может длительное время существовать в «горячем» виде и быть быстро доступным для поиска и просмотра интересующей информации по DICOM сети.
DICOM ( Digital Imaging and Communications in Medicine ) — отраслевой стандарт создания, хранения, передачи и визуализации медицинских изображений и документов обследованных пациентов.
Вы наверняка часто будете видеть в интернете использование той или иной аббревиатуры, хотя речь скорее всего будет идти об одной и той же по функциям системе.
Мир софта для DICOM серверов просто впечатляет разнообразием решений, есть дорогие и сложные громадины из разряда Enterprise, есть масса платных DICOM/PACS-серверов малого и среднего уровня, но наиболее популярные и массовые это бесплатные и Open-Source проекты.
Для реализации DICOM сервера я решил остановиться на Open-Source. Список основных и наиболее известных бесплатных PACS / DICOM серверов:
— Dcm4che
— Conquest DICOM software
— ClearCanvas
— DICoogle
— CDMEDIC PACS WEB
— Orthanc
Я «сломал» голову и потратил уйму времени, что бы определиться какая из них лучше и какую выбрать для создания своего первого DICOM-сервера.
Основа выбора от части была в определении платформы, делать сервер на Windows совсем не хотелось, душа больше лежала к Linux. Второй и немаловажный аспект это наличие и объём полезной информации в русскоязычных сообществах, т.к. на этапе знакомства с DICOM не очень то хотелось тратить силы на перевод иностранных и вовсе не прозаических текстов. Третьим и не менее важным моментом конечно же является функционал системы, а так же простота установки, конфигурирования и использования.
Orthanc направлен на предоставление простой, но мощный автономный сервер DICOM. Он предназначен для улучшения потоков DICOM в больницах и поддержки исследований о автоматизированного анализа медицинских изображений. Orthanc позволяет его пользователям сосредоточиться на содержание файлов DICOM, скрывая сложность формата DICOM и протокола DICOM.
Orthanc может превратить любой компьютер с операционной системой Windows, Linux или OS X в магазин DICOM (другими словами, система мини-PACS). Его архитектура является легким и автономным, это означает, что никакого комплекса управления базами данных не требуется, ни установка зависимостей сторонних.
Что делает Ортханк уникальным является тот факт, что она обеспечивает RESTful API. Благодаря этому главной особенностью, можно ездить Ортханка из любого языка программирования. В DICOM теги сохраненных медицинских изображений могут быть загружены в формате JSON файла. Кроме того, стандартные изображения PNG могут генерироваться на лету из экземпляров DICOM по Ортханка.
Ортханк также имеет механизм плагинов для добавления новых модулей, который расширяет базовые возможности его REST API. Веб зритель, база данных PostgreSQL фоновых и эталонную реализацию DICOMweb настоящее время в свободном доступе в виде плагинов.
Источник
Установка бесплатного PACS-сервера ORTHANC на Ubuntu 20.04
Orthanc — бесплатный и свободно распространяемый PACS-сервер, используется для хранения и просмотра медицинских DICOM-снимков. Устанавливать его мы будем на «чистый» Ubuntu Server 20.04.
Подключаемся к серверу и обновляем репозитории:
Устанавливаем пакеты Orthanc`а.
| root@pacs: # apt install orthanc orthanc-dicomweb orthanc-webviewer |
Запускаем сервер и проверяем, слушает ли он порты. Порт 8042 — для web-интерфейса и порт 4242 — для интеграции с другими приложениями (в частности, для удалённой загрузки снимков, об этом — в конце заметки).
С этого момента сервер работает и доступен через браузер по адресу http://HOSTNAME_OR_IP:8042. Теперь создадим учетную запись пользователя и разрешим авторизацию на сервере, для этого откроем на редактирование конфигурационный файл orthanc.json.
Нас интересуют два параметра — RemoteAccessAllowed (меняем false на true) и RegisteredUsers (раскомментируем и задаём логины-пароли для авторизации).
После сохранения перезапустим сервер и залогинимся по адресу http://HOSTNAME_OR_IP:8042 под одной из созданных учёток.
Если всё сделано правильно, появится интерфейс Orthanc`а.
На этом этапе сервер полностью работоспособен — позволяет загружать снимки, проcматривать их в браузере и искать. Единственное неудобство — веб-интерфейс Orthanc`a при загрузке исследований не позволяет выбрать директорию целиком, только файлы изображений; это неудобно, если исследование имеет вложенные директории. Для удобства можно пользоваться двумя способами.
Автоматическая загрузка исследования скриптом
Orthanc предлагает несколько способов загрузки DICOM-изображений. Речь пойдёт про скрипт ImportDicomFiles.py. Для работы должен быть установлен Python3. Синтаксис запуска скрипта:
Нужно создать smb-шару и дать к ней доступ. В примере — доступ для всех без ограничений.
Исследование следует загрузить в созданную шару, затем выполнить команду:
Скрипт самостоятельно проверяет все директории в /import на предмет dicom-снимков, при нахождении — загружает их к себе. Чтобы не тратить место и не заниматься чисткой, предлагаю использовать модифицированный ImportDicomFiles_custom.py — он не проверяет директории, которые «моложе» 10 минут (на случай, если исследование большое и ещё копируется) и после загрузки dicom-снимков удаляет их (не директории).
Теперь можно создать bash-крипт idf.sh, который запустит скрипт импорта файлов, затем проверит, все ли директории в /import «старше» 60 минут и если да — удалит их.
Скрипт можно поместить в cron для выполнения каждые 10 минут:
Ручная загрузка исследования утилитой
Можно использовать утилиту PACS IW Migration Tool.
В конфигурации утилиты нужно указать адрес хоста с Orthanc и порт 4242.
После этого в основном интерфейсе программы нужно выбрать директорию, содержащую исследовани(е/я) и запустить отправку — утилита самостоятельно отберёт нужные файлы и загрузит их на PACS-сервер.
Источник
PACS-сервер своими руками
Преамбула
Очевидно, что для взаимодействия разнокачественного медицинского оборудования необходим единый протокол. И как раз таким протоколом выступает DICOM (Digital Imaging and Communications in Medicine), который за последние 20 лет был серьёзно усовершенствован, что позволило легко интегрировать медицинское оборудование в общую информационную систему. Практически все производители медицинского оборудования следуют этому протоколу. Следовательно поддержка протокола DICOM было естественным требованием к PACS-серверу. Было решено реализовать многопоточный высоконагруженный PACS, способный работать в кластере. Сервер разрабатывался на языке С++ и применялась самая адекватная на сегодняшний день библиотека для работы с протоколом DICOM, написанная на С++ — DCMTK. Именно благодаря этой библиотеке стало возможным быстро реализовывать высоконагруженные PACS-системы.
Проектируем БД
БД в PACS-системе позволяет хранить информацию о сохранённых изображениях и производить по ним поиск. Изображения также нужно уметь передавать по сети, а вместе с ним метаинформацию о изображении (кто на снимке, в какой клинике произведены, кто проводил исследование и прочее). Для этих целей протоколом DICOM предусмотрена специальная 4х уровневая модель данных, о которой можно вкратце узнать здесь. Полный список всевозможных атрибутов файла можно узнать на официальном сайте протокола[1]. В изображениях, полученных из разных аппаратов, список этих атрибутов будет отличаться, что является совершенно нормальным. Однако часть атрибутов остаётся обязательной для поддержания универсального поиска по изображениям. Их немного — всего штук десять, среди них Patient Name, Patient ID, Patient Birthday, Modality Type (КТ, МРТ, УЗИ и др), Study Date (дата исследования) и др. Помимо обязательных параметров существуют необязательные, их довольно много и поддерживать их в БД как показывает практика — является лишним.
Наличие большого количества необязательных параметров в метаинформации изображений — один из недостатков протокола DICOM. Некоторые аппараты выставляют одни параметры, некоторые — другие. Следовательно поддерживать их в БД для поиска — бессмысленно. В итоге проработав несколько вариантов, остановились на таком варианте БД:
Как видно схема БД соответствует многоуровневой структуре DICOM файлов. У одного пациента может быть много стадий (читай исследований). Исследование представляет собой множество серий, определяемых протоколом исследования. Серия хранит множество изображений.
Основные функции PACS-системы
Рассмотрим вкратце основные функции (сервисы) стандартной PACS-системы, почти все из которых я уже упомянул. Поскольку любое взаимодействие рабочих станций с PACS-системой является клиент-серверным, то и все операции также реализованы в двух вариантах — клиентском и серверном. В DCMTK присутствуют реализации обоих вариантов. PACS реализует серверную часть.
Префикс ‘C-‘ у операций означает Composite, что подразумевает, что операция — целостная и самодостаточная и выполняется без привязки к другим операциям. Существуют ещё операции с префиксом ‘N-‘(N-CREATE, N-SET, N-GET и др.), которые выполняются в рамках какой-то более общей операции (выставляют статусы, информируют о начале исследования и др.). Эти операции не относятся к теме данной статьи.
C-ECHO – команда, позволяющая узнать доступность клиента в сети. Аналогична команде ping в винде. В реализации команда очень проста — нужно всего лишь отправить ответ со статусом STATUS_Success:
где assoc – соединение, установленное клиентом, request — входящий запрос.
С-STORE — команда, позволяющая сохранять изображения на PACS-сервере в формате DCM.
Вот кусок кода, который это делает:
Колбэк storeSCPCallback срабатывает на каждый пакет, а не на каждый файл. О завершении скачивания файла свидетельствует условие progress->state == DIMSE_StoreEnd , тогда мы можем сохранить файл. Единственной сложностью при реализации этой команды является выбор структуры каталогов при сохранении файла. Чтобы не хранить в таблице OBJECTS путь к файлу, мы вычисляем его из остальных данных. Мы остановились на такой структуре каталогов: ПУТЬ_К_ХРАНИЛИЩУ/STUDY.DATE(YEAR)/STUDY.DATE(MONTH)/STUDY.DATE(DAY)/STUDY.TIME(HOUR)/PATIENT.PID(первая буква)/ PATIENT.PID/STUDY.UID/<изображения>. Такая иерархическая структура позволяет минимизировать количество вложенных папок, что позволяет работать с данной структурой каталогов без временных лагов.
Также хочется сказать, что таблица OBJECT заполняется очень интенсивно. Одно исследование на МРТ-томографе длится в среднем 20 минут, за это время томограф производит 100-300 изображений, КТ-томограф 500-700 иображений. Итого изображений за день может достигать 1440/20 * 500 = 36000 изображений за сутки. В нашем диагностическом центре перерывов в работе томографов практически нет ни днём, ни ночью. Поэтому таблица OBJECT должна хранить минимально возможное количество данных.
С-MOVE — команда, позволяющая передать изображения из PACS на рабочую или диагностическую станцию. Команда передаётся вызывающей станцией (source) на PACS и в ней указывается, на какую станцию (destination) необходимо загрузить изображения. В частном случае, если source=destination, то происходит просто скачивание файлов.
Команда C-MOVE является более универсальной по сравнению с командой С-GET, позволяющей только скачивать изображения. С-MOVE умеет скачивать изображения не только на свою, но и на любую другую. В команде указывается AETitle станции, на которую требуется загрузить изображения. AETitle – это имя клиента, обычно большими буквами (например, CLIENT_SCU). Оно устанавливается при запуске dicom-listener’а (сервера).
То есть клиент, инициализирующий команду С-MOVE на PACS-сервер, должен у себя запустить мини-PACS, позволяющий принимать только команду С-STORE. А PACS-сервер в свою очередь должен при команде С-MOVE установить новое соединение с клиентом, поднять изображения из хранилища и выполнить для каждого из низ клиентскую версию команды С-STORE обратно на клиент. Кстати, только команда С-MOVE позволяет передавать как сжатые изображения (JPEG), так и несжатые за счёт установления нового соединения.
Команда С-GET, однако, умеет загружать изображения без установления нового соединения и, следовательно, без необходимости поднимать сервер на клиентской стороне. В этом случае PACS также выполняет клиентскую версию команды С-STORE, только через соединение установленное командой С-GET.
C-FIND — команда, позволяющая производить поиск по изображениям на разных уровнях. То есть фактически существует четыре вида команды С-FIND: C-FIND на уровне PATIENT, на уровне STUDY, на уровне SERIES и на уровне IMAGE.
То есть в коллбэке нужно заполнить объекты response — параметры ответа и responseDataSet — информация о пациенте/стадии/серии/изображении, которую нужно было найти. Об отправке их обратно на клиент позаботится функция DIMSE_findProvider() из DCMTK.
Команда С-FIND опасна тем, что клиент может указать слишком общий критерий поиска и клиенту придётся отдавать большой объём информации. Например, можно запросить все стадии за последний год. Если попытаться сначала загрузить все данные на сервер, то сервер скорее всего повиснет. Поэтому делать большие запросы нельзя, нужно подгружать данные по мере срабатывания коллбэков. Для этого нужно реализовать запрос к БД в виде итератора и по мере срабатывания коллбэков вызывать next() и таким образом брать следующий объект. К тому же отменить поиск можно только по приходу коллбэка, поэтому если поиск на PACS’е повиснет на некоторое время на выборке из БД, а клиент будет вызывать отмену запроса, то никакой реакции на клиенте не произойдёт. Это актуально для поиска на уровне пациентов и стадий. Для поиска на уровне серий это неактуально, поскольку стадий, содержащих более 15 серий, мы на практике не встречали. Аналогично для поиска на уровне изображений — серий с более чем 1000 изображений мы на практике не встречали.
Обобщим
Итак, мы рассмотрели основные функции PACS-системы и её роль в общей структуре диагностического центра. Также освещены практические моменты и различные аспекты реализации медицинских промышленных PACS-систем. Однако этим функционалом PACS-системы как правило не ограничиваются. Существует также сервис WADO(Web Access to DICOM Objects) и сервис управления рабочими задачами (Modality worklist), также входящих в функции PACS-систем. Надеюсь, для кого-то статья окажется полезной и сэкономит кучу времени.
Источник