Рубрика: Статьи

26.09.2026 Статьи

Форвардинг исследований и exporter в dcm4chee-arc: как устроена автоматическая отправка и почему она молча останавливается

Форвардинг — одна из тех настроек, о которых вспоминают спустя три месяца. Исследования исправно принимаются, архив отвечает, пользователи не жалуются, а во второй архив с весны не ушло ни одного объекта. Или ушло, но не всё: половина серий на месте, половина нет, и никто не может сказать, когда это началось.

Причина почти всегда в одном из трёх мест: перепутаны сущности, не включён планировщик задач или условие правила не совпадает с тем, что реально приходит от модальности. Разберём, как устроена автоматическая отправка исследований в dcm4chee-arc, что где настраивается и в каком порядке это диагностируется. Это четвёртая часть разбора прикладной эксплуатации архива — после удаления исследований, слияния пациентов и очередей и проверки хранилища.

Три сущности, которые путают

Автоматическая отправка складывается из трёх независимых настроек. Каждая отвечает за свой вопрос, и отсутствие любой из них означает, что не работает ничего.

Сущность Отвечает на вопрос Что в ней задаётся
Remote Application Entity Куда отправлять AE Title получателя, его адрес и порт
Exporter Чем и по какому протоколу Тип отправки, адрес назначения, очередь задач, от имени какого AE работает архив, расписание
Export Rule Что и когда отправлять Условия отбора, уровень срабатывания, задержка, ссылка на exporter

Типичная ошибка новичка выглядит так: создано правило экспорта, в нём указан exporter, exporter ссылается на AE Title получателя — а самого получателя как Remote AE в конфигурации нет. Формально всё заполнено, задачи создаются и немедленно падают. Обратный вариант встречается реже, но тоже бывает: получатель заведён, exporter есть, а правила нет — тогда задачи просто не создаются, и очередь остаётся пустой, что легко принять за «всё отправлено».

Пустая очередь экспорта — это не «всё отправлено». Это либо действительно всё отправлено, либо задачи вообще не создаются. Различать эти два состояния нужно всегда, и различаются они по-разному: в первом случае в очереди есть выполненные задачи, во втором — нет никаких.

Exporter: чем отправляем

Exporter описывает способ доставки. Основные атрибуты:

Поле в Archive UI Атрибут LDAP Что задаёт
Exporter ID dcmExporterID Имя exporter'а; на него ссылается правило экспорта
URI dcmURI Назначение и способ. Для отправки на удалённый архив по DIMSE — dicom:STORESCP, где STORESCP это AE Title получателя
Queue Name dcmQueueName Очередь задач, в которую попадает экспорт (например Export1)
Application Entity (AE) Title dicomAETitle От имени какого локального AE архив выполняет отправку
Schedule dcmSchedule Необязательное расписание, например hour=18-6 dayOfWeek=* — отправлять только ночью
Description dicomDescription Описание. Не формальность: через год именно оно объяснит, зачем этот exporter заведён

Обратите внимание на dcmURI: именно префикс определяет способ доставки, и у разных способов разный синтаксис и разные дополнительные свойства. Кроме отправки по DIMSE архив умеет выгружать в STOW-RS, забирать и раскладывать по WADO, создавать рабочие элементы UPS и публиковать в XDS. У каждого типа свой набор свойств — от разделов TLS и метаданных документа у XDS до указания целевого хранилища у WADO.

Практически это означает: «настроить exporter» — это не одна процедура, а пять разных. Чужая инструкция, написанная под STOW-RS, не поможет при настройке отправки на обычный DICOM-архив, хотя на первый взгляд обе про «экспорт».

Export Rule: что и когда отправляем

Поле в Archive UI Атрибут LDAP Что задаёт
Name cn Имя правила
Exporter ID dcmExporterID Какой exporter использовать — связь правила с доставкой
Attribute Entity dcmEntity Уровень срабатывания: исследование, серия или отдельный объект
Delay dcmDuration Задержка после получения последнего объекта, в формате ISO-8601: PT1M — минута
Property dcmProperty Условия отбора: например ReceivingApplicationEntityTitle=DCM4CHEE и Modality=CT|MR
Schedule dcmSchedule Ограничение по времени, например dayOfWeek=1-5 — только по будням

Правило создаётся на одном из двух уровней, и выбор уровня — содержательное решение:

    • на уровне устройства архива — правило действует на объекты, принятые любым AE;
    • на уровне конкретного Archive AE — только на то, что принято этим AE.

Когда в архив пишут несколько учреждений через разные AE, правило, повешенное на устройство «чтобы наверняка», начинает пересылать чужие данные туда, куда их пересылать не следовало. Это не техническая ошибка — архив делает ровно то, что попросили, — но это утечка за пределы согласованного контура.

Про уровень срабатывания

Выбор dcmEntity определяет, сколько задач создаст архив и когда они начнут выполняться.

Уровень Поведение Когда уместен
Исследование Одна задача на исследование, после паузы в поступлении объектов Обычный выбор для пересылки во второй архив: передаётся целое исследование
Серия Задача на каждую серию Когда получателю нужны отдельные серии или исследование приходит частями с большими паузами
Объект Задача на каждый принятый объект Редко и осознанно: КТ-исследование на тысячу срезов породит тысячу задач

Отдельно про dcmDuration. Задержка нужна не для красоты: DICOM не сообщает архиву, что исследование закончено. Архив считает исследование сложившимся, когда объекты перестали поступать в течение заданного времени. Поставьте нулевую или слишком малую задержку — и получите отправку наполовину принятого исследования, а затем ещё одну задачу на остаток, и объяснять получателю, почему у него исследование в двух частях, придётся вам.

Слишком большая задержка тоже имеет цену: исследование будет ждать отправки, и если у заказчика есть ожидание «во втором архиве снимки появляются в течение получаса», это ожидание нарушится. Разумная величина выводится из того, как ведёт себя конкретная модальность: сколько длится пауза между сериями на реальных исследованиях.

Как собрать конфигурацию через Archive UI

    1. Зарегистрируйте получателя. Откройте Configuration → Devices → AE list, нажмите +, создайте удалённое устройство или выберите существующее. Укажите AE Title, hostname, port и Network Connection Reference, затем Apply. В той же вкладке запустите Echo, выбрав локальный calling AE.
    2. Создайте exporter. На вкладке Configuration → Devices откройте More Functions → Create Exporter, выберите dcm4chee-arc и задайте Exporter ID, URI вида dicom:AE_TITLE_ПОЛУЧАТЕЛЯ, Queue Name и локальный Application Entity (AE) Title. Нажмите Apply.
    3. Создайте Export Rule. Для правила на весь архив откройте dcm4chee-arc → Extensions → Device Extension → Extensions → Archive Device → Child Objects и в строке Export Rule выберите + Add a new Export Rule. Для одного Archive AE путь идёт через dcm4chee-arc → Child Objects → Network AEs → нужный AE → Extensions → Network AE Extension → Extensions → Archive Network AE → Child Objects. Заполните Name, Attribute Entity, Exporter ID, задержку и условия, затем Save.
    4. Включите планировщик. Вернитесь в атрибуты Archive Device, задайте Export Task Polling Interval и сохраните.

Без wizard exporter можно создать вручную в Archive Device → Child Objects → Exporter Descriptor → + Add a new Exporter. Для начинающего wizard безопаснее: он сразу показывает обязательные поля. Если позже понадобятся редкие опции, откройте созданный exporter в Exporter Descriptor.

Альтернатива через LDAP. В LDAP нужны те же четыре части: удалённые dicomDevice/dicomNetworkAE/dicomNetworkConnection, дочерний объект dcmExporter, объект dcmExportRule на уровне устройства или AE и dcmExportTaskPollingInterval в записи архивного устройства. Имена атрибутов приведены в таблицах выше. После ldapadd/ldapmodify выполните Configuration → Control → Reload.

Настройка, без которой не работает ничего

Есть четвёртая вещь, которая не относится ни к правилу, ни к exporter'у и о которой забывают чаще всего. Задачи экспорта выполняет планировщик, и он включается отдельным интервалом опроса на уровне устройства архива:

dcmExportTaskPollingInterval: PT1M

В интерфейсе это поле «Export Task Polling Interval» в расширении устройства архива. Пока интервал не задан, планировщик не работает: правила срабатывают, задачи создаются и спокойно лежат в очереди в состоянии «запланирована». Внешне архив здоров, очередь не пустая, ошибок нет — просто ничего не происходит.

Это системная особенность dcm4chee-arc, а не частность экспорта. Удаление отклонённых объектов, проверка хранилища, очистка отработанных задач — у каждого механизма собственный интервал опроса, и каждый из них по умолчанию может быть не задан. Настроенный механизм и работающий механизм — разные вещи, и проверять надо второе.

Что происходит после срабатывания правила

Дальше экспорт живёт как обычная задача архива: попадает в указанную очередь, проходит состояния, при неудаче повторяется, отображается на странице мониторинга, где её можно отменить или перепланировать. Подробно состояния задач, их разбор и автоочистка разобраны в статье про очереди и проверку хранилища — здесь достаточно помнить, что вкладка экспорта в мониторинге и есть главное место наблюдения за форвардингом.

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

    • запрос подтверждения хранения (Storage Commitment) у получателя;
    • уведомление о доступности объектов (IAN);
    • удаление объектов из локального хранилища;
    • отклонение объектов с истёкшим сроком хранения.

Третий пункт требует отдельного внимания. Связка «выгрузили во внешний архив — освободили место у себя» абсолютно нормальна и часто именно для этого всё и строится. Но администратор, который меняет правило экспорта, обязан заранее знать, тянет ли оно за собой удаление. Правка условия отбора в такой конфигурации — это уже не «перенастроить пересылку», а операция, затрагивающая сохранность данных. Что происходит с объектами после отправки, должно быть записано в паспорте сервера рядом с самим правилом.

Типовые задачи

Что нужно Как складывается конфигурация
Копия всех КТ и МРТ во второй архив Remote AE получателя → DICOM-exporter с dicom: и его AE → правило уровня исследования с условием по модальности и разумной задержкой
Пересылать только то, что приходит от конкретного учреждения Правило на уровне того Archive AE, которым принимает это учреждение, либо условие по принимающему AE Title
Выгружать ночью, чтобы не занимать канал днём Расписание в exporter'е или в правиле; днём задачи копятся и уходят в окно
Отправить одно исследование по заявке, разово Ручная отправка из интерфейса архива; выбирается между постановкой в очередь и синхронной отправкой
Освобождать место после подтверждённой выгрузки Экспорт плюс подтверждение хранения плюс удаление после экспорта — с обязательной записью об этом в паспорте сервера

Про ручную отправку стоит сказать отдельно. Архив предлагает два режима: поставить задачу в очередь или выполнить отправку синхронно. Разовая отправка небольшого исследования синхронно удобна — сразу видно результат. Но синхронная отправка объёмного КТ через узкий канал займёт интерфейс и может оборваться по таймауту; для такого лучше очередь.

Ничего не уходит: порядок диагностики

Порядок важен: он идёт от самых частых причин к самым редким и не требует доступа к получателю на первых шагах.

    1. Задан ли интервал опроса задач экспорта. Если задачи есть, но все в состоянии «запланирована» — дальше можно не искать.
    2. Создаются ли задачи вообще. Отправьте тестовое исследование и посмотрите вкладку экспорта в мониторинге. Задач нет — проблема в правиле, задачи есть и падают — в доставке. Это развилка, которая экономит больше всего времени.
    3. Тот ли уровень у правила. Правило на конкретном AE не сработает на данных, принятых другим AE.
    4. Совпадают ли условия. Возьмите реальный объект и сверьте его атрибуты с условиями правила. Модальность CR не попадёт под условие CT|MR, а принимающий AE Title в условии может отличаться регистром или быть переименован после настройки.
    5. Не истекла ли задержка. Если dcmDuration — час, то через десять минут после приёма задачи закономерно ещё нет.
    6. Не действует ли расписание. Правило с окном «только ночью» днём не работает, и это не поломка.
    7. Существует ли получатель в конфигурации. Exporter ссылается на AE Title; этот AE должен быть заведён как Remote AE с адресом и портом.
    8. Есть ли связь. Проверка связи с получателем от того AE, от имени которого работает exporter. Заодно выяснится, знает ли получатель наш AE Title — многие архивы принимают только от известных источников.
    9. Что в ошибке задачи и что в логах получателя. К этому моменту у вас уже есть конкретная упавшая задача, а не общее «не работает».

Отдельный симптом — уходит не всё. Здесь первым делом смотрят не на сеть, а на задачи в состоянии предупреждения: получатель мог отказать по отдельным объектам из-за неподдерживаемого transfer syntax или SOP Class. Сеть в этом случае исправна, ошибки нет, а данные у получателя неполные.

Ловушки

    • Петля пересылки. Архив A пересылает в B, B настроен пересылать всё принятое обратно в A. Объекты ходят по кругу, очереди растут на обоих серверах. Перед включением форвардинга выясните, что настроено на стороне получателя.
    • Нулевая задержка — исследования уезжают частями.
    • Уровень объекта на тяжёлых модальностях — тысячи задач на одно исследование, очередь и база под нагрузкой.
    • Правило на уровне устройства «чтобы наверняка» — пересылка чужих данных за пределы согласованного контура.
    • Отсутствие расписания на узком канале — дневная выгрузка конкурирует с приёмом от модальностей.
    • Экспорт с последующим удалением, о котором не знали. Самая дорогая ошибка в этом списке.
    • Включение форвардинга на историю. Правило действует на вновь принимаемые объекты; выгрузка накопленного архива — отдельная операция, которую планируют по объёму, времени и влиянию на канал, а не запускают «заодно».
    • Отсутствие описания. Через год никто не вспомнит, кому и зачем этот exporter отправляет данные, а выключать страшно.

Чек-лист перед включением на рабочем сервере

    1. Есть заявка и понятно, кто получатель, какие данные ему положены и на каком основании.
    2. Получатель согласован: его AE Title, адрес, порт, и он знает наш AE Title.
    3. Выяснено, что настроено на стороне получателя — нет ли обратной пересылки.
    4. Условия отбора сформулированы узко и проверены на реальных атрибутах, а не на предположении о том, что шлёт модальность.
    5. Выбран уровень срабатывания и обоснована задержка.
    6. Решено, нужно ли расписание, и оценено влияние на канал.
    7. Известно и записано, тянет ли экспорт за собой удаление объектов.
    8. Проверено, что интервал опроса задач экспорта задан.
    9. Проведена проверка на одном тестовом исследовании, и подтверждено получателем, что оно дошло целиком.
    10. Правило, exporter, получатель и последствия экспорта внесены в паспорт сервера; запись о включении — в журнал изменений.

Итог

Форвардинг складывается из трёх настроек — получатель, способ доставки, правило отбора — и работает только при заданном интервале опроса задач. Отсюда и порядок диагностики: сначала проверяют, создаются ли задачи вообще, и лишь потом ищут проблему в сети.

Две вещи стоит держать в голове постоянно. Первая: молчащий форвардинг не подаёт признаков аварии, поэтому его состояние должно входить в ежедневную проверку наравне со свободным местом. Вторая: экспорт может тянуть за собой удаление локальных объектов, и прежде чем менять правило, нужно знать, что именно произойдёт с данными после отправки.

Источники

    • Export Rule — атрибуты правила, уровни срабатывания и условия.
    • DICOM Exporter — отправка на удалённый AE по DIMSE.
    • Exporter Properties — свойства exporter'ов других типов: WADO, UPS, XDS.

Названия атрибутов и полей интерфейса приведены по актуальной на момент написания ветке dcm4chee-arc 5.35.x. В более старых инсталляциях они отличаются — сверяйтесь с документацией своей версии и проверяйте настройку на стенде до включения на рабочем сервере.

26.09.2026 Статьи

Очереди и проверка хранилища в dcm4chee-arc: как понять, что архив на самом деле здоров

«PACS работает» — фраза, за которой скрываются три совершенно разных утверждения. Порт архива отвечает. Исследования принимаются. Данные действительно лежат там, где считает база, а накопленные задачи выполняются, а не копятся. Мониторинг доступности подтверждает только первое. Две самые тихие аварии PACS он не видит вообще: остановившаяся очередь экспорта и потерянные объекты в хранилище.

Обе обнаруживаются не в момент возникновения, а через недели — когда выясняется, что во второй архив ничего не уходило с мая, или когда исследование не открывается, хотя в списке оно есть. Статья о двух механизмах, которые позволяют увидеть это вовремя: очередях задач архива и проверке хранилища (Storage Verification). Это третья часть разбора прикладной эксплуатации dcm4chee-arc — после удаления исследований и слияния пациентов и исправления атрибутов.

Часть 1. Очереди и задачи архива

Значительная часть работы архива выполняется не в момент обращения, а отложенно, задачами. Пришло исследование — задача на экспорт во второй архив. Настроена проверка хранилища — задача на верификацию. Запрошены данные из внешнего архива — задача на получение. Такая архитектура нужна, чтобы медленный или недоступный получатель не блокировал приём данных от модальности. Обратная сторона: если задачи перестали выполняться, приём продолжает работать, и внешне всё выглядит нормально.

