FHIR/XDS: обновление документа

Перевод оригинальной статьи Дэвида Хея от 20 ноября 2013 года.

Часто в загруженный в репозиторий и зарегистрированный в реестре документ требуется внести изменения. В документ могут вноситься новые данные, которые меняют смысл содержащейся в нем медицинской информации. В соответствии с процессами, утвержденными в медорганизации, сначала в хранилище может загружаться "предварительная версия" ЭПМЗ, а затем она обновляется и "финализируется" до рабочей версии. Кроме того, оригинальный документ может содержать недостоверные данные и должен быть удален.



Перечисленные ситуации универсальны и применимы не только к ЭПМЗ; однако, в отношении ЭПМЗ есть свои особенности - по ряду причин мы также будем использовать ресурс DocumentReference:

• DocumentReference - это ресурс, который позволяет ссылаться на некоторую сущность ([на ЭПМЗ]). В этой статье мы рассмотрим жизненные циклы сразу двух ресурсов DocumentReference.
• Очень часто хранимая ЭПМЗ - это выписка или краткое изложение оказанной медицинской помощи / лечения (например, выписной эпикриз, дневниковая запись и т.д.) и от содержания ЭПМЗ зависит принятие дальнейшего решения по лечению. Обеспечение доступа (для конечного пользователя) к журналу изменений документа (audit trail) важно с точки зрения судебно-медицинской экспертизы.

Отличают два типа изменений:

• Изменение метаданных (например, тип документа был указан неправильно)
• Изменение содержания ЭПМЗ

Мы будем рассматривать их отдельно.

Внесение изменений в метаданные

Если изменения вносятся только в метаданные, т.е. в ресурс DocumentReference, тогда обновление выполняется стандартным (для fhir) образом - выгружается текущая версия ресурса, вносятся изменения, документ загружается на сервер методом PUT. Механизм управления версиями, предусмотренный в стандарте fhir, сам "позаботится" об обновлении ресурса (Контроль версий ресурсов не обязателен, но очень рекомендован). Есть правда у этого подхода и свои недостатки...

Внесение изменений в документ

Внести изменения в документ несколько сложнее. Опишем шаги, которые необходимо выполнить:

• Нужно обновить сам документ по месту его физического хранения (например, ресурс Binary в конечной точке FHIR/Binary);
• Нужно обновить существующий ресурс DocumentReference, который ссылается на ЭПМЗ; в поле "status" этого ресурса DocumentReference установить значение "superseded" (заменен);
• Создать новый ресурс DocumentReference, ссылающийся на обновленный документ (если в нашей релизации хранилища используется FHIR-сервер, в ссылке должно как-то учитываться наличие нескольких версий документа), установив значение его поля "relatesTo.code" - "supercedes", а в значении поля "relatesTo.target" указать ссылку на оригинальный ресурс DocumentReference.
• Можно создать ресурс Provenance, в котором будут описаны внесенные изменения.

Т.к. изменения в документ вносятся выполнением транзакции, мы будем использовать комплект ресурсов (bundle) и тот же принцип по которому изначально загружали документ на сервер - т.е. переложим "заботу" об обновлении ресурса на сервер репозитория. (Конечно, есть и другие механизмы).
В комплект ресурсов (bundle) будут входить:

• Обновленный документ, запакованный в ресурс Binary (в формате base64). Ему будет назначен уже существующий ID (наверное это автор имел ввиду, когда писал "real ID"), чтобы сервер понял, что происходит именно обновление документа.
• Оригинальный ресурс DocumentReference с обновленным статусом. Ему будет назначен уже существующий ID (наверное это автор имел ввиду, когда писал "real ID"), чтобы сервер понял, что происходит именно обновление документа.
• Новый ресурс DocumentReference (по большей части он будет повторять первоначально созданный ресурс; в поле "relatesTo" будет указана ссылка на первоначально созданный ресурс). Этот ресурс будет иметь идентификатор типа "cid" (create id), чтобы сервер создал новый идентификатор для этого ресурса.
• (Дополнительно, но необязательно) ресурс Provenance c подробной информацией о внесенных изменениях. Ресурс Provenance ссылается на ресурс, в который были внесены изменения (а не наоборот); он будет ссылаться на 2 ресурса DocumentReference, которые должны находиться после выполнения транзакции. Формат идентификатора этого ресурса в комплекте - "cid", то есть на сервере для него будет сгенерирован идентификатор.

Выполним транзакцию и сервер репозитория обработает сформированный комплект ресурсов.
Хотя второй подход к обновлению документа сложнее, очевидным становятся значимость внесенных изменений. По этой причине контроль за изменением метаданных (например, изменение субъекта медицинской информации или автора ЭПМЗ) лучше прослеживается именно этим способом, в отличие от простого изменения ресурса DocumentReference. Но, в конечном счете, выбор метода остается за вами...
В связи со всем этим возникает интересный вопрос (который не возникал, когда мы формировали запрос к реестру документов т.е. к директории /DocumentReference сервера): в качестве ответа на запрос вернутся как актуальные, так и замененные ресурсы DocumentReference: если в запросе не указать параметр "status", в ответе вернутся все ресурсы DocumentReference. Поэтому, рекомендуется проверять значение поля "status" при формировании и выдаче клиенту перечня документов. (Конечно, хорошо бы еще как визуально пометить для пользователя документы, которые изменялись, но это вопрос реализации...)
В противном случае, мы можем явно указать, что нас интересуют только актуальные документы, т.е. примеры запросов (из прошлого поста) будут иметь уже другой вид:

GET  http://registryserver/DocumentReference?subject= 100&status=current&period > 2013-01-01

и

GET  http://registryserver/DocumentReference?subject= 100&status=current&type= http://loinc.org|34108-1

Небольшое дополнение: есть неплохая статья о узкоспециализированных сервисах, в которой предлагается определить specific service end points (наверное директории на сервере, с которыми будет работать сервис), выполняющие данную функцию:

/service/document/new

/service/document/update

в которые будут записываться описанные нами комплекты ресурсов.