DICOM Storage Commitment: подтверждение сохранения и границы ответственности архива

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

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

Служба Storage обеспечивает передачу экземпляров объектов. Storage Commitment добавляет запрос о принятии ответственности за их сохранность. Срок хранения, способ последующего получения и ограничения описывает реализация архива в DICOM Conformance Statement. Поэтому само название функции не означает бессрочного хранения, наличия независимой резервной копии или гарантированного времени восстановления после аварии.

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

Наблюдаемое событие	Что оно подтверждает	Что ещё остаётся проверить
Успешный сетевой обмен	Участники смогли выполнить конкретную операцию	Состав переданного исследования и последующее хранение
Успешный C-STORE	Получатель принял соответствующий объект	Принятие обязательства хранения и поведение при сбое
Запрос Storage Commitment принят	Запрос поступил на обработку	Итоговое уведомление для всех перечисленных объектов
Положительное подтверждение	Принято обязательство по указанному набору	Условия обязательства и полноту самого исходного набора
Исследование открывается у врача	Работает конкретный маршрут получения и отображения	Резервирование, восстановление и доступность остальных типов объектов

Почему единицей контроля должен быть объект

Одно исследование может содержать несколько серий, изображения, структурированные отчёты и дополнительные объекты. Запрос включает ссылки на экземпляры через идентификаторы SOP Class UID и SOP Instance UID. Подтверждение относится к этому перечню. Если какая-то серия не вошла в отправку и запрос, положительный ответ на оставшуюся часть не обнаружит её отсутствие автоматически.

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

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

Отложенный ответ и частичный отказ

В модели Push используются запрос N-ACTION и уведомление N-EVENT-REPORT. Ответ о результате может поступать позже первоначального запроса. Например, реализация Orthanc использует асинхронный обмен и различает ожидание, успех и отказ. Это пример конкретной реализации, а не универсальное описание интерфейсов всех PACS. В документации своей системы необходимо найти правила повторов, тайм-аутов и восстановления незавершённых операций.

Ситуация	Разумная трактовка	Предмет технического разбора
Долго сохраняется ожидание	Итог пока неизвестен	Очередь архива, доставка уведомления, идентификатор транзакции
Подтверждена только часть набора	Нельзя считать завершённым весь набор	Список успешных и неуспешных объектов, причины отказа
Уведомление пришло повторно	Нужна корректная обработка повтора	Соответствие транзакции и отсутствие двойного изменения состояния
Аппарат перезагрузился в ожидании	Состояние очереди требует проверки	Сохранение незавершённых заданий и документированное восстановление
Архив подтвердил хранение, просмотр недоступен	Хранение и доступ через выбранный маршрут расходятся	Службы получения, права пользователя, индекс и совместимость просмотра

Разбор: аппарат показывает отправку, но не завершает архивирование

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

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

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

Разбор: подтверждение есть, но отсутствует дополнительная серия

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

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

Как оформить приёмочный протокол

Поле протокола	Что записать	Зачем это необходимо
Участники обмена	Модель, версия ПО, роль и согласованные идентификаторы систем	Повторить проверку после изменения конфигурации
Тестовый набор	Типы объектов, серии и ожидаемые идентификаторы	Отличить полноту исследования от успешности одного сообщения
Последовательность	Отправка, запрос, уведомление и время завершения	Понять, на каком этапе возникает задержка
Негативный сценарий	Контролируемый отказ на стенде и результат восстановления	Убедиться, что ошибка не маскируется общим статусом
Получение данных	Открытие всех предусмотренных серий и дополнительных объектов	Подтвердить практическую доступность результата
Правило локальной очистки	Документированные условия и ответственный процесс	Не связывать удаление с недостаточным подтверждением

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

Ещё один полезный сценарий — изменение состава участников. После переноса PACS или замены рабочей станции прежний успешный тест не подтверждает новую конфигурацию. Нужно повторить обмен с теми же контрольными объектами и заново проверить направление уведомлений. В журнале сохраняют версии программ и параметры теста, а не только дату проверки. Это помогает отличить ошибку, появившуюся после изменения системы, от давно существовавшей особенности интерфейса. История таких проверок полезнее общего утверждения, что подтверждение хранения когда-то уже работало.

Storage Commitment особенно полезен как проверяемое звено общей системы хранения. Его ценность проявляется тогда, когда организация различает передачу, подтверждение, получение и восстановление, а не объединяет их в одно слово «архивировано». Резервное копирование и план аварийного восстановления остаются отдельными задачами, которые необходимо проверять собственными испытаниями.