В интерфейсе архива задачи разложены по вкладкам страницы Monitoring: Queues, Export, External Retrieve, Diff, Storage Verification. Это первое место, куда администратор смотрит, когда что-то «не доехало».

Состояния задачи

Задача проходит через понятный набор состояний, и различать их важнее, чем кажется:

Состояние Что означает Реакция администратора
Scheduled Задача поставлена в очередь и ждёт выполнения Нормально, если очередь движется. Тревожно, если число только растёт
In process Задача выполняется сейчас Насторожиться, если задача «выполняется» сутками: обычно это след падения узла
Completed Выполнена успешно Ничего. Такие задачи должны автоматически убираться из базы
Warning Выполнена, но не полностью — например, часть объектов не принята получателем Разобрать обязательно: это не «почти успех», а частичная потеря результата
Failed Не выполнена, попытки исчерпаны Найти причину. Перезапуск без устранения причины даст то же самое
Canceled Отменена вручную Убедиться, что отмена зафиксирована в журнале с причиной

Отдельно про Warning. Это состояние регулярно проскакивают мимо: задача же не упала. На практике за ним стоит ровно то, о чём потом спрашивают через месяц: половина серий ушла во второй архив, половина — нет.

Типовые картины и что за ними стоит

Что видно в Monitoring Вероятная причина Что делать
Очередь экспорта монотонно растёт, задачи уходят в failed Получатель недоступен, изменился его адрес или порт, не зарегистрирован AE Title Проверить связь с получателем (C-ECHO), сверить конфигурацию exporter, и только потом перепланировать задачи
Задачи висят в in process и не двигаются Узел архива был перезапущен или упал во время выполнения Перепланировать задачи; в кластере — при необходимости на другой узел
Много задач в warning Получатель принимает не все объекты: несовместимый transfer syntax, отказ по отдельным SOP Class, нехватка места на приёмнике Разобрать один случай до конца по логам обеих сторон, затем исправлять причину, а не задачи
Очередь пустая, но исследования во второй архив не уходят Правило экспорта не срабатывает: условия не совпадают с данными Проверить условия правила на конкретном исследовании, а не искать неисправность в очередях
База данных архива непривычно растёт, хотя исследований столько же Не настроена автоочистка выполненных задач Настроить удаление отработанных сообщений очередей

Главная ошибка в работе с очередями — массовое «перепланировать всё» до того, как понята причина. Задачи уйдут в работу, снова упадут и вернутся в том же количестве, зато будет потеряна картина: какие именно задачи падали и с какими ошибками.

Отмена и перепланирование

Архив позволяет отменять задачи и планировать их заново — как по одной, так и выборкой. В кластере перепланирование поддерживает указание целевого узла: запрос принимается одним узлом и выполняется тем, который указан параметром, а при его отсутствии задача перепланируется на том же устройстве. Для этого узлы должны быть описаны конфигурацией сетевых соединений и веб-приложений со служебным классом DCM4CHEE_ARC.

Порядок работы, который стоит закрепить в собственном runbook:

    1. Зафиксировать состояние: сколько задач, в каких состояниях, с какого времени, с какими сообщениями об ошибке. Скриншот или выгрузка — до любых действий.
    2. Взять одну упавшую задачу и разобрать её до конца: что за операция, какой получатель, что в логах архива и в логах получателя.
    3. Устранить причину.
    4. Перепланировать одну задачу и убедиться, что она прошла.
    5. Только теперь перепланировать остальные.
    6. Записать в журнал: сколько задач, почему падали, что исправлено, сколько прошло после исправления.

Гигиена: автоочистка отработанных задач

Записи о задачах хранятся в базе данных архива. Если их не удалять, база растёт, а страница Monitoring со временем становится нечитаемой. Удаление настраивается отдельно для каждого состояния — и это удобно: выполненные можно убирать быстро, а упавшие держать долго, чтобы было что разбирать.

Поле в Archive UI Атрибут LDAP Что задаёт
Purge Queue Messages Polling Interval dcmPurgeQueueMessagePollingInterval Как часто запускается очистка. Пока не задан, очистка не работает
Delay for purging completed queue messages dcmPurgeQueueMessageCompletedDelay Через какое время удалять успешно выполненные задачи
Delay for purging warning queue messages dcmPurgeQueueMessageWarningDelay То же для задач со статусом warning
Delay for purging failed queue messages dcmPurgeQueueMessageFailedDelay То же для упавших задач
Delay for purging canceled queue messages dcmPurgeQueueMessageCanceledDelay То же для отменённых
Интервалы и задержки задаются в формате ISO-8601: PT1H — час, P1D — сутки, P30D — тридцать суток.

Через Archive UI. Откройте Configuration → Devices, нажмите Edit у dcm4chee-arc, затем Extensions → Device Extension → Extensions → Archive Device. Задайте Purge Queue Messages Polling Interval и сохраните. Затем откройте Child Objects, выберите нужную Queue и задайте четыре задержки. Повторите для каждой очереди, которую нужно очищать.

Через LDAP. dcmPurgeQueueMessagePollingInterval задаётся в записи dicomDeviceName=dcm4chee-arc, а задержки — в каждой нужной записи dcmQueueName=.... После изменения выполните Configuration → Control → Reload.

Разумная отправная точка: выполненные — через сутки, warning и failed — через две-четыре недели. Держать упавшие задачи неделями стоит именно потому, что заявка «а почему в июне не выгрузилось» приходит в июле.

Часть 2. Storage Verification: проверка хранилища

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

Пока никто не спрашивает конкретное исследование, расхождение незаметно. Storage Verification — механизм, который проверяет соответствие планово, а не в момент, когда исследование срочно потребовалось врачу.

Уровни проверки и их цена

Проверять можно с разной глубиной, и это главный выбор при настройке. Логика уровней такая:

Что проверяется Цена Что поймает и что пропустит
Существование объекта в хранилище — OBJECT_EXISTS Дёшево: только обращение к метаданным файловой системы Поймает пропавшие файлы и неподключённое хранилище. Пропустит повреждённое содержимое
Совпадение контрольной суммы — OBJECT_CHECKSUM, значение по умолчанию Дорого: каждый объект читается целиком Поймает и пропажу, и порчу содержимого. Создаёт заметную нагрузку на диск и сеть
Набор доступных политик зависит от версии архива — точный список смотрите в интерфейсе и документации своей версии.

Про цену стоит сказать прямее. Проверка по контрольной сумме означает чтение всего проверяемого объёма. Для архива в единицы терабайт на локальных дисках это вопрос планирования; для хранилища на NFS или для nearline-уровня это может означать многочасовую нагрузку на сеть и заметное замедление обычной работы. Поэтому у механизма есть и расписание, и ограничители.

Настройки

В ветке 5.35.x плановая Storage Verification настраивается в расширении Archive Device. В таблице приведены имена полей Archive UI и их LDAP-атрибуты:

Поле в Archive UI Атрибут LDAP Что задаёт
Storage Verification Polling Interval dcmStorageVerificationPollingInterval Как часто планировщик берётся за работу. Не задан — проверка не выполняется
Storage Verification Initial Delay dcmStorageVerificationInitialDelay Отсрочка первой проверки после поступления данных
Storage Verification Period dcmStorageVerificationPeriod Периодичность повторной проверки уже проверенных объектов
Storage Verification Schedule dcmStorageVerificationSchedule Окно, в которое разрешено выполнять проверку
Maximal scheduled Storage Verifications dcmStorageVerificationMaxScheduled Предел одновременно запланированных задач
Storage Verification Fetch Size dcmStorageVerificationFetchSize Размер порции, которую планировщик берёт за раз
Storage Verification Policy dcmStorageVerificationPolicy Глубина проверки, по умолчанию OBJECT_CHECKSUM
Storage Verification Storage ID(s) dcmStorageVerificationStorageID Какие хранилища считать достаточными для успешной проверки
Storage Verification AE Title dcmStorageVerificationAETitle От имени какого AE выполняется проверка
Storage Verification Update Location Status dcmStorageVerificationUpdateLocationStatus Обновлять ли статус расположения объекта по результату проверки
Storage Verification Batch ID dcmStorageVerificationBatchID Идентификатор пакета для группировки задач в Monitoring

Через Archive UI. Откройте Configuration → Devices → dcm4chee-arc → Extensions → Device Extension → Extensions → Archive Device → Attributes. Для однократной автоматической проверки новых исследований достаточно задать Storage Verification Initial Delay и Storage Verification Polling Interval. Для повторных проверок добавьте Storage Verification Period; для ночного окна — Storage Verification Schedule; для ограничения числа задач — Maximal scheduled Storage Verifications. Проверьте политику, AE Title и Storage ID, затем нажмите Save.

Через LDAP. Все показанные в таблице атрибуты добавляются в запись dicomDeviceName=dcm4chee-arc. После ldapmodify перезагрузите конфигурацию через Configuration → Control → Reload.

Запускать проверку вручную для отдельных исследований можно из интерфейса архива: страница Studies, меню дополнительных функций, пункт проверки хранилища. Наблюдать за выполнением — на странице Monitoring, вкладка Storage Verification. Отдельно инициировать подтверждение хранения через DIMSE или REST для этого не требуется: планировщик делает всё сам.

Как читать результат

Расхождение — это сигнал, а не приговор. Прежде чем говорить о потере данных, проверьте более прозаические причины, расположенные в порядке убывания частоты:

    1. Хранилище не смонтировано. Классика: сервер перезагрузился, NFS-ресурс не подключился, каталог на месте, но пустой. Проверяется первым делом.
    2. Права доступа. Процесс архива перестал читать каталог после смены владельца или обновления.
    3. Объекты перемещены вручную. Кто-то переносил данные между дисками, не используя средства архива.
    4. Незавершённая операция удаления. Записи удалены, файлы ещё нет, или наоборот — смотрите разбор двух стадий удаления в первой части.
    5. Аппаратная проблема. Сбойные секторы, деградировавший массив, отказывающий контроллер. Смотрите SMART и состояние RAID.
    6. Реальная потеря объектов. Вывод, к которому приходят последним, а не первым.

Чего при расхождении делать нельзя категорически: удалять записи из базы, «чтобы расхождений не было». Это не устранение проблемы, а уничтожение единственного свидетельства о том, что объекты когда-то существовали. Пока запись есть, известно, что именно потеряно, и остаётся шанс найти копию — во втором хранилище, в nearline, во внешнем архиве, куда исследование выгружалось, или в резервной копии.

Правильная последовательность: зафиксировать перечень расхождений с идентификаторами → проверить монтирование и права → проверить состояние дисков и массива → искать копию → эскалировать с полным перечнем. И только по решению ответственного — что-либо менять в записях.

Чем не является страница Metrics

У архива есть встроенные показатели производительности: скорости чтения и записи в хранилище, время удаления объектов, скорости передачи внешним получателям, число одновременных ассоциаций от модальностей и к удалённым системам, время обновления базы данных. Смотрят их на странице Monitoring, вкладка Metrics, настраивают в расширении устройства архива.

Важное ограничение, которое стоит знать до того, как вы начнёте на них опираться: эти показатели не хранятся в базе данных. Они существуют только пока сервер запущен, по умолчанию удерживаются около часа и теряются при перезапуске и при изменении конфигурации.

Отсюда практический вывод: встроенные показатели хороши для разбора «что происходит прямо сейчас» — упала скорость выгрузки, выросло число ассоциаций. Для истории, трендов и прогноза заполнения нужна внешняя система мониторинга, которая собирает и хранит данные у себя. Встроенные метрики её не заменяют.

Что проверять регулярно

Оба механизма бесполезны, если в них никто не смотрит. Минимальный регламент, который имеет смысл превратить в скрипт и в привычку:

Периодичность Что смотреть
Ежедневно Свободное место и inode на всех хранилищах. Число задач в failed и warning по каждой вкладке Monitoring. Есть ли задачи, висящие в in process дольше суток. Результат последнего прогона проверки хранилища
Еженедельно Динамика: очередь растёт или движется. Рост базы данных и хранилища. Состояние RAID и SMART. Сроки сертификатов и CRL
Ежемесячно Полный обзор расхождений проверки хранилища. Прогноз заполнения и остаток ёмкости. Контрольное восстановление по ротационному графику. Проверка, что автоочистка задач работает и база не пухнет

Ключевая мысль: наблюдать нужно за динамикой, а не за абсолютным числом. Сто задач в очереди — норма, если через час их десять, и авария, если вчера их было пятьдесят. Поэтому в ежедневной проверке полезно фиксировать числа, а не просто смотреть на них.

Чек-лист «архив действительно здоров»

    • DICOM-порт отвечает на проверку связи, web-интерфейс открывается.
    • Тестовое исследование принимается, находится поиском и открывается во вьювере.
    • Все настроенные хранилища смонтированы и доступны на запись.
    • Свободного места и inode достаточно с запасом до следующей проверки.
    • Очереди движутся: число задач в failed не растёт, нет задач, зависших в in process.
    • Задачи в состоянии warning разобраны, а не просто присутствуют.
    • Проверка хранилища выполняется по расписанию, и известно, когда был последний успешный прогон.
    • Расхождения проверки либо отсутствуют, либо по каждому есть объяснение и решение.
    • Автоочистка отработанных задач настроена, база не растёт без причины.
    • Последняя резервная копия выполнена успешно, и это проверено, а не предполагается.

Первые два пункта обычно уже закрыты внешним мониторингом. Остальные восемь — это и есть та часть, которую приходится смотреть руками и которую чаще всего не смотрит никто.

Частые ошибки

    • Считать, что «сервис отвечает» равно «архив здоров». Порт может отвечать при неподключённом хранилище и вставшей очереди.
    • Перепланировать все упавшие задачи разом, не разобрав ни одной. Причина не устранится, а картина сотрётся.
    • Игнорировать статус warning. За ним стоит частичная передача данных.
    • Оставить проверку хранилища на значениях по умолчанию, не задав окно и ограничители. Проверка по контрольной сумме способна сама создать инцидент, заняв диск и сеть в рабочее время.
    • Никогда не включить проверку вообще. Тогда о расхождении вы узнаёте от врача, которому исследование нужно сейчас.
    • Удалять записи о ненайденных объектах. Это уничтожение свидетельства, а не решение проблемы.
    • Не настроить автоочистку задач. База растёт, интерфейс перестаёт быть пригодным для диагностики.
    • Полагаться на встроенные показатели как на историю. Они живут только до перезапуска.

Итог

Доступность архива и его исправность — разные вещи. Очереди показывают, выполняет ли архив отложенную работу; проверка хранилища — соответствуют ли файлы тому, что записано в базе. Обе аварии тихие: приём данных продолжается, порт отвечает, мониторинг молчит.

Минимум, который стоит сделать один раз и потом поддерживать: включить проверку хранилища с разумным окном и ограничителями, настроить автоочистку отработанных задач, добавить в ежедневный обход число задач в failed и warning и дату последнего успешного прогона проверки. Это несколько строк в скрипте и одна привычка, которая избавляет от вопроса «почему во второй архив ничего не уходило три месяца».

Источники

    • dcm4chee-arc wiki: Metrics — встроенные показатели производительности и их ограничения.
    • Export Rule и DICOM Exporter — настройка экспорта, задачи которого чаще всего и появляются в очередях.

Названия настроек, состав политик проверки и вкладок интерфейса приведены по актуальной на момент написания ветке dcm4chee-arc 5.35.x. В более старых инсталляциях они отличаются — сверяйтесь с документацией и интерфейсом своей версии.

26.09.2026 Статьи

Слияние пациентов и исправление атрибутов в dcm4chee-arc: что можно, чего нельзя и в каком порядке

«Заведите одного пациента вместо двух, это один человек». «Исправьте отчество, в направлении опечатка». «Перенесите снимки — они попали не в то исследование». Эти заявки приходят администратору PACS почти так же часто, как просьбы удалить исследование, и требуют совсем другого инструмента. Здесь не отклоняют объекты и не освобождают место — здесь меняют данные о пациенте, а это самая ответственная операция из всех, что администратор вообще выполняет в архиве.

Статья продолжает разбор удаления исследований и посвящена второй половине прикладной эксплуатации архива: слиянию пациентов, изменению идентификаторов и демографии, переносу объектов между исследованиями и правилам преобразования атрибутов (coercion). Всё на примере dcm4chee-arc.

Четыре разных заявки, которые постоянно путают

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

Как формулируют заявку Что произошло на самом деле Механизм
«Это один и тот же человек, а карточек две» Один пациент попал в архив под двумя разными идентификаторами Слияние пациентов
«Опечатка в ФИО», «не та дата рождения», «неверный пол» Демография пациента введена с ошибкой, идентификатор верный Обновление атрибутов пациента
«Снимки приписаны не тому пациенту» Объекты выполнены одному человеку, а в архиве принадлежат другому Отклонение по причине безопасности пациента и повторная отправка, либо перенос объектов
«Исследование попало не туда», «разделите на два исследования» Объекты лежат внутри неверного исследования или серии Перенос или копирование объектов между исследованиями

Обратите внимание на третью строку: «не тот пациент» — это не задача на исправление атрибутов. Соблазн велик: открыть объекты и переписать в них имя. Так делать нельзя, и ниже объясняется, почему.

Почему нельзя править DICOM-файлы

