Current Build

Переводит компания Health Samurai . Приглашаем поучаствовать в русификации стандарта FHIR: GitHub , Email.

7.8 Примеры типовых сценариев в FHIR

FHIR Infrastructure Рабочая группаУровень зрелости: N/AСтатус голосования: Информативный

FHIR представляет собой стандартизованную методологию, определяющую единый способ решения проблем в здравоохранении c помощью набора ресурсов, используемых различными способами. На данной странице дается описание решений типовых клинических сценариев с помощью стандарта FHIR. Приведенные клинические сценарии - примеры возможного практического применения FHIR и не являются исчерпывающими. FHIR может использоваться в широком множестве клинических сценариев.

In addition, to the information on this page, see also Resource Guide.

Рассмотрим клинический сценарий, при котором ЭМК-система [лечебного учреждения] предоставляет RESTful API, позволяющий пациентам получать доступ к их медицинским записям через общественный веб-портал или мобильное приложение (обычно, поставляемое третьими лицами). В данном случае поставщик услуг PHR [веб-сервиса или "десктопного" приложения]:

  • Предоставляет пациенту логин для идентификации (или "привязывает" запись пациента к стороннему идентификатору от OpenID, Facebook, Google, и т. д.)
  • Проводит аутентификацию клиента с помощью OAuth-сервера, управляющего авторизацией (сервер может принадлежать поставщику PHR) и ограничивает клиента просмотром медицинских записей только конкретного пациента (или нескольких пациентов, в зависимости от настроек доступа)

ЭМК-система предоставляет доступ к FHIR-серверу, который поддерживает операции search и read по отношению к следующим ресурсам:

  1. Patient - для просмотра демографической информации о пациенте. Когда с клиентской стороны отправляется запрос без каких-либо критериев поиска, сервер предоставляет перечень всех пациентов, информация о которых доступна конкретному пользователю.
  2. search и read над ресурсом DocumentReference (ссылка на документ) - для предоставления доступа к неспециализированным документам пациента в формате PDF или др. (Формат PDF предпочтительный.)
  3. search и read над рядом клинических ресурсов

Here is the Capabilities Statement for this scenario: XML or JSON.

ЭМК-система может иметь дополнительные функциональные возможности: предоставлять общий доступ к записям пациентов для родственников и опекунов, позволять пациентам загружать собственные документы, записи о приеме лекарственных средств (medication statement), наблюдения (напр., из электронных медицинских изделий, обеспечивающих мониторинг состояния организма человека) и / или записываться на получение медицинской консультации. Дополнительные функции потребуют реализации и открытия дополнительных возможностей API. ЭМК-сервер может разрешать использование операций search, read и history по отношению к ресурсу AuditEvent, входящего в состав записей о пациентах для просмотра пациентом журнала (логов) обращений к его данным. Обратите внимание, все факты использования RESTful API должны быть отражены в логах ресурса AuditEvent.

Распространенным способом интеграции информации о здоровье, хранящейся во множестве источников, является построение репозитория документов на основании медицинской карты пациента (build a repository of documents around a patient record). Создание репозитория документов позволяет "смягчить" требования к объединению политик, существующих процедур, стандартов документооборота и информационных стандартов.

Наиболее часто используемая методология обмена документами между учреждениями, регионами и странами - IHE Cross-Enterprise Document Sharing (XDS). XDS обеспечивает возможность создания системы способных к интеграции репозиториев и реестра документов для координированного доступа к клиническим документам.

FHIR предоставляет функциональность, эквивалентную XDS, которая может использоваться: для реализации XDS, не обращаясь к существующему интерфейсу XDS.b; для предоставления более простого, воспроизводимого с мобильных устройств интерфейса к существующей экосистеме XDS; либо для связывания совместного доступа к документам с другой функциональностью, предоставляемой через FHIR-интерфейс.

Следующие ресурсы FHIR участвуют в предоставлении функциональных возможностей XDS:

  • Ресурс DocumentReference дает описание документа, размещенного в стороннем хранилище. Реестр документов (document registry) - это система, которая отвечает за администрирование набора ссылок на документы (Document References)
  • Поддержка двоичного представления данных (Binary) может использоваться для хранения документов на FHIR-сервере. Репозиторий - это система, которая хранит документы в двоичном представлении в дополнение к ссылкам на документы (иногда без)
  • Ресурсы Patient (Пациент), Practitioner (Врач) и Организация (Organization) помогают в идентификации людей и организаций
  • Ресурс AuditEvent позволяет отслеживать обращения (использование) к реестру и репозиторию документов (document registry and repository)
  • The DocumentManifest resource describes a set of documents that are grouped together in original publication

В настоящий момент активно проводиться совместная работа консорциума IHE с проектной командой FHIR по использованию FHIR с Mobile Health Documents (MHD)

