Orthanc dicom сервер настройка на windows

Обновлено: 12.07.2024

На днях закончил внедрение 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 серверов:

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 и DICOM-клиента Radiant. В ходе настройки выяснили, что каждый DICOM-клиент должен быть описан в PACS-серверах следующим образом:

  • Имя клиента
  • AE-имя (должно быть уникально)
  • TCP-порт, который автоматически открывается на стороне клиента и принимает DICOM-обследования от PACS-сервера (т.е. сервер как бы толкает их в сторону клиента – инициируя соединение первым)
  • IP-адрес

Пример файла pacs.xml по ссылке:

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

  • Нам нужно ввести в строй несколько новых PACS-серверов, которые подменят старые (где стало заканчиваться место на дисках). PACS сервера в виртуальных машинах, но речь не об этом;
  • Нам нужно как-то централизованно изменить уникальные конфигурации (двумя отличающимися параметрами) на 200 машинах (их количество регулярно увеличивалось);
  • Учитывая темпы роста объемов обследований, решение нужно не разовое, а тиражируемое и регулярное (например, 1 раз в 3-5 месяцев).

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

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

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

  • Собрать групповой политикой все файлы pacs.xml в одном месте на каком ни будь сервере в сетевом ресурсе;
  • Изменить файлы скопом (опыт решения таких задач уже был – с использованием Perl);
  • Также с помощью групповых политик обновить настройки клиентов.

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

Самая простая часть – при входе клиента в свой профиль он со своими правами выполняет некий .bat файл, в котором прописано:


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

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

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

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

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


Принцип его работы:

  • Открываем каталог, в котором у нас собраны конфигурации pacs.xml от клиентов и помещаем список файлов в массив скаляров (@report_files);
  • В цикле обрабатываем по одному файлу и считываем его построчно;
  • С помощью split дробим каждую строку на 5 частей, используя кавычки как разделитель;
  • Находим строку с словом listener и помещаем в две переменные уникальные для каждого файла данные (AE-имя клиента и номер TCP-порта);
  • После этого просто формируем новый XML-файл, вписываем в него уникальные параметры и далее вставляем нужное количество PACS-серверов с их параметрами – т.е. то, ради чего все затевалось)
  • Переписываем новый XML-файл поверх старого.

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

Самое простое, что пришло в голову – внести изменения в уже работающий .bat файл, который собирает конфигурации с клиентов и добавить строку:

Хотим сделать в больнице сеть для обмена DICOM данными между врачами-клиницистами (ПК на базе Windows), сервером для хранения данных (возможны варианты) и ПК врачей-рентгенологов (преимущественно на MacOS с программой OSIRIX).

Прошу у Вас совета по следующим вопросам:

1) можете ли Вы порекомендовать софт для консолей врачей НЕ рентгенологов чтобы они могли работать в DICOM - пространстве (выполнять запросы по поиску пациентов на DICOM-хранилище и скачивать с него выбранные исследования) - требования: бесплатная или очень дешевая, совместима с Windows, простая в освоении;

2) можете ли Вы порекомендовать софт для компьютера использующегося в роли DICOM - хранилища (под Linux или Windows) - чтобы он получал все DICOM данные в режиме listener, обрабатывал запросы с рандомных компьютеров в сети.

Все эти танцы с бубнами нет от лучшей жизни. Денег в больнице нет, а работать по человечески хочется. И самое главное, есть понимание главного врача о необходимости такой сети.

Пока предварительно решили что сервер будет в форм-факторе NAS с 16 Tb хранилищем.

Список основных и наиболее известных бесплатных PACS / DICOM серверов:

— Dcm4che
— Conquest DICOM software
— ClearCanvas
— DICoogle
— CDMEDIC PACS WEB
— Orthanc

Из Google поиска

Список основных и наиболее известных бесплатных PACS / DICOM серверов:

— Dcm4che
— Conquest DICOM software
— ClearCanvas
— DICoogle
— CDMEDIC PACS WEB
— Orthanc

Благодарю, это все тоже нашел. Насколько я понимаю, Вы этот софт не используете.. а мне бы надо реальные отзывы.

