FHIR Release 3 (STU)

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

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

FHIR (Fast Health Interoperability Resources) предназначен для обмена информацией, связанной со здравоохранением. К ней относятся клинические данные, а также относящиеся к здравоохранению административно-хозяйственные данные, данные общественного здравоохранения и исследований. Стандарт охватывает как человеческую, так и ветеринарную медицину, и предназначен для повсеместного использования в самых разнообразных контекстах, включая стационар, долгосрочную медицинскую помощь, амбулаторную реабилитацию инвалидов, вспомогательную немедицинскую помощь и т. д.

Спецификация FHIR ориентирована на людей и организации, которые разрабатывают программное обеспечение и проектируют совместимые программные продукты. Спецификация FHIR не ставит целью выявить хорошие или лучшие клинические практики и не предлагает руководства к пользовательским интерфейсам или рабочим процессам. Консультирование в этих областях может быть полезным, но выходит за рамки FHIR.

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

С клинической точки зрения наиболее важной для понимания частью спецификации FHIR являются ресурсы. Проще всего представить себе ресурсы как бумажные «формы», отражающие различные виды клинической и административной информации, которую можно зафиксировать и совместно использовать. Спецификация FHIR определяет общий шаблон "формы" для каждого типа клинической информации: один для аллергии, один для предписаний, один для направлений и т. д.

Данные FHIR состоят из репозиториев, содержащих заполненные "бланки" (экземпляры ресурсов). Экземпляры ресурсов содержат информацию о пациенте, такую, как демографические данные, клиническое состояние здоровья и процедуры; а также административную информацию, то есть информацию о специалистах, организации и её местоположении. Некоторые ресурсы являются компонентами инфраструктуры, используемыми для осуществления технического обмена информацией, и описывают, что системы могут делать, определяют дозволенные наборы кодов и т. д. Репозиториями FHIR могут выступать системы электронных медицинских записей (EHR), аптечные системы, медицинские информационные системы (МИСы) и т. д. Некоторые системы, например средства поддержки клинических решений, могут использовать интерфейсы FHIR, даже если они сами на самом деле не хранят никакой административной информации или данных пациента.

Каждый ресурс определяет небольшое количество узкоспециализированных данных. Одиночный ресурс мало о чем говорит, а вот набор вместе взятых ресурсов представляет собой клиническую запись, имеющую практическкую ценность. Инфрмационные системы связывают действия пользователя (поиск карты пациента, внесение записи в его историю и т.д.) с операциями над соответствующими ресурсами.

Бумажные формы (ресурсы) в FHIR являются общими; они должны подходить для различных стран, для разных типов врачей в разных контекстах (помощь человеку, ветеринарная помощь, общественное здравоохранение, научные исследования и т. д.). Понимая, что единый подход ко всем не приемлем в области здравоохранения, FHIR предоставляет возможность настраивать формы (ресурсы) таким образом, чтобы удовлетворить потребности различных пространств реализации определением "расширений", а также за счет применения ограничений. Например форма "prescription" может иметь элементы расширения, добавленные для отслеживания ограниченных в обороте лекарств, при этом также ограничивая коды, которые могут быть использованы для соотнесения видов лекарств с определенным государственным стандартом. Формы разработаны таким образом, что добавление к ним расширений не влияют на передачу форм между системами. Такая организация форм позволяет любой системе использовать заполненные формы, даже если в них есть дополнительные элементы, причем независимо от того, будет ли принимающая система использовать эти расширения или нет.

Чтобы не допустить усложнения базовых форм, которыми пользуются все, у FHIR есть правило, что в большинстве случаев ресурс будет включать только элементы данных, если ожидается, что большинство реализаций будут использовать этот конкретный элемент данных. Это не означает, что данные всегда должны существовать. Например большинство систем в мире способны отслеживать "дату смерти" пациента, хотя этот элемент будет пустым во многих историях болезни. С другой стороны, не так уж и много систем отслеживают цвет волос, поэтому цвет волос будет исключен из базовой формы, и те системы, которым он необходим (возможно, в особых клинических условиях или клиническом исследовании) смогут использовать FHIR-расширение для его ввода, если потребуется.