В DCMTK есть утилита dcmodify, которая меняет атрибуты в DICOM-файле. Технически ничто не мешает найти файлы исследования в хранилище архива и переписать в них PatientName. Результат будет такой:

    • в базе данных архива останется прежнее значение — поиск по C-FIND и DICOMweb продолжит возвращать старое имя;
    • при выдаче объектов клиент получит файл с новым именем, и вьювер покажет одно, а список исследований — другое;
    • изменится размер и контрольная сумма файла, и проверка целостности хранилища начнёт сообщать о расхождениях;
    • следа в журнале аудита не останется вовсе.

Ровно то же относится к прямым UPDATE в базе данных архива. Данные о пациенте, исследовании, сериях, объектах, задачах и расположении файлов связаны между собой, и правка одной таблицы рождает несогласованное состояние, которое проявится через недели — обычно в момент, когда исследование срочно понадобится.

Правило простое: любое изменение данных выполняется средствами архива — через его веб-интерфейс или REST-интерфейс. Всё, что делается мимо архива, архив не считает произошедшим.

Что такое «пациент» для архива

Прежде чем сливать записи, нужно понимать, чем архив их различает. Пациент в DICOM опознаётся не по имени, а по паре атрибутов:

Атрибут Тег Смысл
Patient ID (0010,0020) Идентификатор пациента в той системе, которая его выдала
Issuer of Patient ID (0010,0021) Кто выдал этот идентификатор: конкретная МИС, учреждение, реестр
Дополняется Issuer of Patient ID Qualifiers Sequence, когда идентификатор нужно квалифицировать точнее.

Отсюда два следствия, которые объясняют половину «странностей» в архиве.

Первое. Одинаковый Patient ID от разных источников — это разные пациенты. Если одно учреждение нумерует карты с единицы и второе тоже, то без Issuer архив либо смешает двух разных людей, либо размножит одного. Поэтому в dcm4chee-arc есть отдельная операция «дополнить Issuer of Patient ID»: она приписывает существующим записям источник идентификатора, когда модальность или МИС его не передавали.

Второе. Смена имени пациента не меняет его идентичности для архива, а смена Patient ID — меняет. Это две совершенно разные по смыслу операции, и в архиве для них отдельные механизмы.

Что нельзя «исправить» никогда

Идентификаторы объектов неизменяемы по своей природе:

    • StudyInstanceUID (0020,000D) — исследование;
    • SeriesInstanceUID (0020,000E) — серия;
    • SOPInstanceUID (0008,0018) — отдельный объект.

UID — не поле для правки, а вечное имя объекта, на которое ссылаются все остальные системы: МИС, вьюверы, отчёты, журналы аудита, ранее переданные копии в других архивах. Демографию пациента и описательные атрибуты исследования изменить можно; UID — нет. Когда объекты нужно «переложить» в другое исследование, архив не переписывает их UID, а выполняет отдельную операцию переноса, оставляя след в источнике.

Операции архива и их REST-интерфейс

Всё перечисленное доступно и через веб-интерфейс архива, и через REST. Знать REST-пути полезно даже если вы работаете мышью: они однозначно показывают, чем операции отличаются друг от друга. Базовый путь — /dcm4chee-arc/aets/{aet}/rs.

Пациент

POST /patients                                    создать пациента
PUT  /patients/{priorPatientID}                   обновить, слить или сменить ID
POST /patients/{patientID}/merge                  слияние пациентов
POST /patients/{priorPatientID}/merge/{patientID} слияние пациентов
POST /patients/{priorPatientID}/changeid/{patientID}  смена Patient ID
POST /patients/issuer/{issuer}                    дополнить Issuer of Patient ID

Здесь важно различать слияние и смену идентификатора. Слияние применяют, когда в архиве две записи об одном человеке и обе несут исследования: данные исходной записи привязываются к целевой. Смену ID применяют, когда запись одна, а идентификатор у неё неверный — например, учреждение перевыпустило номер карты.

Точное поведение архива в отношении самой исходной записи после слияния и правила выбора «главной» записи стоит проверить на стенде вашей версии до того, как операция выполняется на боевом сервере. Это не формальность: именно здесь администраторы получают неожиданный результат.

Исследование и серия

PUT  /studies/{studyUID}                          обновить атрибуты исследования
PUT  /studies/{studyUID}/series/{seriesUID}       обновить атрибуты серии

Этим правят описательные атрибуты: Accession Number, описание исследования, сведения о направившем враче. Типовой случай — исследование выполнено по верному направлению, но Accession Number не подставился, и МИС не может связать результат с назначением.

Перенос объектов между исследованиями

POST /studies/{studyUID}/copy                                     копировать объекты
POST /studies/{studyUID}/move/{CodeValue}^{CodingSchemeDesignator}  перенести объекты

Посмотрите внимательно на второй путь: операция переноса требует код причины. Причина та же, что и при удалении — перенос устроен как копирование объектов в целевое исследование и отклонение их в источнике. То есть перенос объектов неизбежно порождает rejection note, и его судьба дальше определяется настройками задержек удаления отклонённого, о которых шла речь в предыдущей статье.

Коды берутся из того же справочника CID 7010 стандарта DICOM. Для переноса, вызванного ошибкой идентификации пациента, применяется (113037, DCM) Rejected for Patient Safety Reasons; при выполнении по неверной записи рабочего списка — (113038, DCM) Incorrect Modality Worklist Entry.

Копирование кода причины не требует, потому что в источнике ничего не отклоняется: объекты появляются в целевом исследовании, оставаясь и в исходном. Это нужно реже, чем кажется, и почти всегда следующим шагом всё равно приходится решать судьбу источника.

Главный вопрос: где источник истины

Это та часть, которую администраторы пропускают чаще всего, а она определяет, будет ли исправление устойчивым.

Если сведения о пациенте приходят в архив из МИС — через рабочий список или через HL7-сообщения, — то источником истины является МИС, а архив лишь отражает её данные. Исправление, сделанное только в архиве, в такой схеме живёт до следующего сообщения от МИС: очередное обновление вернёт прежние значения, а администратор будет исправлять одно и то же по кругу и искать «самопроизвольный откат».

Правильный порядок в интегрированном контуре:

    1. ошибка исправляется в системе-источнике;
    2. источник отправляет сообщение об изменении — в HL7 v2 это ADT^A08 для обновления сведений о пациенте и ADT^A40 для слияния идентификаторов;
    3. архив применяет изменение сам, и оно согласовано с источником.

Ручные операции в архиве остаются для случаев, когда источника истины нет (модальность отправляет данные напрямую, без МИС), когда интеграция ещё не настроена или когда исправить в источнике невозможно — например, учреждение уже закрыло случай. В этих случаях исправление в архиве обязательно фиксируется в журнале с пометкой, что оно сделано вручную и может быть перезаписано при появлении интеграции.

Вопрос, который стоит задавать до любой правки: «откуда архив взял это значение и что произойдёт, когда источник пришлёт данные снова?» Если ответа нет — правку делать рано.

Coercion: правила преобразования атрибутов

Отдельный механизм, который часто пытаются применить не по назначению. Coercion — это настроенное в архиве правило, автоматически преобразующее атрибуты проходящих через него данных. Правила применяются в нескольких точках:

    • при приёме объектов от модальности или другого архива;
    • при обработке запросов;
    • при выдаче объектов клиенту;
    • при формировании ответа на запрос рабочего списка.

Для чего это действительно нужно: старый аппарат пишет имя в собственной кодировке; конкретная модальность не заполняет обязательный атрибут; вьювер одного производителя требует значение в ином формате; при передаче во внешний архив нужно подставить идентификатор учреждения. Это всё — свойства потока данных, повторяющиеся каждый день.

Для чего coercion не предназначен: исправить одно конкретное исследование. Правило действует на все данные, попадающие под его условия, и работает молча — в этом и смысл, и опасность. Настроив правило «под один случай», вы получите тихое искажение данных в остальных, и обнаружится это далеко не сразу.

Практические требования к работе с правилами преобразования:

    • каждое правило должно иметь записанное назначение: какая модальность, какой атрибут, почему;
    • условия задаются как можно уже — по конкретному источнику, модальности, AE Title, а не «для всего входящего»;
    • новое правило сначала проверяется на стенде на тестовом наборе, и сравниваются атрибуты до и после;
    • правила входят в состав конфигурации, которая резервируется вместе с архивом: потеряв их, вы получите поток данных, который «раньше работал»;
    • набор и формат настроек заметно менялся между версиями архива — сверяйтесь с документацией и интерфейсом именно вашей версии, а не с чужой инструкцией.

Порядок выполнения работ

У операций изменения данных нет кнопки «отменить». Отклонение объектов обратимо, пока не отработали задержки удаления; слияние пациентов и правка атрибутов — нет. Единственный путь назад — восстановление из резервной копии, а значит, копия обязана существовать до начала работ.

    1. Заявка и основание. Кто просит, на каком основании, кто из ответственных за данные подтвердил. Устная просьба основанием не является.
    2. Классификация. Определить по таблице в начале статьи, какой из четырёх механизмов нужен. Если не удаётся отнести случай ни к одному — это повод эскалировать, а не выбирать наугад.
    3. Источник истины. Выяснить, откуда пришли данные и не вернёт ли интеграция прежние значения.
    4. Фиксация состояния «до». Выписать Patient ID и Issuer, Study Instance UID, при необходимости Series и SOP Instance UID, текущие значения изменяемых атрибутов. Именно значения и UID, а не «исследование Петрова от прошлой недели».
    5. Резервная копия. Свежий дамп базы данных архива и архив конфигурации. Проверить, что копия создана, а не просто запущена.
    6. Проверка цели. Тот ли сервер, тот ли архив, тот ли пациент. Две записи с похожими ФИО — штатная ситуация в любом учреждении.
    7. Выполнение. Средствами архива, одной операцией, без параллельных правок.
    8. Проверка результата. Найти пациента и исследование запросом, открыть исследование во вьювере, убедиться, что перенесённые объекты на месте в целевом исследовании и отсутствуют в исходном, а связь с направлением не потерялась.
    9. Журнал. Запись с полями: заявка, основание, кто подтвердил, механизм, идентификаторы, значения до и после, время, исполнитель, результат проверки.
    10. Уведомление. Сообщить заявителю, что именно сделано — особенно если сделано не то, о чём просили: например, исследование отклонено, а не «удалено навсегда».

Чего делать нельзя

    • Править файлы в хранилище утилитами вроде dcmodify. База об этом не узнает, целостность хранилища нарушится.
    • Менять данные SQL-запросами напрямую. Результат — несогласованный архив, который проявит себя позже и не там, где ожидаете.
    • Подгонять Patient ID «чтобы совпало». Смена идентификатора — операция с последствиями для всех систем, которые на него ссылаются, а не способ свести две записи. Для сведения есть слияние.
    • Настраивать правило преобразования ради одного случая. Правило действует на весь поток и работает молча.
    • Выполнять на боевом архиве операцию, которую ни разу не делали на стенде. Особенно слияние: поведение зависит от версии и настроек.
    • Исправлять в архиве то, что должно исправляться в МИС — без записи о том, что это обход, и без уведомления ответственных.
    • Работать без резервной копии. У этих операций нет отмены.

Где граница ответственности администратора

Изменение медицинских данных — не техническое решение. Администратор владеет инструментом, но не вправе решать, один это пациент или два, и допустима ли правка диагностически значимого атрибута. Решение принимает тот, кто отвечает за данные в учреждении: заведующий отделением, врач, ответственный за информационную систему. Администратор обеспечивает, чтобы решение было исполнено корректно, обратимо там, где это возможно, и зафиксировано.

Отсюда практическое разделение. Администратор первого уровня самостоятельно выполняет операции по утверждённой заявке в рамках отработанной процедуры. Эскалирует — когда затронуто несколько пациентов сразу, когда неясно, какая из записей верна, когда исследование уже передано во внешние системы и правка их не догонит, когда речь идёт о данных из спорного или юридически значимого случая.

Отдельно стоит помнить о том, что журнал аудита архива фиксирует такие операции, и это работает в обе стороны: он защищает администратора, действовавшего по правилам, и не оставляет шансов тому, кто решил «быстренько поправить и никому не говорить».

Итог

Четыре разные заявки — четыре разных механизма: слияние пациентов, обновление атрибутов, отклонение с повторной отправкой, перенос объектов между исследованиями. Все они выполняются средствами архива и никогда — правкой файлов или базы. Идентификаторы объектов неизменяемы, идентичность пациента определяется парой «Patient ID + Issuer», а перенос объектов внутри архива всегда оставляет отклонение в источнике.

И главное: прежде чем что-то исправлять, выясните, откуда архив взял это значение. Половина «неисправимых» ошибок исправляется не в архиве, а в системе, которая их туда прислала.

Источники

    • dcm4chee-arc wiki: RESTful Services — операции с пациентами, исследованиями и объектами, включая слияние, смену идентификатора, перенос и копирование.
    • DICOM PS3.16, CID 7010 — коды причин, требуемые при переносе объектов.

REST-пути и поведение операций приведены по актуальной на момент написания ветке dcm4chee-arc 5.35.x. В более старых инсталляциях состав служб и интерфейс отличаются; перед выполнением операций на рабочем архиве сверяйтесь с документацией своей версии и отрабатывайте порядок действий на стенде.

26.09.2026 Статьи

Почему в PACS нельзя просто удалить файл

«Удалите, пожалуйста, исследование — оно приехало не на того пациента». Это одна из самых частых заявок, которые получает администратор PACS, и одна из самых опасных. В файловой системе архива лежат обычные файлы, и рука тянется сделать rm. Делать этого нельзя: в медицинском архиве удаление — не операция с файлом, а регламентированное действие с историей, аудитом и возможностью объяснить через год, кто и на каком основании убрал данные пациента.

В статье разбирается, как устроено штатное удаление и хранение исследований в dcm4chee-arc: что такое отклонение объектов (rejection) по профилю IOCM, чем оно отличается от физического удаления, как работают политики хранения (retention) и что администратор обязан сделать до того, как в архиве что-то исчезнет.

Почему в PACS нельзя просто удалить файл

Допустим, вы нашли каталог с объектами нужного исследования и удалили его. Что произойдёт дальше:

    • в базе данных архива записи об исследовании, серии и объектах останутся — C-FIND продолжит их находить;
    • при попытке получить исследование через C-MOVE, C-GET или WADO архив вернёт ошибку, потому что файла на месте нет;
    • проверка целостности хранилища (Storage Verification) начнёт выдавать расхождения, и вы не отличите ваше «ручное» удаление от реальной потери данных;
    • в системе не останется следа о том, кто, когда и почему это сделал.

Последний пункт важнее технических. Медицинские изображения — персональные данные особой категории, а исследование может быть предметом разбирательства или судебного спора. Администратор, удаливший объект мимо штатного механизма, не сможет доказать ни основание, ни объём удаления.

Поэтому в DICOM предусмотрен отдельный механизм, а удаление разделено на два принципиально разных действия: логическое отклонение и физическое удаление.

IOCM и rejection note: что это такое

IOCM (Imaging Object Change Management) — профиль IHE, описывающий, как участники радиологической сети сообщают друг другу, что ранее переданные объекты больше не следует использовать. В основе механизма лежит обычный DICOM-объект: документ Key Object Selection (KO), который ссылается на отклоняемые объекты и несёт код причины отклонения. Этот документ и называют rejection note.

Ключевая мысль: отклонение не удаляет данные. Оно помечает объекты как непригодные к использованию, скрывает их от обычных запросов и фиксирует причину. Сами файлы остаются в хранилище, а запись об отклонении — в архиве. Отклонение обратимо: в стандарте для этого предусмотрен отдельный код «Rejection Withdrawn».

Коды причин отклонения

Причина отклонения — не свободный текст, а код из справочника CID 7010 «Key Object Selection Document Title» стандарта DICOM (PS3.16). Администратору достаточно знать пять записей:

Код Значение в стандарте Когда применяется на практике
(113001, DCM) Rejected for Quality Reasons Брак по качеству: смазанный снимок, неверная укладка, засветка. Исследование выполнено тому пациенту, но непригодно
(113037, DCM) Rejected for Patient Safety Reasons Ошибка, угрожающая безопасности пациента: объекты приписаны не тому человеку, перепутаны идентификаторы
(113038, DCM) Incorrect Modality Worklist Entry Исследование выполнено по неверной записи рабочего списка: не то направление, не та процедура
(113039, DCM) Data Retention Policy Expired Истёк установленный срок хранения. Ставится автоматически политикой хранения, а не человеком
(131360, DCM) Rejection Withdrawn Отмена ранее выполненного отклонения — возврат объектов в оборот
Коды причин отклонения по CID 7010. Coding Scheme Designator — DCM.

Код — это не формальность. От него зависит дальнейшая судьба объектов: в dcm4chee-arc для каждой причины настраивается своя задержка перед фактическим удалением, свои права доступа и своё поведение при повторном поступлении тех же объектов. «Брак по качеству» и «не тот пациент» — разные истории и с точки зрения регламента, и с точки зрения того, как скоро данные должны исчезнуть физически.

Практическое правило: если объекты относятся к другому пациенту — это 113037, вопрос безопасности пациента, а не качества. Выбор кода определяет, как быстро данные уйдут из доступа, и его нельзя ставить «на глаз».

Что происходит сразу после отклонения

После того как отклонение выполнено:

    • объекты перестают возвращаться в обычных запросах C-FIND и DICOMweb — для вьювера и для МИС исследование «исчезло»;
    • в архиве появляется rejection note — отдельный объект, который сам по себе доступен и хранится по своим правилам;
    • файлы остаются в хранилище, место на диске не освобождается;
    • операция попадает в журнал аудита архива.

Отсюда типовое недоразумение: администратор отклонил исследования, чтобы освободить место, и удивляется, что df -h показывает прежние цифры. Освобождение места — отдельный, второй этап.

Две стадии удаления в dcm4chee-arc

Физическое удаление в архиве выполняется не одним выключателем, а двумя независимыми процессами. Их полезно держать в голове именно как две стадии.

Стадия 1. Удаление записей об отклонённых объектах

Отвечает за то, через какое время после отклонения архив уберёт записи из базы данных. Здесь настройка разделена между уровнем устройства и дочерними объектами причин отклонения:

Поле в Archive UI Атрибут LDAP Назначение
Delete Rejected Polling Interval dcmDeleteRejectedPollingInterval Как часто запускается задача удаления. Пока интервал не задан, задача не работает
Delete Rejected Instance Delay dcmDeleteRejectedInstanceDelay Задержка перед удалением записей об отклонённых объектах; задаётся отдельно для каждой причины
Delete Rejected Note Delay dcmDeleteRejectionNoteDelay Задержка перед удалением самой rejection note

Через Archive UI. Откройте Menu → Configuration → Devices, нажмите Edit у устройства dcm4chee-arc, затем Extensions → Device Extension → Extensions → Archive Device. В разделе атрибутов задайте Delete Rejected Polling Interval. После этого откройте Child Objects, поочерёдно выберите нужные Rejection Note — например, Quality, Patient Safety, Incorrect MWL Entry и Retention Expired — и задайте для каждой причины свои задержки. Сохраняйте изменения на каждом уровне.

Через LDAP. Интервал dcmDeleteRejectedPollingInterval добавляется в запись устройства dicomDeviceName=dcm4chee-arc, а обе задержки — в соответствующие дочерние записи dcmRejectionNoteLabel=.... После правки LDAP перезагрузите конфигурацию на вкладке Configuration → Control.

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

Стадия 2. Освобождение места в хранилище

Удаление записей из базы само по себе не трогает файлы. За их физическое удаление отвечает отдельный процесс очистки хранилища. В Archive UI пройдите тем же путём до Archive Device и задайте Purge Storage Polling Interval; в LDAP это dcmPurgeStoragePollingInterval в записи устройства.

Практический вывод, который стоит записать в собственный runbook: место освобождается только тогда, когда отработали обе стадии. Частая жалоба «удалили старые исследования, а диск не освободился» почти всегда означает, что не настроена вторая.

Обратная сторона: если у вас настроены обе стадии с короткими задержками, то отклонение перестаёт быть обратимым уже через несколько часов. Прежде чем отклонять что-то на боевом архиве, посмотрите его фактические настройки, а не настройки соседнего сервера.

Retention: политики хранения исследований

Отклонение — это реакция на конкретный инцидент. Политика хранения — правило, которое работает само и определяет, сколько исследование живёт в архиве.

В dcm4chee-arc политика хранения описывается объектом dcmStudyRetentionPolicy и настраивается либо на уровне устройства архива (действует на все AE), либо на уровне конкретного Archive AE. В таблице сначала указано имя поля в Archive UI, в скобках — его LDAP-атрибут:

Атрибут Что задаёт
Name (cn) Имя политики
Study Retention Period (dcmRetentionPeriod) Срок хранения в формате ISO-8601: P1Y — год, P6M — полгода, P30D — тридцать дней
Property (dcmProperty) Условия, при которых правило применяется: например Modality=CT или SendingApplicationEntityTitle=STORESCU
Rule Priority (dcmRulePriority) Приоритет правила, когда под исследование подходит несколько политик
Expire Series Individually (dcmExpireSeriesIndividually) Истекает ли срок у каждой серии отдельно или у исследования целиком

Через Archive UI. Для общей политики откройте Configuration → Devices → dcm4chee-arc → Extensions → Device Extension → Extensions → Archive Device → Child Objects и добавьте Study Retention Policy. Для политики только одного AE откройте у того же устройства Child Objects, выберите AE в Network AEs, затем Extensions → Network AE Extension → Extensions → Archive Network AE → Child Objects → Study Retention Policy. Задайте как минимум Name и Study Retention Period, добавьте условия и нажмите Save.

Через LDAP. Создайте дочернюю запись класса dcmStudyRetentionPolicy под dicomDeviceName=dcm4chee-arc или под нужным dicomAETitle, заполнив атрибуты из таблицы. Затем выполните Configuration → Control → Reload.

Дата истечения вычисляется прибавлением срока хранения к дате поступления исследования в архив и хранится у исследования как отдельный признак. Политику можно применять автоматически при поступлении данных либо запускать вручную к уже накопленным исследованиям.

Отдельно стоит отметить, что тот же механизм позволяет не только ограничивать срок, но и защищать исследования от удаления — «заморозить» их, чтобы никакая автоматика их не тронула. Это нужно для спорных случаев, судебных запросов и контрольных наборов данных.

Как retention соединяется с rejection

Здесь механизмы смыкаются. Истечение срока само по себе ничего не удаляет: оно лишь помечает исследование как просроченное. Дальше работает отдельная задача архива, которая отклоняет просроченные исследования — с кодом (113039, DCM) Data Retention Policy Expired. А уже после этого включаются знакомые две стадии: удаление записей и очистка хранилища.

Этот переход тоже нужно включить. В Archive Device через UI задайте Reject Expired Studies Polling Interval, Reject Expired Studies AE Title и подходящее Reject Expired Studies Schedule; в LDAP им соответствуют dcmRejectExpiredStudiesPollingInterval, dcmRejectExpiredStudiesAETitle и dcmRejectExpiredStudiesSchedule. Указанный AE Title должен существовать и иметь Archive AE Extension. Без этого просроченное исследование останется лишь помеченным как expired.

Полная цепочка выглядит так:

политика хранения
      ↓  (срок истёк — исследование помечено просроченным)
отклонение просроченных исследований
      ↓  (rejection note с кодом 113039, объекты скрыты из выдачи)
удаление записей об отклонённых объектах
      ↓  (отработала задержка dcmDeleteRejectedInstanceDelay)
очистка хранилища
      ↓
место на диске освобождено

Каждый переход управляется отдельной настройкой, и любой из них может быть выключен. Отсюда два противоположных отказа, которые встречаются в эксплуатации: архив бесконтрольно растёт, потому что цепочка обрывается на первом же шаге, — или данные пропадают быстрее, чем ожидал заказчик, потому что срок хранения оказался короче, чем записано в договоре.

Типовые заявки и правильная реакция

Что просят Что это на самом деле Действие администратора
«Снимок бракованный, удалите» Качество, пациент тот же Отклонение с кодом 113001 по заявке от рентгенолога
«Исследование приехало не на того пациента» Ошибка идентификации, безопасность пациента Отклонение с кодом 113037. Не пытаться «переписать» имя пациента в объектах
«Выполнили не по тому направлению» Неверная запись рабочего списка Код 113038, затем решение о повторной отправке с корректным Accession Number
«Диск кончается, почистите архив» Вопрос политики хранения, а не разовой уборки Не удалять вручную. Проверить политику хранения, срок по договору и работу обеих стадий очистки
«Объедините двух пациентов, это один человек» Изменение медицинских данных Самостоятельно не выполнять. Собрать идентификаторы и эскалировать по регламенту
«Верните исследование, отклонили по ошибке» Отмена отклонения Возможна, пока не отработали задержки удаления. Код 131360

Отдельно про последнюю строку таблицы «объедините пациентов». Слияние и разделение пациентов, исправление ошибочных атрибутов, перенос серий между исследованиями — всё это архив умеет, но это уже не эксплуатация, а изменение медицинских данных. Такие операции выполняются по утверждённой процедуре, с фиксацией исходных идентификаторов и обязательным бэкапом до начала работ. Для администратора первого уровня правильный ответ — подготовить данные и передать дальше, а не пробовать на боевом архиве.

Чего делать нельзя

    • Удалять файлы из каталогов хранилища. База об этом не узнает, а Storage Verification начнёт показывать расхождения, неотличимые от реальной потери данных.
    • Удалять записи SQL-запросами напрямую в базе. Связи между исследованием, сериями, объектами, задачами и записями хранилища сложнее, чем кажется; результат — архив в несогласованном состоянии.
    • Выполнять docker compose down -v на боевом архиве. Ключ -v удаляет тома вместе с данными. Эта команда встречается в статьях и в чужих шпаргалках как «перезапустить начисто».
    • Отклонять что-либо без заявки и основания. Устная просьба в коридоре основанием не является.
    • Включать автоматическое удаление просроченного «чтобы не переполнялось» без сверки срока хранения с договором и нормативными требованиями.

Чек-лист перед любым удалением

    1. Есть заявка с основанием и тем, кто её подтвердил.
    2. Записаны идентификаторы: Patient ID, Accession Number, Study Instance UID, при необходимости Series Instance UID. Именно UID, а не «исследование Иванова от вторника».
    3. Проверено, что это тот самый сервер и тот самый архив.
    4. Есть свежая резервная копия базы данных и конфигурации архива.
    5. Известны фактические настройки задержек на этом сервере — то есть сколько времени останется на отмену решения.
    6. Выбран корректный код причины, и выбор можно обосновать.
    7. После операции результат проверен: исследование не находится запросом, rejection note создана, в журнале аудита есть запись.
    8. В журнал изменений внесена запись: заявка, основание, идентификаторы, код, время, исполнитель, результат.

Что стоит настроить заранее

Большая часть авралов вокруг удаления возникает не из-за сложности механизма, а из-за того, что до инцидента никто не смотрел настройки. Минимум, который имеет смысл проверить и записать в паспорт каждого сервера:

    • включена ли задача удаления отклонённого и с каким интервалом;
    • какие задержки установлены для каждой причины отклонения;
    • включена ли очистка хранилища — без неё место не освободится никогда;
    • какие политики хранения заведены, к каким исследованиям применяются и совпадает ли срок с договорными обязательствами;
    • кому выданы права на отклонение объектов — эта операция не должна быть доступна всем подряд;
    • работает ли журнал аудита и куда он пишется.

Итог

В dcm4chee-arc нет операции «удалить исследование». Есть отклонение с указанием причины — обратимое и оставляющее след, и есть отложенное физическое удаление, управляемое настройками архива. Политика хранения — это тот же механизм, только запускаемый автоматически по истечении срока.

Администратору достаточно твёрдо держать в голове три вещи: отклонение и удаление — разные действия; место освобождается только после второй стадии; любое исчезновение медицинских данных должно иметь заявку, основание и запись в журнале. Всё остальное — детали конфигурации, которые всегда можно уточнить в документации.

Источники и что читать дальше

Названия атрибутов и настроек приведены по актуальной на момент написания ветке dcm4chee-arc 5.35.x. В более старых инсталляциях состав настроек и вид интерфейса отличаются — перед применением сверяйтесь с документацией именно вашей версии.

25.08.2026 Статьи

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

«Поддерживает DICOM» — ещё не значит «подключится к вашей системе»

При внедрении радиологических информационных систем мы регулярно сталкиваемся с одной и той же проблемой. Медицинское оборудование заявлено как поддерживающее DICOM, однако при попытке подключить его к PACS или серверу рабочих списков поставщик требует дополнительную оплату: за лицензию, активацию функции, выезд инженера или изменение конфигурации. Особенно недопустима такая ситуация, если передача изображений в PACS или работа с Modality Worklist были прямо указаны в коммерческом предложении, тендерной документации либо договоре. Заказчик вправе ожидать, что заявленная и приобретённая функция будет активирована, настроена и проверена в рамках поставки, а не станет платной неожиданностью после ввода оборудования в эксплуатацию. Проблема часто начинается с слишком общей формулировки: «оборудование соответствует стандарту DICOM». DICOM — это большой набор различных служб. Аппарат может поддерживать лишь некоторые из них и формально оставаться DICOM-совместимым. Поэтому эта фраза сама по себе не гарантирует ни отправку исследований в PACS, ни получение данных пациента из рабочего списка.

Главный документ — DICOM Conformance Statement

До выбора оборудования и подписания договора требуйте у поставщика Заявление о соответствии стандарту DICOM — DICOM Conformance Statement (DCS) именно для предлагаемой модели, версии программного обеспечения и набора лицензированных опций. DCS — не рекламная декларация и не сертификат качества. Это технический документ производителя, в котором указано, какие DICOM-службы реализованы, в каких ролях работает устройство и с какими типами медицинских данных оно взаимодействует. Сравнение DCS оборудования и вашей PACS/RIS позволяет заранее оценить возможность их совместной работы. Это назначение документа прямо определено в части PS3.2 стандарта DICOM. Простое объяснение структуры и назначения DCS можно прочитать в статье «Что такое Заявление о соответствии стандарту DICOM?».

Что именно следует потребовать от поставщика

Для типового подключения радиологического аппарата в документации и договоре необходимо однозначно подтвердить:
    1. Передачу исследований в PACS — оборудование должно отправлять создаваемые им изображения и другие необходимые DICOM-объекты в указанный заказчиком архив. В DCS это обычно описывается как поддержка соответствующих классов DICOM Storage в роли SCU.
    1. Получение рабочего списка — если требуется исключить ручной ввод данных пациента, оборудование должно запрашивать задания с сервера Modality Worklist. В DCS должна быть указана поддержка Modality Worklist Information Model – FIND в роли SCU.
    1. Поддержку всех создаваемых аппаратом типов данных — не только основных изображений, но при необходимости также структурированных отчётов, дозовых отчётов, презентационных состояний, видео и иных объектов.
    1. Отсутствие скрытых ограничений — функции должны быть лицензированы, активированы и доступны в поставляемой конфигурации. Формулировки «поддерживается опционально», «DICOM ready» или «возможно после модернизации» без указания цены и состава опции не должны считаться подтверждением наличия функции.
    1. Выполнение настройки поставщиком — ввод IP-адреса, порта и AE Title серверов заказчика, проверка сетевого соединения, отправка тестового исследования и получение тестового задания Worklist должны входить в поставку.
    1. Возможность дальнейшего сопровождения — заказчику должна быть передана инструкция по изменению DICOM-параметров либо установлен понятный порядок бесплатного выполнения таких изменений поставщиком в течение гарантийного периода.
Полный административный доступ к операционной системе аппарата не всегда необходим и может быть ограничен производителем по соображениям безопасности. Но такое ограничение не освобождает поставщика от обязанности обеспечить заявленное подключение. Если настройки может менять только авторизованный инженер, условия, сроки и стоимость этой работы должны быть определены до заключения договора, а первоначальное подключение к системам заказчика — включено в поставку.

Рекомендуемая формулировка для тендерной документации и договора

Поставщик обязан до подачи предложения предоставить актуальное DICOM Conformance Statement производителя для предлагаемой модели оборудования, версии программного обеспечения и комплекта опций. Поставляемая конфигурация должна обеспечивать без приобретения дополнительных лицензий передачу всех создаваемых оборудованием DICOM-объектов в PACS заказчика и получение рабочих заданий с сервера DICOM Modality Worklist. В стоимость поставки входят активация функций, внесение сетевых и DICOM-параметров, интеграционная настройка и приёмочные испытания. Возможности, требующие отдельной лицензии или оплаты, должны быть прямо перечислены в предложении с указанием их стоимости. Общие формулировки «DICOM-совместимое», «DICOM ready» или «поддерживается опционально» без описания включённых служб и лицензий не являются достаточным подтверждением соответствия требованиям.

Как принять подключение

Оплату и окончательную приёмку целесообразно связывать не с наличием слова DICOM в документации, а с успешными испытаниями:
    • аппарат получает из Worklist тестовое задание с корректными данными пациента и исследования;
    • после выбора задания аппарат формирует исследование без повторного ручного ввода данных;
    • все созданные изображения и сопутствующие объекты поступают в PACS;
    • исследование открывается в используемом заказчиком средстве просмотра;
    • результаты испытаний фиксируются в акте с указанием AE Title, адресов, портов и проверенных функций.
Главная рекомендация заказчикам проста: требуйте DICOM Conformance Statement и точный перечень включённых функций до проведения закупки. Не покупайте обещание «поддержки DICOM» — покупайте конкретный, настроенный и проверенный сценарий работы оборудования в вашей информационной системе.

Источники

Примечание: рекомендуемая формулировка является практическим образцом технического требования. Перед включением в конкретную закупочную документацию её следует согласовать со специалистом по публичным закупкам или юристом учреждения.
27.07.2026 Статьи

dcm4chee-arc, Orthanc и Conquest: подробное сравнение PACS с открытым исходным кодом

1. Краткий вывод

Критерий dcm4chee-arc Orthanc Conquest DICOM
Идея Enterprise-архив, IHE Image Manager/Image Archive Лёгкий DICOM-сервер и интеграционный шлюз Компактный MicroPACS, DICOM router/cache и scriptable archive
Установка Сложная: WildFly, LDAP, PostgreSQL, Keycloak для secure-варианта; удобнее Docker Compose Простая: один бинарник/контейнер и JSON; плагины отдельно Очень простая: Windows/Linux binary, dicom.ini, acrnema.map, dicom.sql; Docker не является основным сценарием
БД PostgreSQL — практический production-вариант; поддерживаются различные SQL-варианты сборки SQLite по умолчанию; PostgreSQL/MySQL через plugins SQLite, MySQL, PostgreSQL, ODBC и dBaseIII; схема задаётся dicom.sql
DICOM-хранение Очень широкий явно описанный набор SOP Classes и развитая архивная обработка Практически любые стандартные DICOM-файлы; глубина индексации и workflow меньше Широкая programmable Storage/Q-R реализация; actual accepted SOP list задаётся конфигурацией
C-FIND Подробная матрица Patient/Study/Series/Image, required/optional keys, matching types Patient Root/Study Root, обычные ключи; нет аналогичной полной публичной таблицы optional keys Patient Root/Study Root и Patient/Study Only; required/unique keys и много optional keys, задаваемых SQL-схемой
MWL/HL7 Встроенные MWL, MPPS, PSU, HL7 ORM/ORU/ADT, XSLT и linking MWL через Worklists plugin; HL7 обычно внешний adapter Простая MWL, HL7 import с configurable translation; полноценного HL7 order engine уровня dcm4chee нет
REST Архивные REST/DICOMweb, MWL, export, retention, MPPS/UPS и administrative APIs Очень удобный REST для Patient/Study/Series/Instance, modify/anonymize/split/merge Встроенный CGI/web API, JSON и DICOMweb; CRUD менее унифицирован и сильнее зависит от Lua/web scripts
Масштаб Центральный PACS нескольких клиник и сложных интеграций Edge/gateway, малый/средний PACS, viewer backend, research Небольшой/средний локальный PACS, cache/router, research; центральный enterprise archive требует осторожной валидации

Если нужны MWL, HL7 ORM/ORU, MPPS/PSU, разные производители модальностей, формальная DICOM-матрица и длительное клиническое хранение, обычно выбирают dcm4chee-arc. Если важны простота, REST, быстрый development и минимальная операционная сложность, часто лучше Orthanc.

Conquest имеет смысл рассматривать как лёгкий локальный PACS, cache/router или Lua-управляемый edge-сервер; для центрального enterprise-архива его следует особенно тщательно валидировать.

2. Архитектура

dcm4chee-arc

dcm4chee-arc изначально проектируется как архивная платформа: у него есть Archive Device, Network AE, HL7 Application, storage systems, export rules, schedulers, audit/security profiles, MWL items, MPPS и UPS. Конфигурация централизована в LDAP. Это даёт большой контроль и воспроизводимость, но добавляет отдельный компонент и требует понимания модели dcm4che.

Orthanc

Orthanc хранит ресурсы в иерархии Patient–Study–Series–Instance, предоставляет HTTP REST API и DICOM network services. Расширения добавляются plugins и Lua/Python. Это проще для разработчика, но часть enterprise-сценариев придётся строить во внешнем RIS/API.

Conquest строится вокруг компактного DICOM engine dgate, SQL/DBF-индекса, файлового storage, dicom.ini, dicom.sql, acrnema.map и dgatesop.lst. В нём есть встроенный web/CGI, DICOMweb и Lua, но нет LDAP/WildFly-модели dcm4chee или столь унифицированной resource REST-модели Orthanc.

3. Инсталляция и настройка

3.1. dcm4chee-arc

Основные варианты:

  • Docker Compose: archive, PostgreSQL, LDAP и, для secure-варианта, Keycloak;
  • нативно: Java 17+, WildFly, SQL БД, LDAP, при необходимости Keycloak;
  • сборка из исходников Maven.

Официальный репозиторий указывает, что Archive 5.x — Java EE-приложение в WildFly, а LDAP используется как централизованная DICOM-конфигурация. В Docker-репозитории отдельно описаны LDAP, PostgreSQL, Java heap, WildFly и Keycloak.

Нужно определить FQDN, TLS, порты DICOM/HTTP/HTTPS/HL7, persistent volumes, PostgreSQL backup, LDAP base DN, Keycloak realm/clients/roles, Archive Device, Network AE, HL7 Applications, storage descriptors, export/retention rules и audit. После запуска необходимо проверить реальные C-ECHO, C-STORE, C-FIND, C-MOVE/C-GET, REST, DICOMweb, MWL и HL7.

Главные риски: неверная Docker network, потеря LDAP volume, отсутствие роли Keycloak, несовпадение hostname, неправильные права на storage и несовместимость версий archive/schema/upgrade scripts. Открывшийся UI не доказывает работоспособность PACS.

3.2. Orthanc

Варианты установки: пакет ОС, готовый бинарник, Docker, сборка C++ или Windows installer. Минимум — один процесс Orthanc и JSON-конфигурация.

Ядро уже умеет C-ECHO, C-STORE, C-FIND, C-MOVE, C-GET и REST. В production часто добавляются:

  • PostgreSQL/MySQL database plugin;
  • DICOMweb plugin;
  • Worklists plugin;
  • Authorization plugin или reverse proxy;
  • Orthanc Explorer 2/viewer;
  • Lua/Python для маршрутизации и webhooks;
  • object-storage plugin.

Настройка сводится к DicomAet, DicomPort, HttpPort, authentication, RemoteAccessAllowed, DicomModalities, storage и plugins. Это заметно быстрее и прозрачнее.

3.3. Conquest DICOM

Conquest устанавливается распаковкой Windows/Linux-пакета или сборкой из исходников. Основные файлы — dicom.ini для AE/порта/БД, acrnema.map для удалённых AE, dicom.sql для database layout и dgatesop.lst для SOP Classes. В Linux есть service file, в Windows — GUI и Windows service. Docker не является основным официальным сценарием.

Установка проще dcm4chee и сопоставима по минимальной сложности с Orthanc, но конфигурация более историческая и менее единообразная: изменение dicom.sql может потребовать полной регенерации базы.

3.4. Сравнение

Этап dcm4chee-arc Orthanc Conquest
Первый запуск Несколько сервисов и зависимостей Один процесс/контейнер Один процесс/service и набор конфигурационных файлов
Конфигурация LDAP-объекты, UI, REST, иногда CLI JSON, REST, plugins, Lua/Python dicom.ini, dicom.sql, acrnema.map, dgatesop.lst, Lua
Безопасность Keycloak/OIDC, роли, LDAP, TLS Basic auth/Authorization plugin, TLS/reverse proxy Web login и reverse proxy; enterprise RBAC нужно строить отдельно
MWL Встроенная order/procedure model Отдельный Worklists plugin Простая MWL и HL7 import translation
HL7 Встроенный HL7 v2 engine и XSLT Внешний adapter/plugin HL7 import для MWL, не полноценный HL7 engine dcm4chee
Диагностика WildFly + LDAP + DB + archive audit Логи процесса и plugins Логи dgate, web/service logs и Lua
Обновление Проверка WildFly, schema, LDAP, Keycloak Обычно проще, но plugins и DB тоже нужно тестировать Проверка binary, dicom.sql, DB migration и Lua/web scripts

4. Железо и СУБД

У обоих проектов нет универсальной формулы ресурсов: определяющими являются peak C-STORE, размер исследований, число viewer-клиентов, WADO/DICOMweb, экспорт, compression, скорость storage и backup window.

Практические стартовые профили

Ресурс dcm4chee-arc: небольшая клиника Orthanc: небольшой/средний узел Conquest: небольшой/средний узел
CPU 4 vCPU; 6–8 при активном DICOMweb/экспорте 2 vCPU; 4 при concurrency 1–2 vCPU
RAM 8–16 GiB archive; 16–32 GiB на общем хосте 2–4 GiB; 4–8 с PostgreSQL/DICOMweb/viewers 1–4 GiB
System disk 40–80 GiB 10–30 GiB 10–20 GiB
DICOM storage Отдельный быстрый RAID/ZFS/NFS/object storage Отдельный volume/диск Отдельный disk/RAID при архиве
DB storage SSD/NVMe и отдельный backup/WAL SQLite на SSD; PostgreSQL/MySQL для concurrency SSD; PostgreSQL/MySQL/ODBC для concurrency
Network 1 Gb/s минимум, 10 Gb/s при больших параллельных экспортах 1 Gb/s обычно достаточно, больше при больших исследованиях 1 Gb/s обычно достаточно

Для Conquest стартовый узел обычно может работать на 1–2 vCPU и 1–4 GiB RAM. Для небольшого локального PACS, cache/router или research-архива этого часто достаточно. Центральную нагрузку нужно проверять отдельно: на неё влияют SQL-driver, DBF/SQLite locking, compression, Lua scripts и число параллельных associations.

Это инженерные стартовые значения, а не сертифицированные минимумы. Для production важнее SSD для БД, корректный Java heap, быстрые временные файлы, connection pool, storage latency и восстановление из backup.

СУБД dcm4chee-arc

В официальной сборке перечислены db2, firebird, h2, mysql, oracle, psql, sqlserver. Для новой Linux production-инсталляции наиболее рационален PostgreSQL: именно он широко используется в официальных Docker-сценариях, хорошо поддерживает транзакции, индексы, WAL и backup. H2 удобен для теста, но не оптимален для клинического архива.

СУБД Orthanc

  • SQLite — встроенная БД по умолчанию;
  • PostgreSQL plugin — основной вариант для большого индекса и concurrent access;
  • MySQL plugin — вариант при стандарте MySQL в организации.

PostgreSQL/MySQL хранят индекс и метаданные, а DICOM binary objects остаются в storage area. Документация Orthanc прямо указывает: с Orthanc 1.9.2 и database plugins 4.0 несколько readers/writers поддерживаются PostgreSQL/MySQL, а встроенная SQLite не поддерживает multiple writers. Поэтому SQLite разумна для edge или одного процесса, но не как центральная многопользовательская БД.

СУБД Conquest

Conquest поддерживает SQLite, MySQL, PostgreSQL, ODBC и исторический dBaseIII/DBF. Для production предпочтительнее PostgreSQL/MySQL или другой проверенный ODBC backend; SQLite подходит для небольшого одиночного узла. В отличие от Orthanc, searchable schema является частью dicom.sql: изменение layout и добавление полей требует контролируемой миграции/регенерации, а не только изменения JSON-настройки.

5. Медицинские исследования и DICOM Conformance

5.1. Как интерпретировать список SOP Classes

Наличие SOP Class в Conformance Statement означает поддержку протокола приёма/отправки, но не гарантирует одинаковую индексацию, viewer support, SR-семантику, private-tag обработку или MWL-сопоставление.

Отдельно проверяются CT/MR/US, enhanced/multi-frame, SR, SEG, PR, KO, RT, dose, video, waveform, Encapsulated PDF/CDA, microscopy/whole-slide, private tags, Transfer Syntax и повторная отправка того же SOP Instance UID.

5.2. dcm4chee-arc

Conformance Statement содержит широкий набор Storage SOP Classes: CT/MR/US/XA/XRF/CR/DX/PET/NM, enhanced/multi-frame, mammography/tomosynthesis, ophthalmology, microscopy, VL photography/endoscopy, video, waveform, SR, presentation states, segmentation, spatial registration, parametric maps, RT objects, radiation dose, encapsulated documents и специализированные классы.

Сильная сторона — не только storage, но и архивная обработка: индексация Patient/Study/Series/Instance, coercion/update policies, storage commitment, export, retention, rejection, audit и связь с MWL/MPPS/HL7.

5.3. Orthanc

Официальная документация заявляет, что Orthanc может принимать, хранить и отправлять любой стандартный DICOM-файл; актуальный список SOP Classes доступен динамически через DICOM Conformance Statement. В нём присутствуют CT/MR/US/PET/NM/CR/DX, mammography/tomosynthesis, RT, SR, SEG, presentation states, waveforms, Encapsulated PDF/CDA, microscopy/whole-slide и другие классы.

Orthanc отлично подходит как нейтральное DICOM storage и REST backend. Но “принять и сохранить” не равно полному clinical workflow: для специализированных объектов может потребоваться ExtraMainDicomTags, plugin, script или внешний индекс.

5.4. Conquest

Conquest принимает широкий набор стандартных DICOM objects; разрешённые SOP Classes можно задавать через dgatesop.lst. Официально заявлены стандартные storage/query/retrieve функции, JPEG/JPEG2000/RLE и web/DICOMweb. Поддержка конкретных enhanced, SR, SEG, RT, waveform, video и whole-slide объектов должна проверяться на фактической версии и конфигурации: исторический Conformance Statement не является полной современной матрицей для всех 1.5.x installations.

Conquest особенно удобен как storage, cache и programmable forwarder, но наличие SOP Class не означает глубокую индексацию SR Content Sequence, MPPS/PSU workflow или viewer semantics.

Тип dcm4chee-arc Orthanc Conquest Вывод
CT/MR/CR/DX/US Полная архивная обработка Отличная базовая поддержка Базовая storage/Q-R поддержка Все три подходят после теста
Enhanced/multi-frame Явно заявлены и архивируются Принимаются; viewer metadata нужно проверить Проверить dgatesop.lst, SQL и viewer Тестировать viewer
Mammography/tomosynthesis Очень сильная область SOP Classes присутствуют Проверить SOP list, codecs и datasets dcm4chee лучше для workflow
SR/dose Широкий набор и HL7/report workflow Хранение/REST, семантика обычно внешняя Storage возможен, семантика и индекс ограничены Преимущество dcm4chee для RIS
RT Развитые SOP и archive scenarios Хранение/передача поддерживаются Проверить конкретный SOP и transfer syntax Отдельный clinical test обязателен
SEG/PR/KO/Parametric Map Поддержка и архивирование Хранение и доступ Возможны как objects, но workflow ограничен Проверить viewer
Video/waveform Широкий список и политики WADO Приём/хранение/отправка Проверить SOP list и web access dcm4chee формализованнее
PDF/CDA Явная поддержка Поддерживаются Проверить acceptance и DICOMweb Все три требуют теста
Whole-slide Современные SOP Classes VL Whole Slide в актуальном списке Не считать поддержанным без отдельного теста Нужен tiled viewer и большой storage
Нестандартные SOP Настраиваемый accept/reject/coercion UnknownSopClassAccepted может разрешить приём dgatesop.lst позволяет управлять accept/reject Приём не означает совместимость

6. Основные DICOM-операции

Операция dcm4chee-arc Orthanc Conquest
C-ECHO SCP/SCU Да Да Да
C-STORE SCP/SCU Да, широкий список Да, список из Conformance Statement Да, SOP list настраивается
C-FIND SCP/SCU Patient Root, Study Root, MWL, MPPS/UPS и расширенные модели Patient Root, Study Root, MWL SCP, C-FIND SCU Patient Root/Study Root, legacy Patient/Study Only
C-MOVE SCP/SCU Да, export/policy/scheduler Да Да, query/move и forwarding
C-GET SCP/SCU Да Да; C-GET SCP с 1.7.0 Поддержка есть в современных 1.5.x, проверить сборку
DICOM TLS Да Да Проверять конкретную сборку/reverse proxy
DICOMweb Archive REST/DICOMweb Официальный DICOMweb plugin Есть в актуальной ветке, проверить coverage
Storage Commitment Полный archive workflow Не эквивалентен встроенной dcm4chee-модели Нет сопоставимого встроенного workflow
MPPS Да, forwarding и procedure linkage Нет сопоставимой встроенной MWL/MPPS модели Нет сопоставимой встроенной модели

7. C-FIND: атрибуты поиска и возврата

В DICOM C-FIND ключ может быть matching key и/или return key. Required и Optional keys имеют разный контракт: optional key нельзя считать обязательным только потому, что он есть в dataset.

7.1. dcm4chee-arc Patient Root

dcm4chee прямо заявляет все required search keys на четырёх уровнях Patient, Study, Series, Image. Публикуется подробная таблица с тегом, VR и типами matching. По умолчанию нет “always returned” атрибутов: возвращаются ключи, присутствующие в query identifier.

Уровень Главные matching keys Типичные return keys
Patient PatientName (0010,0010), PatientID (0010,0020), IssuerOfPatientID (0010,0021), IssuerOfPatientIDSequence (0010,0024), PatientBirthDate (0010,0030), PatientSex (0010,0040) Patient demographics, SpecificCharacterSet, optional patient attributes
Study StudyInstanceUID (0020,000D), StudyDate (0008,0020), StudyTime (0008,0030), AccessionNumber (0008,0050), StudyID (0020,0010), StudyDescription (0008,1030), ReferringPhysicianName (0008,0090), ModalitiesInStudy (0008,0061) UIDs, dates, descriptions, patient keys, institution/physician, modality/counts
Series SeriesInstanceUID (0020,000E), Modality (0008,0060), SeriesNumber (0020,0011), SeriesDate/Time, SeriesDescription (0008,103E), BodyPartExamined (0018,0015), ProtocolName (0018,1030), StationName (0008,1010) Series UID/number/modality/description, equipment, counts
Image SOPInstanceUID (0008,0018), SOPClassUID (0008,0016), InstanceNumber (0020,0013), AcquisitionNumber, ContentDate/Time, ImageType, NumberOfFrames SOP UIDs, instance/image/acquisition/content attributes и optional object-specific keys

Поддерживаются hierarchical и relational queries, date range, fuzzy и timezone matching. Ограничение из CS: на Patient level PatientID должен иметь хотя бы partial value, если нет PatientName; на Study level при отсутствии partial study attributes нужен partial PatientID или PatientName. Это защита от запроса “вернуть всё”.

7.2. dcm4chee-arc Study Root

Study Root имеет Study, Series, Image. Все required search keys этих уровней заявлены. Patient attributes (PatientName, PatientID, birth date, sex) доступны на Study level. Для RIS важны AccessionNumber, StudyInstanceUID, dates, StudyDescription, Modality, SeriesInstanceUID, SOPInstanceUID, RequestedProcedureID, SPS-related attributes и counts.

7.3. Orthanc

Orthanc заявляет C-FIND SCP для Patient Root и Study Root и C-FIND SCU к remote modalities. Обычные Patient/Study/Series/Instance запросы работают, но публичной таблицы с полнотой dcm4chee (каждый optional key, VR и S,*,U,R,M) нет.

Быстрые REST-фильтры и выдача опираются на MainDicomTags; дополнительные быстрые tags задаются ExtraMainDicomTags. Полный dataset можно прочитать, но чтение файла не означает автоматически быстрый database-side matching по любому тегу.

Стандартный список MainDicomTags по официальной документации:

Уровень Tags
Patient PatientName, PatientID, PatientBirthDate, PatientSex, OtherPatientIDs
Study StudyDate, StudyTime, StudyID, StudyDescription, AccessionNumber, StudyInstanceUID, RequestedProcedureDescription, InstitutionName, RequestingPhysician, ReferringPhysicianName, TimezoneOffsetFromUTC плюс patient tags
Series SeriesDate, SeriesTime, Modality, Manufacturer, StationName, SeriesDescription, BodyPartExamined, SequenceName, ProtocolName, SeriesNumber, CardiacNumberOfImages, ImagesInAcquisition, NumberOfTemporalPositions, NumberOfSlices, NumberOfTimeSlices, SeriesInstanceUID
Instance Основные instance tags; полный набор через /instances/{id}/tags, индекс зависит от версии/настройки

Для стандартного RIS-поиска Orthanc обычно достаточен. Для RequestedProcedureID, SPSID, private tags, SR content, нестандартной anatomy или object-specific attributes понадобятся extra tags, plugin/script или внешний индекс.

7.4. Conquest

Conquest поддерживает Patient Root/Study Root и историческую Patient/Study Only модель. Базовые UID и required/unique keys для Patient, Study, Series и Image заявлены; многие optional keys поддерживаются. Но точный перечень зависит от версии, dicom.sql, database driver и dgatesop.lst. dicom.sql определяет поля, участвующие в query/retrieve, поэтому две установки Conquest с разными схемами могут иметь различную searchable surface.

Уровень Основные matching keys Return keys
Patient PatientName, PatientID, birth date/sex, issuer и стандартные patient keys Демография и counters, предусмотренные SQL layout
Study StudyInstanceUID, StudyDate/Time, AccessionNumber, StudyID, StudyDescription, patient keys Study/patient attributes, modality/counts и поля layout
Series SeriesInstanceUID, Modality, SeriesNumber, dates, description, body part, protocol Series/equipment/counts при наличии полей
Image SOPInstanceUID, SOPClassUID, InstanceNumber, acquisition/content keys SOP/image attributes из SQL layout и запроса

Это делает Conquest гибким, но менее предсказуемым для универсального RIS-клиента. Перед интеграцией нужно выполнить реальные C-FIND-запросы на конкретном сервере и проверить не только matching, но и возвращаемые attributes. Для SR ContentSequence (0040,A730) и вложенных sequences наличие объекта в storage не означает штатную индексацию.

7.5. Возвращаемые атрибуты

Вопрос dcm4chee-arc Orthanc Conquest
Политика C-FIND Только запрошенные return keys, согласно CS Core формирует response по уровню/запросу; REST tags возвращает больше Return keys зависят от запроса и dicom.sql
Полная published matrix Да, Patient Root/Study Root tables Нет в сопоставимой форме Исторический CS есть, но актуальная schema/config важнее
Полный dataset REST/WADO/экспорт /instances/{id}/tags, /file, DICOMweb DICOM retrieve/web/CGI; exact API зависит от версии
Расширение индекса Archive query configuration ExtraMainDicomTags Изменение dicom.sql с миграцией/регенерацией

Для формального договора interoperability dcm4chee удобнее: его таблица — явный контракт. Для собственного приложения Orthanc удобнее благодаря REST. Conquest может быть очень быстрым и гибким, но требует проверки фактической конфигурации каждой установки.

8. RESTful-сервисы

8.1. Orthanc

Orthanc имеет понятный API:

GET/DELETE /patients/{id}
POST       /patients/{id}/modify|anonymize
GET/DELETE /studies/{id}
POST       /studies/{id}/modify|anonymize|split|merge
GET/DELETE /series/{id}
POST       /series/{id}/modify|anonymize
GET/DELETE /instances/{id}
POST       /instances/{id}/modify|anonymize
POST       /instances              # upload DICOM

Удаление родителя удаляет дочерние resources по модели Orthanc. Modify/anonymize на patient/study/series создаёт изменённые objects и новую иерархию; для изменения PatientID/StudyUID/SeriesUID/SOPUID требуется Force. Поддерживаются bulk modify/anonymize, split/merge studies, changes log, peers, modalities и auto-routing.

DICOMweb plugin добавляет QIDO-RS, WADO-RS, STOW-RS и WADO-URI. Проект предупреждает, что это reference/basic implementation и полный DICOMweb standard реализован не целиком; для OHIF/Cornerstone следует проверить metadata mode (Full, MainDicomTags, Extrapolate) и конкретные запросы viewer.

8.2. dcm4chee-arc

REST/DICOMweb archive API покрывает поиск и получение patients/studies/series/instances, STOW/QIDO/WADO, MWL, linking study/series with MWL, export/retrieve, rejection, retention, storage verification, MPPS/UPS/IAN/storage commitment и configuration operations.

У dcm4chee изменение entity — не прямое редактирование строк БД: применяются archive update/coercion policies, чтобы согласовать индекс, storage и ссылки. Это безопаснее для clinical archive, но payload и URI необходимо брать из документации конкретной версии.

8.3. Conquest

Conquest предоставляет встроенный web/CGI-интерфейс, JSON/web extensions, DICOMweb и Lua server commands. Через web UI доступны database browser, query/move, maintenance, ограниченное редактирование, anonymization, удаление, splitting/merging series и отправка объектов. Однако это не настолько единый resource REST API, как у Orthanc: конкретные CRUD endpoints и payload зависят от версии, web scripts и конфигурации.

Для автоматизации RIS безопаснее использовать DICOMweb или собственный adapter поверх Conquest, предварительно проверив атомарность изменений, обновление SQL index, изменение UID и поведение при параллельном C-STORE.

CRUD dcm4chee-arc Orthanc Conquest
Patient REST/HL7 workflows, patient update/delete Обычно создаётся загрузкой DICOM; modify/delete/anonymize Web/CGI/Lua/database tools; uniform REST CRUD нужно проверить
Study STOW и archive REST; MWL/order workflow Загрузка instance; modify/delete/anonymize/split/merge Web/DICOMweb/скрипты; не полноценная order entity
Series Archive REST/DICOMweb modify/delete/anonymize Web tools, split/merge и Lua
Instance C-STORE/STOW/REST, export/reimport POST/GET/DELETE/modify/anonymize C-STORE/DICOMweb/CGI/Lua
Пустая clinical entity Через order/MWL workflow Обычно не создаётся отдельно от DICOM object Обычно через MWL, не через полноценную clinical study entity

9. MWL, HL7 и уведомления

9.1. dcm4chee-arc MWL/HL7

Поддерживаются:

  • DICOM MWL C-FIND SCP;
  • creation scheduled procedure steps через REST;
  • HL7 ORM^O01, OMI^O23, OMG^O19 через XSLT;
  • ADT/patient demographics;
  • generators для Accession Number, Requested Procedure ID и SPS ID;
  • SPS state и linking study/series with MWL;
  • MPPS-driven updates;
  • ORU^R01 action MWL_COMPLETED;
  • HL7 Procedure Status Update с message type, template и conditions;
  • matching по Study UID, Accession Number, RequestedProcedureID или configured key.

Это order/procedure model, а не просто набор .wl файлов. Поэтому dcm4chee лучше переносит отсутствие MPPS, delayed report, разные vendor matching rules и повторные сообщения.

9.2. Orthanc MWL

В legacy sample plugin worklists — DICOM .wl files в каталоге; внешнее приложение создаёт/меняет/удаляет файлы. Новое Worklists plugin документирует REST:

POST   /worklists/create
GET    /worklists/{id}
DELETE /worklists/{id}
GET    /worklists/?format=Simplify|Short|Full

В payload передаются DICOM tags и ScheduledProcedureStepSequence; MWL C-FIND предоставляется plugin. Это хороший DICOM worklist provider, но не встроенная HL7 order database.

HL7 ORM/OMI/OMG, ADT, MPPS-to-MWL linkage, PSU scheduler, idempotency и reconciliation обычно реализуются внешним HL7 listener/sender и вызовами Worklists REST API. Для RIS это означает больше собственного кода, но и больше свободы.

9.3. Conquest MWL и HL7

Conquest предоставляет простую DICOM MWL implementation и HL7 import с configurable translation. В worklist database могут храниться дополнительные HL7 tags, используемые для преобразования входных сообщений в DICOM worklist. Это подходит для небольшого RIS или локальной модальности, но не заменяет dcm4chee order/procedure engine: нет сопоставимого встроенного MPPS/PSU lifecycle, scheduler и enterprise reconciliation model. Для сценариев с различиями AccessionNumber и Study UID потребуется внешний adapter.

9.4. Уведомления

dcm4chee-arc: HL7 PSU, ORU^R01, HL7 forwarding/merge, IAN, MPPS forwarding, Storage Commitment, audit events и schedulers с retry. Для HTTP обычно используются REST/DICOMweb и внешний интеграционный сервис; универсальный webhook на каждое событие нужно проектировать отдельно.

Orthanc: /changes, Lua OnStoredInstance, OnStablePatient/Study/Series, HttpPost/Put/Get, Python callbacks, peers/modalities и auto-routing. HTTP webhook сделать легко, но outbox, retry, deduplication, подписывание и критерий “study completed” нужно реализовать самостоятельно. HL7 в ядре отсутствует и добавляется внешним adapter/plugin.

Conquest: Lua callbacks/server commands, forwarding, processing и web scripting позволяют вызвать HTTP endpoint, отправить объект на DICOM AE или сформировать внешний event. Готового эквивалента dcm4chee HL7 PSU/IAN/Storage Commitment/audit scheduler нет. Для надёжных уведомлений нужен внешний outbox/adapter с retry, ACK и deduplication.

10. Безопасность и зрелость

dcm4chee-arc

Keycloak/OIDC, LDAP, роли, TLS, audit profiles, access control, retention, rejection и lifecycle policies дают хорошую основу enterprise PACS. Цена — сложность WildFly/LDAP/Keycloak и необходимость контролировать версии и сертификаты.

Orthanc

Простая Basic auth, HTTPS/reverse proxy, Authorization plugin, Lua/Python policies и небольшая поверхность установки. Но multi-tenant security, audit, RBAC и клинические workflow нужно проверять и собирать самостоятельно. RemoteAccessAllowed без TLS, ACL и authentication публиковать нельзя.

Conquest

Conquest имеет web login и может размещаться за TLS reverse proxy, но по встроенной модели безопасности существенно проще dcm4chee. Для production нужно отдельно обеспечить RBAC/изоляцию, audit, TLS, ACL, backup и контроль Lua/web scripts. Наличие web interface не является готовой enterprise security model.

11. Поддержка и сообщество

Источник dcm4chee-arc Orthanc Conquest
Документация ReadTheDocs CS, wiki, Docker repos Orthanc Book, OpenAPI/REST, dynamic CS, plugin docs Site, manuals, GitHub files; часть документации историческая
Исходники/issues GitHub dcm4che/dcm4chee-arc-light Open-source Orthanc ecosystem, GitHub/mercurial repositories GitHub Conquest-DICOM-Server
Сообщество dcm4che mailing list/Google Group, GitHub issues Mailing list/forum, GitHub issues Forum/GitHub, сообщество меньше
Коммерческие услуги Интеграторы и специалисты dcm4che Orthanc Team, официальные plugins/services Специализированная поддержка ограничена
Для разработчика Глубоко, но Java/WildFly/LDAP сложны Очень удобно REST/Lua/Python/C++ SDK Очень гибко через Lua, но CGI/config менее унифицированы
Formal evidence Сильнее: подробные CS tables Хорошая базовая документация, сложные keys надо тестировать Исторический CS + проверка фактической schema/config

Оба решения пригодны для production, но open source не означает SLA. Нужны мониторинг, backup, disaster recovery, staged upgrades, audit и тесты восстановления.

12. Нагрузки и рекомендации

Выбирать dcm4chee-arc, если:

  • центральный архив нескольких клиник или десятков модальностей;
  • HL7 ORM/ORU/ADT и MWL — часть основного workflow;
  • нужны MPPS, PSU, IAN, Storage Commitment;
  • есть сложные retention/export/rejection/audit policies;
  • требуется formal SOP/C-FIND conformance matrix;
  • нужны многие viewer/client systems и DICOMweb;
  • команда готова сопровождать PostgreSQL, LDAP, WildFly и Keycloak.

Выбирать Orthanc, если:

  • нужен локальный PACS или edge node;
  • нужен DICOM router/normalizer/anonymizer;
  • нужен REST backend собственного RIS/viewer;
  • нужен research archive или быстрый integration prototype;
  • HL7/order logic уже есть во внешнем RIS;
  • важнее простота и скорость разработки, чем встроенный enterprise workflow.

Выбирать Conquest, если:

  • нужен очень лёгкий локальный PACS, cache или DICOM router;
  • важны Lua-forwarding, filtering, processing и compression;
  • требуется простая MWL с HL7 import translation;
  • достаточно web/CGI/DICOMweb без сложной multi-tenant archive model;
  • команда готова самостоятельно тестировать SQL layout, scripts, security и recovery.

Conquest не следует выбирать центральным enterprise PACS только по низким требованиям к ресурсам: его production-профиль сильнее зависит от конкретной конфигурации и собственного тестирования.

Orthanc можно масштабировать несколькими экземплярами с PostgreSQL/MySQL и shared storage, но это не следует автоматически считать HA: необходимы health checks, locking, backup, storage semantics, idempotency и fault-injection tests.

Нагрузку нужно измерять по peak C-STORE, instances/study, размерам CT/MR/video/whole-slide, parallel associations, QIDO/WADO traffic, exports, HL7 events, backup window и RTO/RPO. Load test должен использовать реальные DICOM datasets и включать отказ БД, заполнение storage, повторную отправку SOP UID и восстановление.

13. Практические риски

dcm4chee-arc

  • успешный UI не доказывает исправный DICOM/HL7 workflow;
  • потеря LDAP volume означает потерю конфигурации;
  • неверные Keycloak roles могут дать пустой UI;
  • schema/archive upgrade нужно выполнять по инструкции конкретной версии;
  • медленный PostgreSQL/NFS становится узким местом;
  • неправильный HL7 PSU может создавать зависшие tasks;
  • optional query keys без индексов могут перегрузить БД.

Orthanc

  • SQLite не годится как центральная БД с несколькими writers;
  • Orthanc UUID не равен PatientID/StudyInstanceUID;
  • для viewer могут понадобиться ExtraMainDicomTags;
  • Worklists plugin не заменяет HL7 order engine;
  • DICOMweb plugin не означает полную реализацию стандарта;
  • webhook без outbox/retry/idempotency теряет события;
  • изменение UID/PatientID без Force и проверки ссылочной целостности опасно.

Conquest

  • dicom.sql нельзя менять без понимания миграции и regeneration;
  • точный C-FIND key set зависит от schema/configuration;
  • web/CGI API менее унифицирован, чем REST Orthanc;
  • Lua callback без outbox/retry может терять уведомления или создавать дубликаты;
  • proprietary compression может ухудшить совместимость с внешними tools;
  • простой web login не заменяет RBAC/audit/TLS/изоляцию;
  • принимать сложные SOP Classes без реального dataset test опасно.

14. Рекомендованная архитектура

null

Смешанная схема часто наиболее практична: Orthanc или Conquest выполняют локальный buffer, routing и vendor-specific adaptation, а dcm4chee-arc остаётся центральным архивом, MWL/HL7 engine и точкой формального DICOM/IHE-соответствия. Orthanc удобнее как современный REST/DICOMweb edge, Conquest — как очень лёгкий Lua-scriptable cache/router.

