Conquest сервер dicom настройка

Настройка DICOM сервера Conquest / Configuring and Running Conquest DICOM server

This article is written in Russian. You might want to read a Google Translation in order to get the main idea.

Тут речь пойдет об установке открытого DICOM сервера Conquest под ОС Linux (на примере Debian GNU/Linux)

Сервер умеет хранить индексную информацию в базах данных PostgreSQL, mysql и sqlite. Файлы исследований во всех случаях хранятся в файловой системе. Для случая PostgreSQL и mysql, сервер подключается к внешним базам данных, указанным в конфиге. Для случая sqlite эта мини-субд вкомпилируется напрямую в сервер.

Справедливости ради, надо заметить, что мне не удалось собрать Conquest с sqlite, и я не пробовал устанавливать его с Postgresql, поэтому речь пойдет о сборе с использованием mysql.

Скачиваем дистрибутив conquest’а для сборки под линукс со страницы http://www.xs4all.nl/

Ставим пакет libmysqlclient-dev с заголовочными файлами библиотеки для соединения с mysql

Создаем директории /usr/lib/cgi-bin и /var/www, поскольку maklinux_mysql сам их создавать не умеет. Если есть желание использовать другие пути, следует отредактировать maklinux_mysql. (Так же отмечу, что все помещаемое в /var/www для нас бессмысленно, так как туда кладется какой-то ocx для MS IE который нам бесполезен, так что строчки относящиеся /var/www можно просто закомментировать)

Запускаем maklinux_mysql с правами root’а

Создаем в mysql базу данных с именем conquest и пользотвателя для работы с ней

Редактируем файл конфигурации /usr/lib/cgi-bin/dicom.ini Добавляем туда имя имя пользователя базы данных (поле Username) пароль этого пользователя (поле Password), и имя самой базы данных (поле SQLServer)

Создаем папку для хранения данных сервера, по умолчанию предполагается что это /.data

Прописываем файл конфигурации /usr/lib/cgi-bin/dicom.ini путь к созданной директории в поле MAGDevice0 (в самом низу). ВНИМАНИЕ: следите за тем чтобы в конце строк в файле конфигурации не стояло пробелов, Conquest к этому чувствителен, и сочтет что пробел – часть пути

Скопировать директорию samples из которая живет в директории data дистрибутива, в созданную директорию для хранения данных

Проверить что в базе данных появились таблицы

Редактировать /usr/lib/cgi-bin/acrnema.map добавть туда IP адреса, DICOM имена и порты клиентов которые будут подсоединяться к серверу.

Следует помнить, что клиент – понятие условное, оба и клиент и сервер являются по сути серверами и должны видеть дург-друга и уметь открвывать tcp соединение со своей стороны. Поэтому ни один из узлов не должен быть спрятан за NAT’ом…

Чем тестировать:

K-PACS

Настройка подключения к серверу происходит по нажатию на кнопку с тремя компьютерами. Если конквест был поставлен с настройками по умолчанию, должны быть примерно такими:

Если же нажать на кнопку с папкой сервером и еще какой-то хренью, то попадаешь в окно настроек локального сервера:

Данные из полей K-PACS Server Application Entry Title и Server Port следует добавить в /usr/lib/cgi-bin/acrnema.map вместе с IPшником той машины на которой этот K-PAСS запускается. Примерно вот так:

Левые кнопки работают только если рядом с какой-то записью поставить галочку. От кнопки transfer выпадает список внешних серверов на которые можно изображение передать.

За счет кнопки import можно создавать новые картинки из обычных jpeg’ов.

Настроить MITO следует через меню Pacs/Preferences

Server Node: IP адрес Conquesta Server Port: Порт к которому прибинден Conquest (по умолчанию 5678) Called AP Title: Имя сервера (в нашем случае, если эта настройка конквеста не менялись, CONQUEST1) Calling AP Title: Имя клиента. Например MITO_CLIENT Storage AP Title: Не совсем понял, но работает если совпадает с именем клиента, то есть MITO_CLIENT

Во второй вкладке, Transfer/Reseive:

Storage Server Port: порт по которому локальный сервер MITO будет принимать информацию, например 1234 Receive/Local Files Directory: Папка в которой MITO будет хранить локальную информацию…

На сервере, в файле /usr/lib/cgi-bin/acrnema.map следует правильно прописать данные MITO, его IP, имя, и порт. Что-то вроде этого:

Для проверки работоспособности жмем Query в панеле инструментов, В появившемся окне снова кнопку Query, выбераем HEAD EXP2 и жмем кнопку Download. снимок головы неизвестного героя должен загрузиться в локальный сервер MITO.

настройка dicom сервера conquest

Изменение настроек программ с сохранением персональных параметров

Предыстория

В одной медицинской организации внедряли решения на базе PACS-серверов Orthanc и DICOM-клиента Radiant. В ходе настройки выяснили, что каждый DICOM-клиент должен быть описан в PACS-серверах следующим образом:

После настройки Radiant клиентов получили следующую информацию к размышлению – у каждого клиента настройка ПО с указанными выше параметрами приводила к заполнению файла pacs.xml, который располагался в профиле пользователя (путь: %APPDATA%\RadiantViewer\pacs.xml). При этом конфиг одного клиента от другого отличался минимум двумя параметрами (AE-имя у всех разное, а порт в основном одинаковый, кроме терминальных клиентов, работающих на одном и том же сервере – там порты тоже приходилось назначать разными).

Примерно полгода все было хорошо, система заработала…и тут до нас дошли «подводные камни»:

Выбор инструментария для решения задачи

Вначале были попытки найти какое-то решение, которое на стороне клиента изменяло файл pacs.xml, и вносило в него изменения в список PACS-серверов, не трогая настройки AE-имени и TCP-порта. Windows клиенты на тот момент были на базе как Windows XP, так и Windows 7 – поэтому были попытки написать что-то такое на базе VBScript. Но увы – осилить такую задачу не получилось, ввиду полного отсутствия опыта написания чего-либо сложного и комплексного на этом языке. Попытки же найти и переписать также не увенчались успехом (тут надо отметить, что в голове уже был другой план, поэтому я не долбился с VBScript больше 3-4 часов).

В итоге я остановился на следующем решении:

Сбор файлов с помощью групповой политики

Таким образом на сервере в скрытом ресурсе будут накапливаться файлы pacs.xml, в имени которых есть информация с какого компьютера и с какого пользователя был скопирован данный конфиг.

Самое сложное было – дождаться, когда у всех пользователей отработает данная политика.

Изменение конфигураций с помощью Perl скрипта

Нам потребуется Active Perl под Windows от компании ActiveState, а также модуль XML::Writer, который можно установить с помощью команды ppm install XML-Writer.

Сам же скрипт получился довольно простой:

Надо отметить, что на самом деле я использую данный скрипт не полностью автоматически – по сути я копирую собираемые конфиги в отдельный каталог и потом запуская скрипт изменяю их всем скопом. Далее выборочная проверка – и конфиги можно разливать обратно по машинам.

Распространение измененных pacs.xml файлов по клиентам

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.
Вот кусок кода, который это делает:

Также хочется сказать, что таблица 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-систем. Надеюсь, для кого-то статья окажется полезной и сэкономит кучу времени.