Чтобы поддерживать количество ресурсов в разумных пределах, некоторые из них описаны в довольно общем виде. Например ресурс Observation (Наблюдение) используется для записи основных показателей состояния организма, лабораторных результатов, психологических оценок и ряда других вещей. Для поддержки правил настройки для более узких областей (например "Что я должен отправить, если я хочу зафиксировать кровяное давление?"), FHIR позволяет создавать профили. Предстоит проделать большой объем клинической работы по формированию консенсуса по тому, как различные типы подробной клинической информации необходимо вводить и совместно использовать в конкретных условиях. Инструментарий для поддержки создания профилей непосредственно клиницистами входит в планы FHIR, но все еще находится на начальных этапах разработки.

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

Предполагается, что описательная часть будет присутствовать в большинстве экземпляров ресурсов, тем не менее, она может быть опущена в некоторых ограниченных обстоятельствах. В некоторых случаях описательная часть будет генерироваться из дискретной информации. Например описательная часть ресурса "patient" может выглядеть следующим образом:

Питер Джейс Чалмерс (ОФИЦИАЛЬНОЕ), Джим
идентификатор: MRN = 12345 (ОБЫЧНЫЙ)
контакт: тел: (03) 5555 6473(РАБОЧИЙ)
пол: МУЖСКОЙ
дата рождения: 25.12.1974
умер: нет
адрес: 534 Эдгин Санкт-Плезантвилл Виктория 3999 (ДОМАШНИЙ)

В иных случаях описательная часть может быть введена в виде комментария, содержащего произвольный текст, непосредственно специалистом, например направления, патологические отчеты и т. д. Некоторые фрагменты описательной части могут быть позже представлены в виде дискретных данных.

В дополнение к определению «форм» для обмена данными (ресурсов), FHIR также определяет набор интерфейсов, с помощью которых системы фактически совместно используют эту информацию. Есть четыре основных механизма - или "парадигмы" - обмена, поддерживаемые FHIR: через REST-интерфейс, обмен документами, отправку и получение сообщений, вызовы сервисов.

REST - это простейший механизм обмена. Продолжая метафору "формы", RESTful-сервер можно рассматривать как комнату, заполненную шкафами для хранения документов. В комнате есть шкаф для каждого "типа" формы (или "ресурса"), которую он поддерживает. В шкафу находятся папки, каждая папка имеет уникальный номер и соответствует одной конкретной сущности реального мира: одному пациенту, одному визиту, одному лекарственному средству и т. д. Каждая папка (представляющая собой отдельный экземпляр ресурса) содержит несколько листов бумаги, где каждый лист бумаги представляет собой определенную "версию" этого экземпляра. Каждый раз, когда кто-то обновляет запись, новый лист бумаги добавляется сверху в папку-регистратор. Чтобы увидеть историю ресурса, вам нужно всего лишь пролистать страницы в папке.

Нужно отметить, что медицинская карта обычно представляет собой папку со множеством вложенных папок, в которых хранится большой объем собранных вместе различных "форм" или "отчетов". Это удобно, если вы хотите просмотреть всю запись, но неудобно, если вы хотите внести изменения лишь в некоторые её части. Всегда присутствует конкуренция за доступ к записи, чтобы внести изменения в нужную часть. В компьютерных приложениях в целях оптимизации управления запись будет разбита на мельчайшие компоненты, и компьютер должен верно собрать нужные компоненты, следуя по заданным ссылкам от одного компонента к другому.

