Получение документов из FHIR/XDS-инфраструктуры

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

Мы коротко обсудили, как ресурсы fhir могут полноценно использоваться в инфраструктуре обмена ЭПМЗ, изучили возможности document creator может создавать и загружать ЭПМЗ в репозиторий и / или обновлять реестр документов, коснулись использования ресурса DocumentReference. Теперь уделим внимание действующему лицу "пользователь сервиса" (service consumer).
Нас интересуют два кейса (которые должен решать FHIR/XDS-хранилище):

• Получение списка документов для конкретного пациента (используя различные параметры поиска - в диапазоне дат, по типам документов и т.д.) и представление пользователю метаданных о документах в виде списка.
• Выгрузка конкретного документа для просмотра.

Получение списка документов

Первый кейс: чтобы упростить задачу, представим, что нам нужно выгрузить все документы по конкретному пациенту. Учитывая то, что метаданные документа хранятся в ресурсе ​​DocumentReference, который физически находится на сервере реестра документов (Registry Server), то запрос будем делать к директории (end point - конечной точке) /DocumentReference на этом сервере. Есть несколько способов выполнить запрос. Выбор способа зависит от того, если ли у нас идентификатор пациента или идентификатор ресурса, который представляет пациента в системе).
Если мы знаем ID ресурса Patient (скажем, "100"), тогда запрос будет выглядеть так:

GET  http://registryserver/DocumentReference?subject= 100

(При условии, что идентифицирующие пациента данные хранятся на том же сервере, к которому мы обращаемся. В противном случае под Patient ID будем иметь ввиду абсолютную ссылку на ресурс Patient).
Если мы не знаем идентификатор ресурса Patient, но знаем персональный идентификатор пациента (номер полиса, номер паспорта - "PRP1660"), у нас есть следующие варианты:

• Сначала получить идентификатор ресурса Patient отправив запроса к директории (end point) севера /Patient
• Отправить запрос (chained query) к ресурсу DocumentReference, в котором будет указан идентификатор пациента:

GET http://registryserver/DocumentReference?subject.identifier= PRP1660

Обратите внимание, что сервер не обязан поддерживать цепочки запросов (chained queries), поэтому, прежде чем отправлять такой запрос на сервер, почитайте его conformance-ресурс (где определяются поддерживаемые сервером функции). В запросе мы не указали систему идентификации (identifier system) (т.е. не указывали, что персональный идентификатор пациента является номером паспорта, полиса или SSN). Тем не менее, это может требовать конкретная реализация FHIR/XDS-хранилища. "Цепочки запросов" (chained query - не знаю, почему он их тут так называет) значительно упрощают для клиентов процесс обращения к серверу (и, соответственно, усложняют жизнь серверу), но согласно идеологии FHIR мы должны максимально упрощать работу клиентской стороны.

В обоих случаях в качестве ответа на запрос вернется комплект ресурсов DocumentReference с той разницей, что при указании идентификатора ресурса Patient, мы 100% можем быть уверены, что все ресурсы DocumentReference относятся к нужному нам пациенту. Если бы мы использовали в запросе персональный идентификатор пациента (номер паспорта / полиса / SSN), тогда, лучше указывать в запрос дуплет "идентификатор"+"система кодирования", чтобы не оказалось, что указываемый нами идентификатор неуникальный.
Что, если мы хотим выполнить более конкретный поиск? Например, нас интересуют только документы, созданные в прошлом году или только выписки из медкарт?
Для ресурса DocumentReference в спецификации определен набор поисковых параметров. В примерах ниже вы встретите такие параметры как "period" (дата оказания услуги) и "type" (т.е. тип документа). (В приведенных примерах предполагается, что мы знаем идентификатор ресурса Patient):

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

и

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

В запросе можно указывать разные поисковые параметры (определенные в спецификации) только при условии, что сервер поддерживает такие запросы.

Выгрузка конкретного документа

Теперь, когда мы можем показать пользователю список документов; осталось извлечь нужный документ из репозитория. Будем надеяться, что в ресурсе DocumentReference (который описывает документ) место физического хранения документа указано правильно (в поле "location"). В этом случае дело за малым - в отправке http-запроса. Если репозиторий с документами не поддерживает прямые get-запросы, придется обратиться к профилю "XDS" и его разделу "retrieve document", параметры доступа к которому должны определяться в поле "service" ресурса DocumentReference.
Если сервер обрабатывает get-запросы, сервер репозитория также будет включать в ответt на запрос стандартные http-заголовки, такие как "content-type" (это значение также записывается в поле mimeType ресурса DocumentReference), чтобы программа для просмотра документа правильно его отображала. Конечно, все может оказаться несколько сложнее, чем описано здесь, особенно если структурированный документ типа CDA или fhir-документ будет отображаться специализированными программами-просмотрщиками на клиентской стороне (с использованием стилей XSLT). Например, метаданные из ресурса DocumentReference (и, возможно, HTTP-заголовка) должны сообщать, какую программу для отображения документа следует использовать.
Обратите внимание: get-запрос возвращает непосредственно документ вне зависимости от его формата (pdf или cda). (т.е. вернется не fhir-ресурс.)

Коротко о защите обмена данными

Стандарт fhir не имеет собственного протокола для обеспечения безопасности обмена данными; предусмотрено, что он будет использоваться с другими протоколами специально предназначенными для данных целей и может сообщать системе безопасности дополнительную информацию, по которой она будет принимать решение о выдаче документа о запросу или даже о выдаче по запросу метаданных о хранящихся в системе ЭПМЗ.
Существует предположение, что любой, кто получает доступ к одному из описанных выше сервисов должен быть идентифицирован системой; для этой цели рекомендуется использовать oAuth (хотя не обязательно использовать именно OAuth).
Стандарт FHIR поддерживает использование "тегов", которые могут быть назначены любому ресурсу и использоваться системой безопасности. Теги могут обрабатываться системой, принимающей решение о выдаче данных, на основании предопределенного набора правил; такие правила могут быть достаточно сложными. Кроме того, ресурс DocumentReference имеет специальное поле "confidentiality", которое также можно использовать по назначению.
Существует также ресурс SecurityEvent (по целям использования аналогичный профилю IHE ATNA), используемый для записи важных событий, таких как выдача пользователю документа. Этот ресурс может использоваться для контроля за получением доступа к документам ("Кто просматривал этот конкретный документ?") и может быть создан в любое время в процессе работы системы. Ресурс Provenance отображает контекст получения ресурса, например, автора документа.
В конечном счете, ответственность за инфраструктуру обмена документами и утверждение и внедрение в жизнь политик полностью ложится на руководство медорганизации. Конфигурация инфраструктуры совместного хранения ЭПМЗ также описана в договоре участников "Affinity Domain".