Форвардинг — одна из тех настроек, о которых вспоминают спустя три месяца. Исследования исправно принимаются, архив отвечает, пользователи не жалуются, а во второй архив с весны не ушло ни одного объекта. Или ушло, но не всё: половина серий на месте, половина нет, и никто не может сказать, когда это началось.
Причина почти всегда в одном из трёх мест: перепутаны сущности, не включён планировщик задач или условие правила не совпадает с тем, что реально приходит от модальности. Разберём, как устроена автоматическая отправка исследований в dcm4chee-arc, что где настраивается и в каком порядке это диагностируется. Это четвёртая часть разбора прикладной эксплуатации архива — после удаления исследований, слияния пациентов и очередей и проверки хранилища.
Три сущности, которые путают
Автоматическая отправка складывается из трёх независимых настроек. Каждая отвечает за свой вопрос, и отсутствие любой из них означает, что не работает ничего.
| Сущность | Отвечает на вопрос | Что в ней задаётся |
|---|---|---|
| Remote Application Entity | Куда отправлять | AE Title получателя, его адрес и порт |
| Exporter | Чем и по какому протоколу | Тип отправки, адрес назначения, очередь задач, от имени какого AE работает архив, расписание |
| Export Rule | Что и когда отправлять | Условия отбора, уровень срабатывания, задержка, ссылка на exporter |
Типичная ошибка новичка выглядит так: создано правило экспорта, в нём указан exporter, exporter ссылается на AE Title получателя — а самого получателя как Remote AE в конфигурации нет. Формально всё заполнено, задачи создаются и немедленно падают. Обратный вариант встречается реже, но тоже бывает: получатель заведён, exporter есть, а правила нет — тогда задачи просто не создаются, и очередь остаётся пустой, что легко принять за «всё отправлено».
Пустая очередь экспорта — это не «всё отправлено». Это либо действительно всё отправлено, либо задачи вообще не создаются. Различать эти два состояния нужно всегда, и различаются они по-разному: в первом случае в очереди есть выполненные задачи, во втором — нет никаких.
Exporter: чем отправляем
Exporter описывает способ доставки. Основные атрибуты:
| Атрибут | Что задаёт |
|---|---|
dcmExporterID |
Имя exporter'а; на него ссылается правило экспорта |
dcmURI |
Назначение и способ. Для отправки на удалённый архив по DIMSE — dicom:STORESCP, где STORESCP это AE Title получателя |
dcmQueueName |
Очередь задач, в которую попадает экспорт (например Export1) |
dicomAETitle |
От имени какого локального AE архив выполняет отправку |
dcmSchedule |
Необязательное расписание, например hour=18-6 dayOfWeek=* — отправлять только ночью |
dicomDescription |
Описание. Не формальность: через год именно оно объяснит, зачем этот exporter заведён |
Обратите внимание на dcmURI: именно префикс определяет способ доставки, и у разных способов разный синтаксис и разные дополнительные свойства. Кроме отправки по DIMSE архив умеет выгружать в STOW-RS, забирать и раскладывать по WADO, создавать рабочие элементы UPS и публиковать в XDS. У каждого типа свой набор свойств — от разделов TLS и метаданных документа у XDS до указания целевого хранилища у WADO.
Практически это означает: «настроить exporter» — это не одна процедура, а пять разных. Чужая инструкция, написанная под STOW-RS, не поможет при настройке отправки на обычный DICOM-архив, хотя на первый взгляд обе про «экспорт».
Export Rule: что и когда отправляем
| Атрибут | Что задаёт |
|---|---|
cn |
Имя правила |
dcmExporterID |
Какой exporter использовать — связь правила с доставкой |
dcmEntity |
Уровень срабатывания: исследование, серия или отдельный объект |
dcmDuration |
Задержка после получения последнего объекта, в формате ISO-8601: PT1M — минута |
dcmProperty |
Условия отбора: например ReceivingApplicationEntityTitle=DCM4CHEE и Modality=CT|MR |
dcmSchedule |
Ограничение по времени, например dayOfWeek=1-5 — только по будням |
Правило создаётся на одном из двух уровней, и выбор уровня — содержательное решение:
-
- на уровне устройства архива — правило действует на объекты, принятые любым AE;
-
- на уровне конкретного Archive AE — только на то, что принято этим AE.
Когда в архив пишут несколько учреждений через разные AE, правило, повешенное на устройство «чтобы наверняка», начинает пересылать чужие данные туда, куда их пересылать не следовало. Это не техническая ошибка — архив делает ровно то, что попросили, — но это утечка за пределы согласованного контура.
Про уровень срабатывания
Выбор dcmEntity определяет, сколько задач создаст архив и когда они начнут выполняться.
| Уровень | Поведение | Когда уместен |
|---|---|---|
| Исследование | Одна задача на исследование, после паузы в поступлении объектов | Обычный выбор для пересылки во второй архив: передаётся целое исследование |
| Серия | Задача на каждую серию | Когда получателю нужны отдельные серии или исследование приходит частями с большими паузами |
| Объект | Задача на каждый принятый объект | Редко и осознанно: КТ-исследование на тысячу срезов породит тысячу задач |
Отдельно про dcmDuration. Задержка нужна не для красоты: DICOM не сообщает архиву, что исследование закончено. Архив считает исследование сложившимся, когда объекты перестали поступать в течение заданного времени. Поставьте нулевую или слишком малую задержку — и получите отправку наполовину принятого исследования, а затем ещё одну задачу на остаток, и объяснять получателю, почему у него исследование в двух частях, придётся вам.
Слишком большая задержка тоже имеет цену: исследование будет ждать отправки, и если у заказчика есть ожидание «во втором архиве снимки появляются в течение получаса», это ожидание нарушится. Разумная величина выводится из того, как ведёт себя конкретная модальность: сколько длится пауза между сериями на реальных исследованиях.
Настройка, без которой не работает ничего
Есть четвёртая вещь, которая не относится ни к правилу, ни к exporter'у и о которой забывают чаще всего. Задачи экспорта выполняет планировщик, и он включается отдельным интервалом опроса на уровне устройства архива:
dcmExportTaskPollingInterval: PT1MВ интерфейсе это поле «Export Task Polling Interval» в расширении устройства архива. Пока интервал не задан, планировщик не работает: правила срабатывают, задачи создаются и спокойно лежат в очереди в состоянии «запланирована». Внешне архив здоров, очередь не пустая, ошибок нет — просто ничего не происходит.
Это системная особенность dcm4chee-arc, а не частность экспорта. Удаление отклонённых объектов, проверка хранилища, очистка отработанных задач — у каждого механизма собственный интервал опроса, и каждый из них по умолчанию может быть не задан. Настроенный механизм и работающий механизм — разные вещи, и проверять надо второе.
Что происходит после срабатывания правила
Дальше экспорт живёт как обычная задача архива: попадает в указанную очередь, проходит состояния, при неудаче повторяется, отображается на странице мониторинга, где её можно отменить или перепланировать. Подробно состояния задач, их разбор и автоочистка разобраны в статье про очереди и проверку хранилища — здесь достаточно помнить, что вкладка экспорта в мониторинге и есть главное место наблюдения за форвардингом.
Важно и то, что экспорт умеет тянуть за собой другие действия. Архив позволяет настроить, чтобы за успешной отправкой следовали:
-
- запрос подтверждения хранения (Storage Commitment) у получателя;
-
- уведомление о доступности объектов (IAN);
-
- удаление объектов из локального хранилища;
-
- отклонение объектов с истёкшим сроком хранения.
Третий пункт требует отдельного внимания. Связка «выгрузили во внешний архив — освободили место у себя» абсолютно нормальна и часто именно для этого всё и строится. Но администратор, который меняет правило экспорта, обязан заранее знать, тянет ли оно за собой удаление. Правка условия отбора в такой конфигурации — это уже не «перенастроить пересылку», а операция, затрагивающая сохранность данных. Что происходит с объектами после отправки, должно быть записано в паспорте сервера рядом с самим правилом.
Типовые задачи
| Что нужно | Как складывается конфигурация |
|---|---|
| Копия всех КТ и МРТ во второй архив | Remote AE получателя → DICOM-exporter с dicom: и его AE → правило уровня исследования с условием по модальности и разумной задержкой |
| Пересылать только то, что приходит от конкретного учреждения | Правило на уровне того Archive AE, которым принимает это учреждение, либо условие по принимающему AE Title |
| Выгружать ночью, чтобы не занимать канал днём | Расписание в exporter'е или в правиле; днём задачи копятся и уходят в окно |
| Отправить одно исследование по заявке, разово | Ручная отправка из интерфейса архива; выбирается между постановкой в очередь и синхронной отправкой |
| Освобождать место после подтверждённой выгрузки | Экспорт плюс подтверждение хранения плюс удаление после экспорта — с обязательной записью об этом в паспорте сервера |
Про ручную отправку стоит сказать отдельно. Архив предлагает два режима: поставить задачу в очередь или выполнить отправку синхронно. Разовая отправка небольшого исследования синхронно удобна — сразу видно результат. Но синхронная отправка объёмного КТ через узкий канал займёт интерфейс и может оборваться по таймауту; для такого лучше очередь.
Ничего не уходит: порядок диагностики
Порядок важен: он идёт от самых частых причин к самым редким и не требует доступа к получателю на первых шагах.
-
- Задан ли интервал опроса задач экспорта. Если задачи есть, но все в состоянии «запланирована» — дальше можно не искать.
- Создаются ли задачи вообще. Отправьте тестовое исследование и посмотрите вкладку экспорта в мониторинге. Задач нет — проблема в правиле, задачи есть и падают — в доставке. Это развилка, которая экономит больше всего времени.
- Тот ли уровень у правила. Правило на конкретном AE не сработает на данных, принятых другим AE.
- Совпадают ли условия. Возьмите реальный объект и сверьте его атрибуты с условиями правила. Модальность
CRне попадёт под условиеCT|MR, а принимающий AE Title в условии может отличаться регистром или быть переименован после настройки. - Не истекла ли задержка. Если
dcmDuration— час, то через десять минут после приёма задачи закономерно ещё нет. - Не действует ли расписание. Правило с окном «только ночью» днём не работает, и это не поломка.
- Существует ли получатель в конфигурации. Exporter ссылается на AE Title; этот AE должен быть заведён как Remote AE с адресом и портом.
- Есть ли связь. Проверка связи с получателем от того AE, от имени которого работает exporter. Заодно выяснится, знает ли получатель наш AE Title — многие архивы принимают только от известных источников.
- Что в ошибке задачи и что в логах получателя. К этому моменту у вас уже есть конкретная упавшая задача, а не общее «не работает».
Отдельный симптом — уходит не всё. Здесь первым делом смотрят не на сеть, а на задачи в состоянии предупреждения: получатель мог отказать по отдельным объектам из-за неподдерживаемого transfer syntax или SOP Class. Сеть в этом случае исправна, ошибки нет, а данные у получателя неполные.
Ловушки
-
- Петля пересылки. Архив A пересылает в B, B настроен пересылать всё принятое обратно в A. Объекты ходят по кругу, очереди растут на обоих серверах. Перед включением форвардинга выясните, что настроено на стороне получателя.
-
- Нулевая задержка — исследования уезжают частями.
-
- Уровень объекта на тяжёлых модальностях — тысячи задач на одно исследование, очередь и база под нагрузкой.
-
- Правило на уровне устройства «чтобы наверняка» — пересылка чужих данных за пределы согласованного контура.
-
- Отсутствие расписания на узком канале — дневная выгрузка конкурирует с приёмом от модальностей.
-
- Экспорт с последующим удалением, о котором не знали. Самая дорогая ошибка в этом списке.
-
- Включение форвардинга на историю. Правило действует на вновь принимаемые объекты; выгрузка накопленного архива — отдельная операция, которую планируют по объёму, времени и влиянию на канал, а не запускают «заодно».
-
- Отсутствие описания. Через год никто не вспомнит, кому и зачем этот exporter отправляет данные, а выключать страшно.
Чек-лист перед включением на рабочем сервере
-
- Есть заявка и понятно, кто получатель, какие данные ему положены и на каком основании.
- Получатель согласован: его AE Title, адрес, порт, и он знает наш AE Title.
- Выяснено, что настроено на стороне получателя — нет ли обратной пересылки.
- Условия отбора сформулированы узко и проверены на реальных атрибутах, а не на предположении о том, что шлёт модальность.
- Выбран уровень срабатывания и обоснована задержка.
- Решено, нужно ли расписание, и оценено влияние на канал.
- Известно и записано, тянет ли экспорт за собой удаление объектов.
- Проверено, что интервал опроса задач экспорта задан.
- Проведена проверка на одном тестовом исследовании, и подтверждено получателем, что оно дошло целиком.
- Правило, exporter, получатель и последствия экспорта внесены в паспорт сервера; запись о включении — в журнал изменений.
Итог
Форвардинг складывается из трёх настроек — получатель, способ доставки, правило отбора — и работает только при заданном интервале опроса задач. Отсюда и порядок диагностики: сначала проверяют, создаются ли задачи вообще, и лишь потом ищут проблему в сети.
Две вещи стоит держать в голове постоянно. Первая: молчащий форвардинг не подаёт признаков аварии, поэтому его состояние должно входить в ежедневную проверку наравне со свободным местом. Вторая: экспорт может тянуть за собой удаление локальных объектов, и прежде чем менять правило, нужно знать, что именно произойдёт с данными после отправки.
Источники
-
- dcm4chee-arc wiki: Forwarding of received instances — обзорная страница со ссылками на частные сценарии.
-
- Forward received instances to remote AE — состав настроек и интервал опроса задач экспорта.
-
- Export Rule — атрибуты правила, уровни срабатывания и условия.
-
- DICOM Exporter — отправка на удалённый AE по DIMSE.
-
- Exporter Properties — свойства exporter'ов других типов: WADO, UPS, XDS.
-
- Очереди и проверка хранилища в dcm4chee-arc — состояния задач, их разбор и автоочистка.
-
- Удаление исследований в PACS — что происходит с объектами, когда экспорт тянет за собой удаление.
Названия атрибутов и полей интерфейса приведены по актуальной на момент написания ветке dcm4chee-arc 5.35.x. В более старых инсталляциях они отличаются — сверяйтесь с документацией своей версии и проверяйте настройку на стенде до включения на рабочем сервере.