Теперь представьте клерка возле входной двери в эту комнату. Вы можете передать клерку заявку, чтобы он что-то сделал с информацией в этих картотечных шкафах. "Клерк" и набор бланков заявок на его столе составляют FHIR RESTful API. С этим API вы можете делать следующее:

  • поиск: Заставить клерка искать среди папок те, которые отвечают ряду критериев поиска, и выдать вам копию верхнего листа бумаги из каждой подходящей папки
  • чтение: Получить копию верхнего листа бумаги (представляющего собой последнюю версию) из какой-то определенной папки одного из шкафов
  • создание: Добавить новую папку в соответствующий шкаф (с новым номером)
  • обновление: Добавить новую страницу (версию) к содержимому определенной папки
  • удаление: Убрать папку из шкафа (или, точнее, виртуально удалить наклеиванием на неё стикера с надписью "не открывать")
  • история: Просмотреть все страницы в отдельной папке, в каком-то картотечном шкафу или, возможно, во всей комнате целиком. Такой широкий запрос будет применяться скорее в административных, чем клинических целях.
  • транзакция: Вручить клерку несколько листов бумаги для одновременного помещения их в различные папки
  • operation: Попросить клерка выполнить действие или процедуру над бумагами из одного или нескольких папок - например получить среднее количество пациентов, создать краткий отчет или выполнить сложный поиск, просто проставив галочки в заявке и сказав: "сделай это"

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

Документы - это хорошо известный механизм обмена информацией в области здравоохранения. Они полезны, когда есть желание управлять тем, как потребитель информации будет перемещаться по ней и есть необходимость в "замороженном" представлении информации, которое может быть надежно извлечено в будущем даже спустя годы. Примеры документоподобных объектов в здравоохранении включают в себя выписные эпикризы и лабораторные отчеты.

В FHIR есть специальный ресурс, который называется Composition (Композиция), который выступает в качестве "обложки" документа. Он определяет его название, дату создания, соответствующего пациента и оглавление. Документ в FHIR можно рассматривать как набор листов (экземпляров ресурса), сложенных в стопку с титульной страницей наверху и сшитых степлером вместе. Такая сшитая коллекция может храниться или передаваться, сообщая полный набор информации целиком за один раз.

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

Сообщение может быть запросом на выполнение лабораторной заявки или уведомлением для системы о том, что две записи пациентов были объединены, или что пациент был переведен из одной кровати в другую. Сообщение аналогично документу тем, что оно собирает ресурсы вместе, однако в случае сообщения "титульным листом" будет MessageHeader, выступающий в качестве заявления. И ресурсы соединены друг с другом не степлером, а скрепками для бумаг, и не предполагается, что принимающая система будет хранить содержимое сообщения точно в том виде, в котором они были получены, если вообще будет.

Сервисы можно рассматривать как облегченную версию обмена сообщениями. Вместо полной обложки к ресурсу прикрепляется небольшая записка. А иногда вместо того, чтобы отправить лист бумаги целиком, вырезаются необходимые куски и отправляются как фрагменты. Подобным образом, ответом на запрос будет служить сколотая скрепкой пачка экземпляров ресурса. Сервисы часто используют для таких целей, как поддержка принятия решений. Например "Есть ли проблема с назначением лекарств X пациенту Y?" или "Какой план ухода рекомендуется для пациента с условиями A, B и C?"

Возможности системы на основе FHIR определяются тем, какую информацию могут дать ресурсы и, с клинической точки зрения, историю болезни определяют следующие параметры:

  • виды ресурсов, которые определены
  • их содержимое и правила, применяющиеся к этим данным, например то, какие коды из справочников поддерживаются и/или требуются
  • как ресурсы ссылаются друг на друга
  • как вы можете искать информацию

Эту информацию можно найти на страницах с описаниями ресурсов. Ресурсы, которые скорее всего будут представлять интерес, можно найти в следующих модулях:

Инструкции о том, как интерпретировать информацию на страницах ресурсов, можно найти здесь. Скорее всего, понять их будет проще в виде логической таблицы и UML-диаграммы. Не забудьте зайти на вкладку с примерами для ознакомления с тем, какого рода информация может быть выражена с помощью ресурса. Увидеть, как элементы используются для передачи реальных данных часто оказывается более полезно, чем просто смотреть на определения. Также зайдите на вкладку профилей, чтобы увидеть примеры того, как можно ограничить различные ресурсы для использования в определенных контекстах.

Опыт использования FHIR в системе здравоохранения и других доменных областях, а также отзывы всегда приветствуются, поскольку мы продолжаем заниматься уточнением спецификации FHIR. В верхней части страницы каждого ресурса находится ссылка на страницу рабочей группы, ответственной за каждый конкретный ресурс. Если у вас есть отзывы по ресурсам, рассмотрите возможность своего участия.