Слияние пациентов и исправление атрибутов в 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)	Кто выдал этот идентификатор: конкретная МИС, учреждение, реестр

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

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

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

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

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

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

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

• • при обработке запросов;

• • при выдаче объектов клиенту;

• • при формировании ответа на запрос рабочего списка.

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

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

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

• • каждое правило должно иметь записанное назначение: какая модальность, какой атрибут, почему;

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

• • новое правило сначала проверяется на стенде на тестовом наборе, и сравниваются атрибуты до и после;

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

• • набор и формат настроек заметно менялся между версиями архива — сверяйтесь с документацией и интерфейсом именно вашей версии, а не с чужой инструкцией.

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

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

1. 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 — операции с пациентами, исследованиями и объектами, включая слияние, смену идентификатора, перенос и копирование.

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

• • dcm4chee-arc wiki: HL7 Receiver — приём сообщений от систем-источников.

• • dcm4chee-arc wiki: HL7 PDQ Service — запрос демографии пациента во внешней системе.

• • dcm4chee-arc wiki: Audit Logger — журнал аудита операций.

• • dcm4chee-arc wiki: Secure Archive Users and Roles — кому доступны операции изменения данных.

• • DICOM PS3.16, CID 7010 — коды причин, требуемые при переносе объектов.

• • Удаление исследований в PACS: rejection, IOCM и retention в dcm4chee-arc — первая часть разбора прикладной эксплуатации архива.

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