доброе) у нас на больницу и клиницистам и рентгенологам стоит CLearCanvas - ничего особенного про него не скажу. Клиницисты вроде не жалуются на него, да и мы тоже; хотя выбора особа и нет) Поиск по ФИО, дате, и еще чемуто. Вот так както)

что выбрали в итоге ?

добрый день всем. Раз уж тут про PACS надеюсь сможете чем нибудь помочь. есть томограф и рабочая станция. на станции хранятся все пациенты и периодически мы их писали на диски (архив) и освобождали место под новых. Вскоре упросили начальство купить комп с большими винчестерами. также попросили приезжего инженера установить efilm. все прекрасно работало и снимки отправлялись в хранилище до одного прекрасного дня. теперь файлы со станции (plaza) не отправляются на efilm или отсылается какой то один и система пишет "передано с ошибкой" может быть кто знает где надо порыться?

(пинг от компа к компу по сетке идет. Efilm видит рабочую станцию и пациентов на ней, но принимать файлы отказывается.)

Проверьте IP компа с efilm, Совпадает ли AE title efilm, его порт с прописанным на станции. Если что-то из этого изменилось - программа не сможет послать дайкомы в базу efilm.

Обработка медицинских изображений DICOM: Orthanc Plugin SDK внедряет сервис WADO

hot3.jpg

2019 Unicorn Enterprise Стандарт набора для тяжелых инженеров Python >>>

1) Введение

Стандарт DICOM определяет формат файла и протокол передачи сети медицинских изображений. WADO, веб-доступ к постоянным объектам DICOM, представляет собой протокол для доступа к медицинским изображениям на основе веб-служб в стандарте DICOM 3.0 (в частности, в DICOM 3.0, часть 18). Благодаря протоколу WADO профессиональные врачи могут использовать обычные браузеры (в настоящее время Orthanc, похоже, не поддерживает IE) для предварительного просмотра и загрузки медицинских изображений.

2) Справочная информация:

Orthanc - это открытый, легкий, независимый сервер с поддержкой сценариев DICOM. Orthanc в основном используется для оптимизации клинических медицинских процедур и упрощения управления медицинскими изображениями. Кроме того, благодаря совместимости с распространенными форматами JSON, PNG и RESTful API стандарт DICOM стал более широко использоваться в области компьютерной графики. Orthanc скрывает сложность формата файла DICOM и протокола DICOM, поэтому его могут использовать обычные сетевые администраторы и профессиональные разработчики программного обеспечения для автоматического анализа медицинских изображений. Orthanc может служить надежным медицинским центром обработки изображений, предоставляя услуги различным больницам.

3) DICOM и WADO

Этот раздел лишь кратко знакомит с протоколом WADO. Подробное введение см. В части 18 стандарта DICOM3.0.

Соглашение DICOM предусматривает следующие стандарты: Пациент может проводить несколько обследований (Исследования). Каждое исследование содержит серию медицинских изображений, а именно серии. Например: стандартное исследование PET-CT (Исследование) будет содержать два набора последовательностей, последовательность CT и последовательность PET. Последовательность обычно соответствует 2D / 3D / 4D изображениям человеческого тела. Каждое изображение будет разделено на несколько файлов для хранения, а именно Экземпляр (то есть единственный файл с суффиксом DCM, который мы видим, содержит одно изображение).

Обычно экземпляр DICOM можно рассматривать как комбинацию двумерного изображения и структуры, в которой хранится метаинформация пациента (демографическая информация, такая как имя, возраст, рост, вес и т. Д.). Метаданные пациента обычно представляют собой массив, содержащий соответствующие значения тегов DICOM. Каждая метка представлена ​​двумя шестнадцатеричными числами. Очень важно, чтобы каждый уровень обучения (Study), последовательности (Series) и образа (Instance) требовал глобальной уникальности.

Например (0x0020,0x000d) От имени Study Instance UID Определите уникальность исследования (Study);

Ответом на этот запрос WADO будет формат JPEG изображения DICOM, соответствующий studyUID / seriesUID / objectUID. Если вы хотите получить файлы формата DICOM напрямую, вы должны добавить contentType = application% 2Fdicom к запросу WADO, как показано ниже:

Пример кода зависит от следующих четырех частей: Orthanc Plugin SDK (после версии 0.8.0); Библиотека CImg (используется для преобразования изображений DICOM в формат PNG); Библиотека JsonCpp, используемая для анализа файла формата Json, возвращаемого службой Orthanc; CMake Используется для компиляции исходного кода.

