FHIR и XDS: краткий обзор

Первая из цикла статей о FHIR и XDS, опубликованных в блоге Дэвида Хэя.

Стандарт FHIR со своей REST-архитектурой успешно может использоваться в реализациях профиля обмена документами IHE XDS (Cross Enterprise Document Sharing). Организация IHE разработала интеграционный профиль MHD (мобильный доступ к документам о здоровье) (кстати, также как и FHIR реализующий архитектурные принципы REST), чтобы упростить доступ к XDS-инфраструктуре для мобильных устройств. С появлением FHIR, IHE и HL7 уже могли объединить свои усилия и начать разработку второй версии профиля MHD, полностью базирующегося на стандарте FHIR. Стандарт FHIR не отменяет XDS - в некоторых ситуациях необходимо развертывание именно XDS-инфраструктуры - особенно, если речь идет о крупных развертываниях сети обмена медицинской информацией; однако, простота реализации и использования FHIR побуждает многих интеграторов использовать именно его в качестве интерфейса взаимодействия.



Вполне возможна реализация "XDS-подобных" систем, которые соответствует всем паттернам XDS (и соответственно удовлетворяет всем ее сценариями использования), но не обязательно имеет "настоящий" XDS-бэкенд.
Этот пост - первый из цепочки о FHIR в качестве фронтэнда XDS; мы также рассмотрим соответствия инфраструктурных компонентов XDS и FHIR.
Рисунок ниже - это стандартное представление XDS:


На рисунке изображены 5 основных участников:

• Реестр документов (Document Registry) - это "индекс" имеющихся документов. В пределах организации разворачивают только один регистр; определен профиль (например, XCA), поддерживающий отправку запросов нескольким регистрам для случаев, когда в единую инфраструктуру объединяют несколько партнерских медицинских организаций.
• Документы фактически хранятся в одном или нескольких репозиториях документов (Document Repository).
• Источники документов (Document Sources) отвечают за создание документов и загрузку их в хранилище (репозиторий)
• Заказчики документов (Document Consumers) отправляют запросы на выдачу документов, получают документы из репозиториев
• Единый источник идентификационных данных (Identity Source) для управления идентификаторами пациентов (patient identity)

Определен набор стандартных транзакций:

1. Регистрация и предоставления набора документов (Register and provide document set) (ITI-41): источник документов собирает в пакет один или несколько документов с соответствующими данному набору метаданными и отправляет пакет для хранения в репозиторий.
2. Регистрация набора документов (Register document set) (ITI-42): репозиторий отправляет метаданные о пакете в реестр документов.
3. Запрос к реестру документов (Registry stored query) (ITI-18): потребитель документа отправляет в реестр запрос, содержащий некоторый набор поисковых критериев. Цель запроса - получение документа(ов), соответствующих критериям поиска.
4. Получение набора документов (Retrieve document set) (ITI-43): данная транзакция определяет механизм получения потребителем конкретного документа. Как правило, извлечение документа из хранилища происходит уже после того, как был отправлен запрос в реестр документов.
5. Канал идентификации пациентов (Patient Identity Feed) (ITI-8, ITI-44): канал по которому передаются обновления демографических данных пациентов, вносимых источниками идентификаторов (identity source) в реестр(ы). В частности эта транзакция используется при слиянии (merges) или мэппинге идентификаторов, относящихся к одному пациенту.

Если поверх изображенной на рисунке выше инфраструктуры "положить" FHIR-ресурсы, то получится следующее:


Неудивительно, что между транзакциями, определенными XDS, и FHIR-ресурсами есть прямое соответствие.

• Источник документов может отправлять документ и метаданные в репозиторий в форме выполнения транзакции (например, как medication update)
• Репозиторий обновляет реестр документов, отправляя FHIR-ресурс в конечную точку DocumentReference реестра
• Поиск документа заказчиком осуществляется выполнением запроса к конечной точке DocumentReference реестра документов; документ выгружается выполнением команды GET, отравляемой в репозитории или конечную точку с бинарными ресурсами (binary endpoint).
• Ресурс SecurityEvent регистрирует (значимые) запросы получения доступа.

(В этом посте мы обходим стороной ресурс DocumentManifest и только используем DocumentReference: для нас это означает лишь только то, что мы можем загружать и выгружать только один документ за раз). Ресурс DocumentReference определяет метаданные только для одного документа (в него записывается основной набор данных для выполнения поиска). Ресурс DocumentManifest позволяет "группировать" несколько документов (например, документ и его вложение) в единый пакет.
Источник документов может обновлять реестр напрямую. Это возможно, если документ хранится за пределами инфраструктуры XDS (например, поддерживается взаимодействие с репозиторием, который не отвечает требованиям профиля XDS).

Почти в каждом предложении этого поста мы говорили о некотором "документе" - но что такое "документ"? Официальная спецификация дает следующее определение:

"Документ - это последовательность байтов, которую можно [уникально] идентифицировать, которая существует в некотором контексте (т.е. имеет тему, автора и т.д.), может быть показана [и интерпретирована] пользователем и для которой определен порядок внесения изменений (update management)."

Соответственно, под определение документа подпадает CDA, PDF, любой текстовый файл, FHIR-документ или документ Microsoft Word. Метаданные о документе содержатся в ресурсе DocumentReference - в том числе и его mime-тип.
Последнее, что мы обсудим в этом посте - это Affinity domain (т.е. "доверенный домен"). Организация IHE определяет affinity domain как "группу медицинских организаций, которые договорились об использовании единого набора политик и использовании общей инфраструктуры".
На практике под доверенным доменом (affinity domain) мы будем понимать следующее:

• Политики обеспечения безопасности и конфиденциальности (которых будут придерживаться все участники affinity domain)
• Коды конфиденциальности (Confidentiality codes) и их значения
• Определение типов и подтипов документов. Например, могут использоваться коды LOINC для "выписного эпикриза", "выписки из амбулаторной карты", "дневниковой записи" и т.д.
• Поддерживаемые форматы документов. Например, перечисление поддерживаемых mime-типов, но может быть и более детальное определение поддерживаемых типов
• Возможные статусы документа
• Поддерживаемые виду медицинских учреждений (учреждения первичного звена, стационар (госпиталь), дом отдыха и т.д.)
• Клинические службы (ортопедия, педиатрия, реанимация и т.д.)

У документа могут быть и другие характеристики, но выше перечислены самые важные из тех, о которых должны договориться участники "affinity domain".