Медицинские информационные системы широко применяются для интеграции систем поддержки принятия решений (СППР) и медицинских систем. Распространенные способы применения СППР:

  • Проверка взаимодействия лекарственных средств и, в более общем смысле, проверка "безопасности" лекарственных назначений (prescription safety checks)
  • Предложение (обычно опускаемой) интерпретации данных диагностики (including delta checking)
  • Контроль за состоянием пациента для раннего обнаружения ухудшения в состоянии здоровья (как при интенсивной терапии, так и при амбулаторном лечении)
  • Определение пациентов-кандидатов на переход к альтернативным планам лечения для повышения эффективности лечения

Обратите внимание, в дополнение к поддержке принятия решений по лечению, возможно также инфраструктурное использование, например, управление контролем доступа.

Различные подходы к содействию в принятии решений подразумевают использование разных шаблонов взаимодействий (interaction patterns), поэтому стандарт FHIR имеет несколько вариантов реализации ППР. Обычно, шаблоны взаимодействия можно разделить на несколько классов:

  1. Решение генерируется подсистемой (engine), полностью скрытой за интерфейсом системы и не имеющей прямого влияния на обмен данными
  2. Подсистема принятия решений использует имеющиеся данные и генерирует оповещения (alarm messages) в соответствии с состоянием пациента, информация о котором доступна в FHIR-интерфейсе
  3. Обращение к подсистеме поддержки принятия решений происходит через описанный интерфейс; она принимает запрос и возвращает решение

Любая СППР может быть классифицирована в соответствии с несколькими представленными выше категориями, в зависимости от аспекта применения конкретной СППР.

  1. В настоящий момент к спецификации FHIR не предъявляется каких-либо требований по поддержке принятия решений, однако, в будущем будет проведен пересмотр содержимого ресурсов, чтобы гарантировать поддержку распространенных подходов содействия принятию решений
  2. FHIR не предусматривает наличие какого-либо ресурса, использующегося для данных целей. Ресурс Flag предназначен для работы с медицинскими записями (clinical notes) и не может использоваться для содействия принятию решений. В будущем для данных целей будет использоваться ресурс "Alarm" (в настоящий момент в подготовке).
  3. Запрос поддержки принятия решения понимается как операция search, использующей именованный запрос (named query) с набором параметров (using a named query that takes a set of parameters). См.далее

При отправке запроса на получение решения справедливы следующие соображения:

Запрос (Request)

  • Запрос решения выполняется по одному из шаблонов взаимодействий (interaction patterns), описанных для операций search / query: RESTful-поиск, отправка запроса к сервису Mailbox, отправка запроса в сообщении, использование асинхронных запросов
  • Запрос должен содержать параметр, которые позволит установить запрашиваемое решение
  • В запросе необходимо указывать значения параметров. Значениями параметров могут быть данные, описывающие принимаемое решение, или ссылки на конкретные ресурсы, содержащие запрос. Вообще, чем сложнее запрос на решение, тем больше вероятность, что ресурс полностью подойдет, в частности это дает уже готовый способ записи и управления самими запросами.
  • В некоторых шаблонах отправки запросов, (query interaction patterns) ресурсы, идентифицируемые значением параметров, могут отправляться вместе с запросом (can be bundled up with the request). В других шаблонах взаимодействий, запрос снабжается только ссылками на ресурсы.
  • Какой из шаблонов взаимодействия является наиболее подходящим зависит от сложности входных параметров, а также от времени, выделяемого на нахождение решения. При увеличении ожидаемого времени нахождения решения и повышении сложности входных параметров, применяются более сложные шаблоны запросов (more complex query patterns become more appropriate).

Ответ (Response)

  • Если подсистема поддержки принятия решений не в состоянии предоставить запрашиваемое решение, она возвращает ресурс OperationOutcome с описанием возникшей проблемы
  • Иначе, СППР возвращает ресурс, представляющий решение, вместе с другими ресурсами (в качестве сопроводительной) информации, как описано в ресурсе или применяемых интеграционных профилях
  • В принципе, поставщик решения может предоставлять (или не предоставлять) копию возвращаемого ресурса с решением через обычный RESTful-интерфейс. Это зависит от ограничений, накладываемых применимыми в данном случае профилями, политиками и от самой сущности запроса
  • Если поставщик решения (decision provider) или отправитель запроса на получение решения (decision requester) желают сохранить полученное решение, они должны гарантировать что достаточно внимания уделяется (потере) актуальности решения при его использовании (актуализации решения)

Отсюда следует, что решения, которые могут быть запрошены, требуют объявления ресурса-ответа (response resource defined) и, возможно, ресурса-запроса (request resource). В данной таблице дается обобщенное представление известных решений, для которых были определены ресурсы.

Решение (Decision) Ресурсы (Resources) Invocation (Вызов)
Какую вакцинацию необходимо пройти данному пациенту? Ответ: ImmunizationRecommendation Конкретный способ получения ответа по данному запросу еще не определен

Разрешается использовать существующие ресурсы для содействия принятию решений, однако, нет никаких гарантий, что ресурсы "подойдут" для решения поставленных задач. Улучшенная поддержка содействия принятию решений станет одной из основных задач развития стандарта на этапе его пробного использования.