Почему в 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	Отмена ранее выполненного отклонения — возврат объектов в оборот

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

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

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

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

• • объекты перестают возвращаться в обычных запросах C-FIND и DICOMweb — для вьювера и для МИС исследование «исчезло»;

• • в архиве появляется rejection note — отдельный объект, который сам по себе доступен и хранится по своим правилам;

• • файлы остаются в хранилище, место на диске не освобождается;

• • операция попадает в журнал аудита архива.

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

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

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

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

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

Атрибут LDAP	Назначение
dcmDeleteRejectedPollingInterval	Как часто запускается задача удаления отклонённого. Пока интервал не задан, задача не работает вовсе
dcmDeleteRejectedInstanceDelay	Задержка перед удалением записей об отклонённых объектах. Задаётся отдельно для каждой причины отклонения
dcmDeleteRejectionNoteDelay	Задержка перед удалением самой rejection note

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

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

Удаление записей из базы само по себе не трогает файлы. За их физическое удаление отвечает отдельный процесс очистки хранилища, который включается своим интервалом опроса на уровне устройства архива («Purge Storage Polling Interval»).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• • Удалять файлы из каталогов хранилища. База об этом не узнает, а Storage Verification начнёт показывать расхождения, неотличимые от реальной потери данных.

• • Удалять записи SQL-запросами напрямую в базе. Связи между исследованием, сериями, объектами, задачами и записями хранилища сложнее, чем кажется; результат — архив в несогласованном состоянии.

• • Выполнять docker compose down -v на боевом архиве. Ключ -v удаляет тома вместе с данными. Эта команда встречается в статьях и в чужих шпаргалках как «перезапустить начисто».

• • Отклонять что-либо без заявки и основания. Устная просьба в коридоре основанием не является.

• • Включать автоматическое удаление просроченного «чтобы не переполнялось» без сверки срока хранения с договором и нормативными требованиями.

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

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

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

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

• • включена ли задача удаления отклонённого и с каким интервалом;

• • какие задержки установлены для каждой причины отклонения;

• • включена ли очистка хранилища — без неё место не освободится никогда;

• • какие политики хранения заведены, к каким исследованиям применяются и совпадает ли срок с договорными обязательствами;

• • кому выданы права на отклонение объектов — эта операция не должна быть доступна всем подряд;

• • работает ли журнал аудита и куда он пишется.

Итог

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

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

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

• • DICOM PS3.16, CID 7010 Key Object Selection Document Title — исходный справочник кодов причин отклонения.

• • dcm4chee-arc wiki: IOCM Operations — операции отклонения, копирования и переноса объектов.

• • dcm4chee-arc wiki: Deletion of Rejected Instances — задержки и интервалы удаления отклонённого.

• • dcm4chee-arc wiki: Study Retention Policy — политики хранения и их атрибуты.

• • dcm4chee-arc wiki: Reject Expired Studies — отклонение исследований с истёкшим сроком хранения.

• • dcm4chee-arc wiki: Storage Verification — проверка соответствия базы и фактического содержимого хранилища.

• • dcm4chee-arc wiki: Audit Logger — журнал аудита архива.

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