1) Компиляция плагина Orthanc WADO:

Первый шаг: войдите в режим командной строки cmd, создайте каталог компиляции, введите команду: mkdir Build

Шаг 2: Войдите в каталог сборки

Третий шаг: запустите Cmake, начните компиляцию, введите cmake .. \ WadoPluginSources ( Примечание: здесь .. означает возвращать каталог, в котором находится CmakeList.txt в исходном коде WadoPluginSources, формулировка в README.txt неверна )

Шаг 4: Откройте проект WadoPlugin.sln в каталоге Build и скомпилируйте с помощью VS. Вы увидите WadoPlugin.dll в каталоге Build \ Debug, указывая, что плагин WADO был успешно создан.

2) Установка плагина Orthanc WADO:

Инструкции по установке, приведенные в файле README.txt в пакете с исходным кодом, неверны. Вы должны добавить полный путь к файлу WadoPlugin.dll в поле, соответствующее Plugin, в файле Configuration.json, как показано на следующем рисунке:



Примечание. Путь WadoPlugin.dll, введенный в системе Windows, должен использовать [/] на приведенном выше рисунке или ввести «c: \\ WadoPluginSources \\ Build \\ Debug \\ WadoPlugin.dll». В противном случае произойдет ошибка.

3) Плагин Orthanc WADO запускается:

После изменения файла Configuration.json перейдите в каталог, где находится Orthanc.exe, например, мой компьютер: C:\Orthanc-0.8.5\Debug>Orthanc.exe ../../Orthanc/Configuration.json , [Примечание: следует путь Configuration.json с добавленным WadoPlugin.dll, если вы вводите Orthanc.exe --config=Configuration.json , Является результатом создания файла Configuration.json по умолчанию без запуска службы WadoPlugin).



4) Пример теста:

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



Среди них известные UID test1:

StudyInstanceUID=1.3.6.1.4.1.30071.6.176694098609799.4240639413125000;

SeriesInstanceUID=1.3.6.1.4.1.30071.6.176694098609799.4240639413125000.1;

SOPInstanceUID=2.16.840.114421.81623.9430067258.9493139258;

Результаты браузера показаны ниже, так же, как исходный файл test1.dcm.



1) Официальное описание:

Уровень обучения должен быть расположен в первую очередь, код выглядит следующим образом:

Функция LocateStudy сначала создает запрос URI API RESTful в форме / Studies, запрашивает UUID всех исследований в Orthanc, а затем перебирает каждый полученный studyUUID для построения запроса API RESTful в форме / Studies / . Сравните теги StudyInstanceUID в возвращенном результате JSON один за другим, чтобы определить местоположение исследования;

Во-вторых, найдите уровень sereis, код выглядит следующим образом:

Аналогично уровню обучения;

Последний уровень уровня, код выглядит следующим образом:

Вышеуказанный процесс позиционирования является сложным. Начиная с версии 0.8.0, Orthanc предоставляет функции для прямого доступа к индексу DICOM в базе данных, OrthancPluginLookupPatient (), OrthancPluginLookupStudy (), OrthancPluginLookupStudyWithAccessionNumber (), OrthancPluginLookupSeries (). С этим типом функции нет необходимости сначала находить исследование, затем серию и, наконец, экземпляр. Это так громоздко. Модифицированный код выглядит следующим образом:

2) Модификация новой версии плагина Wado:

Согласно официальным инструкциям, SDK Orthanc Plugin предоставляется в формате файла заголовка C, поэтому после прямой замены OrthancCPlugin.h в WadoPluginSources файлом OrthancCPlugin.h в Orthanc-0.8.5 мы обнаружили, что недавно добавили LocateInstance в WadoPlugin.cpp. GetContext () в функции не распознается:


Откройте файл OrthancContext.h и найдите, что в файле нет функции GetContext (), поэтому вам нужно вручную добавить публичную функцию:

После модификации можно распознать функцию GetContext (), но после компиляции возникает следующая ошибка:





До сих пор разработка Orthanc WADO Plugin была объяснена.

fo-dicom создает простой DICOM-сервер






Читайте также: