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

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. Рекомендованная архитектура

Смешанная схема часто наиболее практична: 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 необходима проверка конкретной сборки и конфигурации.