15. Источники

  1. dcm4chee-arc-light: официальный репозиторий — WildFly, Java 17+, варианты БД, wiki и issues.
  2. dcm4chee-arc Docker image — LDAP, PostgreSQL, Java heap, Keycloak и параметры контейнера.
  3. dcm4chee-arc DICOM Conformance: Query/Retrieve — SOP Classes, уровни, matching/return keys.
  4. dcm4chee-arc Storage specification.
  5. dcm4chee-arc Archive Device configuration — MWL generators, HL7 ORU и PSU.
  6. dcm4chee-arc security/audit profiles.
  7. Orthanc Book: REST API.
  8. Orthanc: anonymization and modification.
  9. Orthanc: Main DICOM Tags.
  10. Orthanc: DICOM guide.
  11. Orthanc: scalability.
  12. Orthanc DICOMweb plugin.
  13. Orthanc Worklists plugin.
  14. Orthanc legacy Worklists plugin.
  15. Orthanc dynamic DICOM Conformance Statement.
  16. Orthanc documentation and support.
  17. DICOM PS3.4 Query/Retrieve.
  18. Conquest DICOM software: официальный сайт — DICOM, базы данных, MWL/HL7 import, Lua, web и DICOMweb.
  19. Conquest DICOM Server: GitHub — исходный код, service file и manuals.
  20. Conquest Linux manual.
  21. Conquest Windows manual — dicom.ini, acrnema.map, dicom.sql, web/CGI и service model.
  22. Conquest DICOM Conformance Statement 1.4.14 — исторический CS; для 1.5.x необходима проверка конкретной сборки и конфигурации.

01.04.2023 Статьи

Что такое Заявление о соответствии стандарту DICOM?

Некоторые поставщики и заказчики медицинской аппаратуры, заявляя в своей документации о соответствии стандарту Dicom, не понимают о чем, собственно заявляют, как собственно необходимо "заявлять" и что такое вообще "Заявление о соответствии стандарту Dicom". Краткий ликбез на эту тему.

Перевод статьи Bimba Shrestha с исправлениями и дополнениями.

Стандарт DICOM сложен, и разные медицинские устройства поддерживают его в разной степени. Например, компьютерный томограф может поддерживать определенный набор функций DICOM, а архив изображений (PACS) может поддерживать другой. Оба устройства совместимы с DICOM, но если они не поддерживают определенные дополнительные функции, они не будут работать вместе.Что это означает для покупателей, продавцов и пользователей медицинского оборудования? Это означает, что не каждое DICOM-совместимое устройство обязательно будет взаимодействовать с другим DICOM-совместимым устройством!Здесь вступает в действие Заявление о соответствии стандарту DICOM ( DICOM Conformance Statement — DCS). DCS — это подробный технический ДОКУМЕНТ, сопровождающий большинство устройств, в котором точно указывается КАКИЕ конкретно функции стандарта поддерживаются. Возвращаясь к нашему примеру, в Заявлении о соответствии стандарту КТ-сканера должно быть указано, что он поддерживает функции, перечисленные как требуемые в Заявлении о соответствии стандарту архива изображений, чтобы они могли работать вместе.
SOP, SCU и SCP
DCS используют множество специфических терминов. Некоторыми распространенными из них являются SOP (пара объектов службы), SCU (пользователь класса службы) и SCP (поставщик класса службы). Эти термины имеют очень специфические значения в стандарте DICOM, но на данный момент вы можете думать о SOP как о «некоторой желательной функции устройства», а SCU/SCP — как о дополнительных частях этой функции. Половина SCP обеспечивает функцию, а половина SCU использует ее.Чтобы продолжить наш предыдущий пример: чтобы компьютерный томограф мог отправлять изображения в архив изображений он должен быть SCU для SOP «Хранение изображений CT», а архив изображений должен быть SCP для него. Если обе половины этой функции отсутствуют, два устройства не будут работать вместе. Даже если они оба помечены как совместимые с DICOM!DCS (среди прочего) — это список поддерживаемых SOP, определенных как роли SCU/SCP. Сравнив этот список между устройствами, вы сможете определить их совместимость.Также смотрите ликбез системному администратору на эту тему.
Структура DCS
Несмотря на сложность, большинство DCS имеют одинаковую структуру документов. Это сделано намеренно, и разработчики стандарта DICOM приложили большие усилия, чтобы предоставить подробные шаблоны для DCS. Вот высокоуровневая структура DCS (подробности смотрите в официальном стандарте ) :
  • Титульная страница : первая страница, содержащая название устройства и дату.
  • Обзор заявления о соответствии : описание устройства непрофессионалом.
  • Оглавление
  • Введение : общая информация, соответствующие отказы от ответственности и условия.
  • Сеть : Описание услуг, связанных с сетью.
  • Медиа-обмен : Описание несетевых служб обмена.
  • Поддержка наборов символов : какие наборы символов и кодировки поддерживаются (подробнее о проблемах кириллических кодировок см. в описании программы Dicom AutoExport).
  • Безопасность : Соответствующие вопросы безопасности, описания и заявления об отказе от ответственности.
  • Приложения
Для покупателей медицинского оборудования
Если вы являетесь покупателем, оценивающим медицинское устройство, вам всегда следует запрашивать DCS. Как упоминалось выше, то, что устройство совместимо с DICOM, ещё не означает, что оно обязательно будет работать с вашими существующими информационными системами. Например, вот несколько случаев, в которых что-то может пойти не так, если вы не изучите подробно DCS поставщика:

  • Если вы покупаете устройство, которое не поддерживает SOP SCP для проверки DICOM, вы никогда не сможете проверить подключение DICOM к этому устройству с другого устройства DICOM. Сообщения с подтверждением, отправленные на него, останутся без ответа, как будто устройство либо не существует, либо имеет разорванное сетевое соединение.
  • Если вы покупаете архив, который поддерживает SOP SCP хранилища MR, это не означает, что он должен поддерживать SOP SCP хранилища CT, и вы, возможно, не сможете перенести свои данные CT в тот же архив.
  • Если у вас есть рабочая станция, которая поддерживает C-Find (Query) SCU, но не поддерживает C-Find (Query) SCP, вы никогда не сможете запросить эту рабочую станцию ​​с другой рабочей станции или из архива. Только SCP-запросы могут отвечать на запросы, передавая эти ответы другим устройствам.
  • Если вы покупаете телерадиологический сервер DICOM, который не поддерживает сжатие изображений для передачи изображений C-Store, вы не сможете отправлять сжатые изображения. И т. д. ...

Список потенциальных проблем длинный, поэтому будьте внимательны и всегда просите DCS.

Для продавцов медицинского оборудования
Если вы являетесь продавцом медицинского оборудования, в ваших же интересах поставлять свой продукт с сопроводительной DCS. Это единственный способ, которым ваши потенциальные клиенты могут оценить совместимость вашего устройства с их существующей настройкой.

 Пример Заявления о соответствии:

Сервер XrayPACS. Заява про відповідність стандарту Dicom

 

01.04.2023 Статьи

Почему существует стандарт DICOM?

О назначении стандарта. Просто для начинающих.

Перевод статьи David Giese с некоторыми моими дополнениями и уточнениями.

Стандарт DICOM предназначен для облегчения взаимодействия между системами медицинской визуализации от разных поставщиков. Стандарт определяет формат файла для хранения медицинских изображений, протоколы, чтобы приложения могли ими обмениваться, и формат соответствия, чтобы покупатели могли определить, какие системы могут (надеюсь) взаимодействовать. Но, возможно, самое главное, DICOM обеспечивает стандартизированную модель реальности. Эта информационная модель является основой, в которой заложена интероперабельность, т. е. способность продуктов или систем взаимодействовать и функционировать с другими продуктами или системами без каких-либо ограничений доступа и реализации.

Что такое DICOM?

Стандартный документ DICOM имеет краткое описание области применения в разделе 1.1 стандарта :

Цифровая визуализация и коммуникация в медицине (DICOM) — это стандарт для передачи и управления информацией о медицинских изображениях и связанными с ними данными. Стандарт DICOM облегчает взаимодействие медицинского оборудования для визуализации, определяя:

  • Для сетевой связи - набор протоколов, которым должны следовать устройства, заявляющие о соответствии Стандарту.
  • Синтаксис и семантику команд и связанная с ними информация, которой можно обмениваться с использованием этих протоколов.
  • Для медиа-коммуникации - набор услуг хранения медиа, которым должны следовать устройства, заявляющие о соответствии Стандарту, а также формат файла и структура медицинского каталога для облегчения доступа к изображениям и связанной с ними информации, хранящейся на обменном носителе.
  • Информацию, которая должна быть предоставлена ​​с реализацией, для которой заявлено соответствие Стандарту.

DICOM обеспечивает совместимость в двух смыслах. Во-первых, это облегчает техническую «синтаксическую» совместимость:

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

Разработка программного обеспечения, которое точно следует этим техническим деталям, может быть сложной задачей. К счастью, есть несколько приличных библиотек, которые очень помогают в этом.

Помимо чисто технической совместимости, DICOM также способствует «семантической» совместимости.

Семантическая совместимость

Эта общая модель реальности облегчает взаимодействие, потому что без нее у разных поставщиков, вероятно, были бы слегка (или радикально) разные модели реальности, что затрудняло бы взаимодействие.Например, один поставщик может не утруждать себя включением объекта «Исследование» в свою модель реальности, а другому поставщику могут потребоваться определенные фрагменты данных, которые другой поставщик опускает. В обоих случаях интеграция оборудования и программного обеспечения от этих двух разных поставщиков будет более сложной, а в некоторых случаях и невозможной.

Основная проблема в том, что реальность сложна!

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

Фактически, сам DICOM признает, что его модель не идеальна.

Эта информационная модель представляет собой упрощение реальных концепций и действий медицинской визуализации; для модальностей сбора исследование приблизительно эквивалентно упорядоченной процедуре, а серия приблизительно эквивалентна выполненному элементу протокола сбора данных. В других областях, таких как лучевая терапия, исследование и серия менее четко связаны с реальными объектами или действиями, но все же необходимы для согласованности. Эта упрощенная модель достаточна для прагматических нужд управления изображениями и соответствующими данными, собранными в повседневной практике.

К счастью, несмотря на эти упрощения, модель DICOM довольно хороша. И, на наш взгляд, гораздо лучше иметь одну бракованную модель, чем десятки бракованных моделей — по одной на каждого производителя!

Конечно, DICOM не устраняет полностью проблемы интеграции по нескольким причинам:

  1. Приложения не реализуют должным образом стандарт
  2. Приложения реализуют разные версии стандарта
  3. Большая часть метаинформации является необязательной (поэтому приложение может не предоставлять ее).
  4. Стандарт неоднозначный.

Еще раз, DICOM достаточно осведомлен , чтобы сообщить вам о своих ограничениях , если вы не можете сделать вывод самостоятельно:

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

Вывод
Цель стандарта DICOM — облегчить взаимодействие между системами медицинской визуализации от разных поставщиков. Это достигается за счет стандартизации технических деталей реализации сети и хранилища, но, возможно, что более важно, за счет предоставления согласованной модели реальности.
10.07.2022 Статьи

DICOM: цифровые снимки в медицине — ликбез для системного администратора

Одним из самых компьютеризированных разделов медицины является радиодиагностика. Медицинские исследования генерируют большое количество данных, которые затем обрабатываются передовыми методами визуализации, 3D-реконструкции по срезам и даже машинного обучения. Этот топик призван помочь системным администраторам погрузиться в тематику передачи и хранения медицинских изображений.
Авторские права на данную статью принадлежат Владиславу Россу - gag_fenix . Она была недавно опубликована на популярном у программистов, админов и широкого круга околокомпьютерной публики веб-сайте — https://habr.com/ru/post/217761/ А здесь публикуется с любезного разрешения её автора с некоторыми сокращениями и моими комментариями.

0920b6d7c1c8d090551342d4ec3ea3a1

Фото автора

Техминимум

DICOM (Digital Imaging and Communications in Medicine) — стандарт обработки, хранения, передачи, печати и визуализации медицинских изображений. DICOM определяет формат файлов радиологических исследований и сетевой протокол, который в качестве транспорта использует TCP/IP. DICOM разрабатывается с 80-х годов, ежегодно обновляется, став на сегодняшний день стандартом де-факто — поддерживается всеми современными цифровыми устройствами: томографами, УЗИ-аппаратами, маммографами, рентгеновскими аппаратами и т.д.

Основная «фишка» DICOM — интероперабельность. За счет различных механизмов DICOM позволяет передавать данные между очень разным медицинским оборудованием и ПО.

Сама спецификация протокола интересна в первую очередь разработчикам медицинского софта. Мы рассмотрим основные моменты, касающиеся эксплуатации с точки зрения ИТ-отдела, не углубляясь в дебри.

c01b3d7f26b35dd60d320cf0d822f629

 

Информация о пациенте и запланированном исследовании поступает на аппарат из радиологической информационной системы. По завершении диагностики аппарат уведомляет РИС и отправляет снимки в центральный архив. Рентгенолог получает снимки на рабочую станцию (со специально откалиброванным монитором) и составляет заключение. Пациенту файлы исследования могут быть записаны на диск или распечатаны.

Основные понятия

Modality (модальность) — медицинский аппарат, создающий (acqusition) медицинское изображение определенного типа. Типы обозначаются аббревиатурой, например:

CR Рентгенография
CT Компьютерная томография (КТ)
MG Маммография
MR Магнитно-резонансная томография (МРТ)
PT Позитронно-эмиссионная томография (ПЭТ)
US Ультразвуковая диагностика (УЗИ)
XA КТ-ангиография
SC Secondary capture — импорт из не-DICOM источника (например, сканирование пленки)
SR Структурированный текстовый отчет
OT Прочее

PACS — Picture Archiving and Communication System — центральный сервер хранения медицинских изображений в организации, который получает исследования от модальности и по запросу выдает на рабочие станции радиологов или в другие отделения. Может быть интегрирован с RIS и/или HIS;

HIS — Hospital Information System — медицинская информационная система (МИС) — общая система электронного документооборота мед. учреждения;

RIS — радиологическая информационная система (РИС) — система информатизации диагностического отделения, содержащая данные от пациентов, расписание приёма на исследование и т.д.

DICOM-файл — файл (стандартное расширение .dcm), содержащий графическую информацию, а также метаданные. Для большинства модальностей в одном файле хранится единственное изображение, но иногда это может быть серия кадров. Используются различные алгоритмы сжатия: Lossy JPEG, JPEG2000 или Loseless JPEG. Также DICOM поддерживает хранение waveform данных (ЭКГ, аудио).

Файл является нижним элементом иерархии: пациент (patient) → исследование (study) → серия (series) → изображение (image/instance).

В тегах каждого файла хранятся атрибуты с информацией о самом изображении, а также об объектах верхнего уровня, в т.ч.:

  • patient demographics — персональные данные пациента: ФИО с разделителем кареткой (??????^????^?????????), возраст: число и буква (0???), пол (M/F/O), вес и т.д.;
  • уникальный идентификатор (UID) study и series по ISO 8824;
  • patient ID;
  • модальность;
  • сведения о медицинском учреждении, ФИО радиолога;
  • дата и время обследования;
  • марка и модель аппарата;
  • другая информация об исследовании; полный список можно посмотреть тут.

Анонимизация (anonymize) — функция удаления персональных данных из DICOM-файлов;

DICOMDIR — файл с метаинформацией о снимках в папке. Используется при записи снимков на CD/DVD;

SCU (Service Class User) и SCP (Service Class Provider): в терминологии DICOM SCU инициирует запрос, а SCP предоставляет ему сервис. Иначе говоря, SCU — клиент, а SCP — сервер. При этом один и тот же узел DICOM может быть в каких-то случаях SCU (например, когда он запрашивает список), а в каких-то SCP (когда получает снимки);

AE — Application Entity — отдельный сервис DICOM. В простом случае на физическом устройстве (станции, PACS, модальности) «живет» один AE, но по стандарту их может быть и несколько, в т.ч. на одном TCP-порте;

AE Title — название узла (AE), уникальное в сети, до 16 символов ASCII, обычно заглавными. Бо́льшая часть DICOM-софта работает в режиме whitelist, т.е. обмен данными разрешается только с AE, заранее занесенными в список. Как правило, для успешной передачи снимков на обоих сторонах в ПО нужно указать IP, порт и AE Title;

IOD — Information Object Definition — шаблон, определяющий список атрибутов для объектов реального мира. Для атрибутов задается тип данных, длина и флаг множественности. Для повторного использования атрибуты группируются в модули. Например, атрибут Patient's Birth Date входит в модуль Patient, который используют разные IOD. Если IOD содержит модули для нескольких объектов, он называется композитным (composite). Например, IOD снимка томографа содержит не только само изображение, но также наследует информацию о пациенте, исследовании, серии, frame of reference и оборудовании. IOD и команда комбинируются в SOP Class (Service Object Pair), например, класс «CT Storage» — это комбинация команды C-Store и КТ-изображения. Подробно останавливаться на модели данных DICOM мы не будем; отсылаю интересующихся к литературе в конце.

Transfer syntax — режим кодирования информации при передаче, задает порядок бит implicit/explicit little/big endian, формат сжатия графики. Иногда его приходится указывать явно;

Association — процесс установления сетевой сессии в DICOM; подразумевает обмен информацией о поддерживаемых Abstract и Transfer syntax. Ошибка на этапе Association говорит либо о неверных настройках TCP или AE Title либо о несовместимом Transfer syntax или неподдерживаемом/отключенном в софте SOP;

DICOMweb — стандарт REST-API для просмотра снимков через web.

Сервисы DICOM

Сервисы DICOM обеспечивают взаимодействие модальностей, PACS, RIS и рабочих станций по сети, поддерживая набор композитных операций над объектами (DIMSE):
C-STORE — отправка снимков с SCU на SCP («пуш»), например, с аппарата в архив;
C-GET — получение снимков от SCP на SCU («пулл»), например, из архива на рабочую станцию;
C-FIND — поиск исследований по атрибутам (например, ФИО пациента, дате и др.);
C-MOVE — запрос от SCU на отправку снимков с SCP на какой-то третий хост (который может быть самим SCU); SCP должен «знать» AE Title хоста назначения;
C-ECHO — проверка связи («пинг»).

Подробнее об операциях DICOM можно почитать в топике [6].

Сервис Query/Retrieve (Q/R) комбинирует C-FIND и C-MOVE (реже C-GET) для поиска объектов на SCP с последующим получением на SCU.

Сервис Storage предназначен для согласования и передачи объектов от SCU к SCP с помощью команды C-STORE. При этом на принимающей стороне (SCP) может производиться процесс добавления/изменения информации Coercion, если какие-то из обязательных атрибутов не заполнены, например автоматически генерироваться Patient ID.

Modality Worklist (MWL) — предварительное получение информации о пациенте, для которого запланировано исследование, из RIS на модальность. Таким образом, специалист, проводящий исследование, избавляется от необходимости заполнять эту информацию вручную, что экономит его время и уменьшает количество ошибок.

MPPS (Modality Performed Procedure Step) — фиксация статусов проведенных исследований, количества изображений, полученной дозы радиации и т.п. в RIS.

Print — печать hard copy снимка на пленочном принтере.
Администрирование DICOM

PACS-сервер

В самом примитивном случае никакого центрального сервера вообще нет. Снимки с аппаратов сыпятся на рабочие станции, а врачи гоняют их между компьютерами в одноранговой сети. Такой подход по понятным причинам является тупиковым.

Необходимо выделение центрального архива — PACS, который будет круглосуточно обеспечивать доступ к полному собранию обследований. Если выбор PACS лежит на ИТ-отделе, стоит обратить внимание на бесплатные проекты:

  • dcm4chee — open-source PACS на Java с web-интерфейсом. Работает на Linux, Mac OS X или Windows.
  • Orthanc — легковесный и быстрый open-source mini-PACS под Linux, Mac OS X или Windows, написанный на С++. Поддерживает REST API и систему плагинов;
  • Dicoogle — еще один кроссплатформенный open-source PACS;
  • microsoft/dicom-server — облачное решение от Microsoft, можно развернуть локально в Docker, но, кажется, что оно заточено под небесплатный Azure;
  • PacsOne — freeware (до 1 млн. снимков) PACS для Windows/Mac/Linux;

Из перечисленных PACS я работал только с dcm4chee (но на всех трёх платформах). По своему опыту могу сказать, что он способен обслуживать крупные архивы, а для конфигурирования доступна масса параметров — в Tomcat и XML-файлах. К сожалению, не все из них хорошо задокументированы, поэтому приходилось обращаться за помощью на форум.

Финальным шагом автоматизации является интеграция PACS с RIS/HIS с реализацией MWL и MPPS. Без интеграции с общей системой архив PACS быстро превращается в «кашу»: данные пациента вводят на аппарате непосредственно перед исследованием, поэтому нет сквозного ID пациента, а ФИО часто заводится транслитом (*т. к. аппаратура, производящая снимки, использует нестандартную для Dicom кодировку символов кириллицы. Например, win-1251. Для исправления кодировки в таких файлах существует программа Dicom AutoExport . Прим. Александра Кузнецова — А.К.). В результате потом невозможно автоматически сопоставить исследование и историю болезни: например, Юлия Жукова из общей HIS может числиться в PACS как Yuliya Zhukova, Julia Jukova или даже Iulia Dzukova. До кучи появляются опечатки. Если же на аппарат будут автоматически приходить данные пациентов из RIS/HIS, то такой проблемы не возникнет.

Сеть

Пропускная способность сети должна быть не ниже 1 Гбит/c. Используйте выделенную локальную сеть, лучше всего физически изолированную от других сетей и Интернет или хотя бы в отдельном VLAN. Для увеличения скорости и надежности подключения PACS-сервера можно использовать bonding.

Что может затруднить задачу построения сети для радиологии: файрволлы или трансляция адресов между модальностями/станциями, динамические адреса, динамическое назначение порта в операции C-GET.

Стандартные TCP-порты DICOM: 104, 11112, 2762 (TLS).

Хранилище

Основная нагрузка на аппаратное обеспечение PACS ложится на диски.
Хранилище необходимо проектировать, исходя из двух параметров:
а) Необходимого интервала хранения архива. (*Для разных категорий исследований устанавливаются разные сроки храненения — от трех до десяти лет, и даже пожизненно— для некоторых видов патологий. Прим. А.К).
б) Количества поступающих новых данных в единицу времени. Эта величина сильно зависит от количества и типов оборудования, а также режима работы конкретного ЛПУ. (*Обычно самый большой размер имеют ангиографические исследования (видео), затем МРТ и КТ (много срезов), флюороскопия (многокадровые серии), маммография (т. к. изображения имеют высокое разрешение), затем рентгенография. Всё остальное «весит» значительно меньше. Прим. А.К.)

Таким образом, главной головной болью администратора является построение относительно большого по объему хранилища с высокой степенью надежности. Требования же к пропускной способности и IOPS не столь существенны, если клиентов (модальностей и рабочих станций) не очень много. В большинстве случаев подойдут обычные (СMR) жесткие диски (кажется, что диски с черепичной PMR записью плохо подходят для DICOM, но у нас опыта с ними не было). Однако современные PACS при желании позволяют организовать и многоуровневое хранилище, например: свежие снимки на SSD → архив на HDD → «холодный» архив на ленте или S3.

Если сервер, который выделили под PACS, не может вместить необходимое количество дисков (например, он одноюнитовый), решением может стать закупка СХД или дисковой полки, подключаемой к серверу.

Тут нужно отдельно отметить, что PACS, как правило, ведут реляционную базу данных с пациентами, исследованиями и снимками. Вот её, возможно, стоит хранить на быстром хранилище на SSD или HDD RAID0, чтобы ускорить Q/R поиск по большому архиву.

Обеспечение надежности и резервное копирование

Как следует из предыдущего пункта снимки нужно хранить до 10 лет, а рядовой жесткий диск может прожить значительно меньше. Стандартным способом увеличения надежности является использование RAID-массива. Если позволяет бюджет, то для обеспечения наилучшей производительности рекомендуется использование уровня RAID10, которые требует х2 пространства хранения и выдерживает отказ, как минимум, одного диска. Более бюджетным, но менее производительным является уровень RAID6, который выдержит отказ двух дисков. Уровни RAID0 и RAID5 использовать не рекомендуются из-за низкой надежности. Хранилище без RAID (JBOD) можно использовать только, если у вас есть вторая полная резервная копия архива.

Важно: используйте hot-spare диски или держите оперативный запас дисков того же объема на складе на случай отказа одного из HDD.

Немаловажным аспектом использования RAID является резервирование RAID-контроллера. Если используется аппаратный RAID, существует ли надежный план восстановления в случает отказа контроллера? Есть ли на складе идентичная модель? Возможно, стоит сразу использовать софтверный RAID, у которого не будет проблем с восстановлением на другой машине?

Желательно использовать сервера с двумя блоками питания, питающимися от разных фаз/вводов. Необходимо наличие ИБП. Если сервер/ИБП конструктивно может быть запитан только от одного источника, то для повышения надежности можно использовать специальный PDU с возможностью питания от двух источников.
Старая админская мудрость гласит, что использование RAID не является заменой резервному копированию. Вообще стандарт DICOM не поддерживает операций удаления из архива, поэтому уничтожения данных из-за ошибки оператора, как правило, можно не бояться. Однако существуют другие опасности, например, разрушение файловой системы, отказ нескольких дисков или физическое уничтожение сервера в результате пожара, затопления и т.п. серверного помещения. В таких случаях может спасти только настоящий бекап.

Для восстановления PACS нужно сохранять дамп БД и резервную копию файлов исследований. Особенностью DICOM в данном случае является то, что PACS, как правило, хранят каждый снимок отдельно, так что на диске будут лежать миллионы мелких файлов. В результате полный бекап десятилетнего хранилища может занять дни или даже недели. Возможно, для снимков оптимальной стратегией будет разово сделать полную копию и настроить инкрементальное резервное копирование, например, раз в сутки. Хорошей новостью является то, что файлы DICOM обычно неплохо сжимаются, поэтому бекап может занимать значительно меньше места, чем оригинал.

Несколько лет назад мы заводили для резервного копирования open source ПО Bacula и роботизированную ленточную (LTO) библиотеку. В 2022 году уже кажется, что исходя из совокупной стоимости владения и простоты администрирования для бекапа предпочтительно использовать обычный сервер с HDD. При этом желательно, чтобы архивная копия физически находилась как можно дальше от основного PACS на случай пожара: в другом корпусе, на другом этаже или хотя бы в другом помещении. Не стоит делать бекап на тот же сервер, где «живёт» PACS — это серьезно его «обесценивает».

Нужно помнить, что авария центрального хранилища может привести к приостановке лечебной деятельности, поэтому разумно завести PACS горячего резерва на отдельной физической машине. Основной PACS следует настроить на автоматическую отправку свежих снимков на резервный. В принципе такой «брат-близнец» может быть альтернативой резервному копированию. Если же бюджет не позволяет зеркалировать архив за всё время, можно держать в горячем резерве только свежие исследования, например за последний месяц. Т.к. клиентов обычно не так много, не обязательно держать настоящий балансер (типа HAProxy) на случай отказа — достаточно оповестить медицинский персонал, что есть резервный архив, которым они могут пользоваться, и завести его AE Title на всех локальных узлах.

Наконец, немаловажным элементом устойчивой эксплуатации является мониторинг. Помимо использования обычного шаблона мониторинга аппаратного обеспечения и ОС для PACS-сервера, следует обратить пристальное внимание на мониторинг сервиса PACS и его резерва (с помощью утилит отправки C-ECHO, см. ниже), свободного места, свободных inode (для Linux), специфических метрик используемой СУБД. Обязательно также настроить оповещения от диагностики дисков S.M.A.R.T. и RAID-контроллера. Резервное копирование также должно быть покрыто мониторингом.

Если модальности или сопутствующие системы поддерживают сбор метрик (через snmp или т.п.) их также стоит замониторить. В зависимости от тяжести аварийной ситуации стоит настроить алертинг вплоть до автоматического экстренного звонка на телефон дежурного сотрудника — например, отказ воздушного контура охлаждения МРТ может привести к кипению дорогостоящего жидкого гелия и сбросу его через аварийный клапан, что приведет к финансовым потерям и простою сканера.

Мониторинг может также служить подспорьем в планировании закупок (capacity planning), прежде всего HDD под хранилище. Для этого нужно организовать сбор метрик об объеме новой информации поступающей в неделю/месяц/год — можно экстраполировать график и заранее узнать, когда понадобятся новые диски.

Клиенты и утилиты

Просмотрщиков для DICOM очень много, упомянем некоторые:
Horos — открытый и бесплатный просмотрщик для Mac OS X;
OsiriX — популярный платный просмотрщик для Mac OS X, может работать как PACS, есть бесплатная Lite версия;
Weasis — открытый кроссплатформенный просмотрщик для Linux, Mac OS X и Windows; есть portable версия; может быть интегрирован в dcm4chee как веб-просмотрщик;
Oviyam 2 — HTML5 просмотрщик для web;
MultiVox DICOM Viewer — бесплатный отечественный просмотрщик для Windows;
MicroDicom — бесплатный для некоммерческого использования просмотрщик для Windows;
Vidar Dicom Viewer — просмотрщик DICOM исследований для Windows, Linux систем, есть бесплатная версия.
Сайт IDoImaging.com содержит большую подборку бесплатного софта медицинской визуализации.

dcm4che3 — открытый кроссплатформенный набор утилит для манипуляций с DICOM — например, миграции исследований по сети или мониторинга ответа C-ECHO;
DCMTK — открытий кроссплатформенный набор утилит и библиотек для DICOM.

Ещё почитать
  1. Сайт стандарта DICOM
  2. DICOM Standard Browser — удобная навигация по атрибутам
  3. Типы данных
  4. Basic DICOM Operations
  5. Глоссарий OTpedia
  6. PACS-сервер своими руками
  7. Серия постов «DICOM Tutorial» на сайте «DICOM is Easy»
  8. Introduction to DICOM
  9. Пьяных, О.С. Digital Imaging and Communications in Medicine (DICOM). A Practical Introduction and Survival Guide— Springer, 2008. ISBN: 978-3-540-74571-6
19.03.2022 Статьи

Кодировка dicom-элементов типа Code String

Небольшое исследование об отображении кириллического текста в dicom-элементах типа Code String (CS). Не всё так просто, как оказалось. Инструкцию читать надо! 🙂

Один из пользователей программы Dicom AutoExport версии 1.9.1 прислал несколько файлов с указанием того, что кириллица в тегах такого типа все-равно неправильно отображается после конвертации.

Что выяснилось? А оказалось, что тип кодировки, указанный в элементе (0008,0005) совершенно не влияет на отображение символов в элементах Code String.

В стандарте Dicom он определяется как строка символов длиной не более 16 байт, которая может содержать прописные буквы, цифры 0-9, пробел и нижнее подчеркивание.  Кодировка символов в стандарте не указана, но вот на одном из сайтов нашёл, что она должна быть ASCII, и понятно, что латиница. Откуда они взяли, что должно быть именно ASCII непонятно, но, по-видимому, многие вьюверы ожидают именно её.

Взял, что было под рукой из вьюверов. Оказалось, что это Microdicom, Weasis и Радиант. Dicom-файл "сделан" на аппаратуре и ПО компании Телеоптик, программой экспорта кодировка всех текстовых тегов, в том числе и CS, конвертирована в UTF-8.

Microdicom и weasis однозначно не опознают здесь УТФ8.
То, что там УТФ я убедился через онлайн-конвертер.

MD Weasis UTF8

А Радиант нормально всё видит.

readiant utf8

Есть ещё один нюанс.
DicomDump указывает, что ошибка также в том, что значения тегов взяты не из словаря, т. е. не соответствуют стандарту.

DicomDump

Например, для (0018,5101) это должны быть двух-трехбуквенные значения, обозначающие позицию пациента: https://dicom.innolitics.com/ciods/cr-image/cr-series/00185101

А для (0018,0015) есть приложение "L" в стандарте с перечислением возможных значений: https://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_L.html#chapter_L

Я не думаю, что те вьюверы, которые неправильно отображают Юникод в этих тегах, ориентируются на стандартные значения из словаря и типа кроме них ничего не умеют видеть.

Начал экспериментировать. Взял аналогичные файлы, где все теги в кодировке 1251 и всё, кроме CS конвертировал в UTF-8. Т.е. (0018,0015) и (0018,5101) остались в кодировке win-1251.

Теперь MicroDicom все отображает корректно:

2 MD

А Weasis все-равно не понимает кириллицу в CS:

2 weasis

И Радиант перестал правильно смотреть:

2 radiant

Т.о. вывод:
Первый вьювер в этих тегах читает кодировку в вин-1251, второй — непонятно, что ждет, а Радиант ждет то, что указано в (0008,0005).

Добавил функцию конвертации из 1251-ansi в ascii и применил ее только к тегам CS.
Т.е. всё в UTF-8, а CS в ASCII
Теперь MicroDicom показывает какую-то хрень, а точнее пытается ascii отобразить как 1251:

3 md

Weasis все равно кириллицу не видит:

3 weasis

И Радиант тоже:

4 radiant

Вывод: Нет одного единого подхода у вьюверов при отображении этих тегов. Единственный вариант, когда все вьюверы не отображают иероглифы в этих тегах — латиница. Т.е., чтобы всех удовлетворить, нужно CS записывать латиницей, а ещё лучше конкретные значения брать из словаря.
Для (0018,5101) в «людской» рентгенографии это всего-то восемь возможных значений: AP, PA, LL, RL, RLD, LLD, RLO, LLO. Для ветеринарии, конечно, посложнее 🙂 и для лаборанта там вообще китайская грамота будет. Но, наверное, стоит эти значения жестко занести в список для выбора без возможности его редактирования.
Для (0018,0015) всё ещё сложнее. Укладок хренова туча и все их проблематично внести. А если даже они и будут доступны для выбора, то кто же их выбирать будет, когда мало кто из персонала смыслит в этих названиях. Когда укладка выбирается на графическом шаблоне, то лаборанты ещё справляются как-то, а выбрать из списка непонятных слов на латинице — это нереально 🙂

В версии 1.9.3 программы Dicom AutoExport была добавлена для элементов типа Code String была специально добвлена опция, определяющая, каким образом их обрабатывать.

Прокрутить вверх