Эта статья - перевод оригинальной статьи, опубликованной 3 августа 2015 года в блоге Hay on FHIR, дополненная и согласованная с автором (David Hay).

Работаем с ClinFHIR: Создаем FHIR-ресурсы по стандартным профилям

Основой для данной короткой статьи послужили несколько публикаций (Дэвид назвал их даже "мини-серией") в блоге "Hay on FHIR". Все они были посвящены созданию и редактированию простых профилей (ClinFHIR не рекомендуется использовать для работы с "большими и страшными профилями". Для этого лучше всего подойдет Forge от Furore). Давайте коротко рассмотрим процесс создания ресурса типа Patient как "центрального" ресурса, с которым будут логически связаны другие клинические ресурсы, и ресурса Encounter ("обращение за получением медицинской услуги") по уже существующему стандартному профилю. Сущность т.н. процесса "профилирования" ресурсов (в оригинальной спецификации это называется "resource profiling") мы обсудим уже в последующих публикациях.

Небольшая "вводная"

ClinFHIR позволяет создавать экземпляры:

• базовых ресурсов (core resource), т.е. ресурсов, структура и содержимое которых определяется непосредственно стандартом FHIR;
• "профильных" ресурсов (profiled resource), структура и содержимое которых определяется (пользовательским) профилем.

Ресурсы - это самостоятельные "кирпичики", из которых складывается информация о здоровье. Ресурсы независимы с точки зрения смысла и могут самостоятельно участвовать в информационном обмене. Существуют ресурсы различных типов, предназначенные для "фиксации" и передачи данных о пациенте, эпизоде лечения, лекарственном препарате, записи на приём к врачу и т.д.

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

Поиск пациентов на FHIR-сервере средствами ClinFHIR

Интерфейс Resource Creator

Запустим Resource Creator (один из модулей ClinFHIR) и выберем пациента, с данными которого мы будем работать (для этого нужно нажать на ссылку "Select Patient").

Выбрать пациента можно введя в поиске какое-либо произвольное имя. Введем в поле фамилию "Richards", а в результатах поиска выберем пациента с именем "Richards Robert". Может возникнуть вопрос - "Зачем выбирать пациента, если мы просто решили создать некоторый ресурс, основываясь на формальном описании его структуры?" Дело в том, что в рассматриваемом случае (т.е. когда мы взаимодействуем с сервером, на котором размещаются клинические данные) большая часть ресурсов, используемых для представления клинических, демографических и административных данных должна быть связана с конкретным пациентом. Пациент же должен быть представлен ресурсом типа "Patient".

Поиск пациента (при нажатии на ссылку "Select Patient")

Вполне возможно, что на сервере могут быть созданы несколько ресурсов типа "Patient", с одинаковым именем (имеется ввиду имя человека, записываемое в поле "name" с типом данных "HumanName"). В таком случае отличить ресурсы можно будет по идентификатору пациента (id). В нашем примере идентификатор пациента Richards Robert будет показан в верхней панели меню Resource Creator (конечно, после того, как мы выберем данного пациента в рабочей области, озаглавленной My recent Patients).

Не забудьте выделить Richards Robert в списке пациентов

Данные о пациенте хранятся на сервере HAPI. Об этом говорит установленное по умолчанию значение "HAPI Server" выпадающего списка в левой части рабочей области Resource Creator. В текущей версии ClinFHIR можно работать только с несколькими "жестко заданными" тестовыми серверами, однако, впоследствии будет добавлена возможность взаимодействовать с внешними серверами. Кстати, кнопка Test предназначена просто для проверки работоспособности сервера (мало ли что может с ним случиться).

Создаем нового пациента на одном из тестовых серверов с помощью ClinFHIR

Resource Creator позволяет создавать ресурсы "в два приема":

1. выбираем пациента с которым будет "связан" создаваемый нами ресурс (в большинстве случаев FHIR-ресурсы связаны с каким-либо конкретным пациентом),
2. выбираем стандартный или пользовательский профиль (шаблон).

Как мы уже видели ранее, в левой части интерфейса находится область для выбора пациента (озаглавленная "My Recent Patients"). В ней нас интересует элемент "Select Patient", по которому открывается окно поиска. Выпадающее меню позволяет выбирать сервер, на котором хранятся ресурсы или на который можно разместить создаваемый нами ресурс.

Давайте попробуем создать новый ресурс типа "Patient" на сервере Public HAPI Server STU3 (выбор на него пал совершенно случайно). Для этого перейдем по ссылке "Select Patient", затем по ссылке "Add new Patient" слева в нижней части окна поиска. Перед нами откроется форма для ввода данных, в которой необходимо указать имя пациента (First Name), фамилию (Last Name), дату рождения (Date of Birth) и пол (Gender). Кроме того, если поместить флажок напротив элемента Generate samples, то для данного пациента будут сгенерированы «тестовые» экземпляры ресурсов. Для созданного нами пациента с именем Eugene Mozolev (76433) были сгенерированы ресурсы типа Encounter, Condition, Appointment, Observation и ProblemList.

Создаем нового пациента на сервере Public HAPI Server STU3

В верхней панели меню перейдем по ссылке "Details", чтобы просмотреть все ресурсы, связанные с пациентом Eugene Mozolev (76433). В левой части интерфейса размещается список всех ресурсов, имеющих одинаковый id. Это 2 ресурса Appointment (запись на приём), 2 ресурса типа Condition (заболевание, проблема со здоровьем), 5 ресурсов типа Encounter (обращение за медицинской помощью, "взаимодействие с медицинской организацией"), 1 ресурс Patient (пациент), 2 ресурса типа Practitioner (врач, медицинский или социальный работник).

Resource Browser открывается по нажатию на Details в верхней панели меню

В списке слева выберем тип ресурса Appointment, а затем в появившемся слева от него списке ресурсов этого типа (Appointment resources) выберем первую запись (Investigate Angina Clarence cardiology clinic). Тогда еще немного левее появится блок с JSON-кодом выбранного нами ресурса Appoinment/76439.

Разберем по частям JSON ресурса Appointment

Ресурс Appointment

В атрибуте "resourceType" указан тип ресурса "Appointment", затем "id", который идентифицирует не сам ресурс, а пациента, к которому данный ресурс относится. Далее в блоке "meta" содержатся два параметра - "versionId" (сколько раз данный ресурс подвергался правкам) и "lastUpdated" (дата последней правки ресурса).

В блоке "text" размещается человекочитаемое описание содержимого ресурса, которое может использоваться для представления человеку. "Status" "generated" говорит о том, что содержимое было сгенерировано на основании формализованного содержимого.

"status" : "pending" (другие варианты - "proposed", "booked", "arrived", "cancelled" и т.д.) говорит, что не все участники приёма (окончательно) подтвердили свое участие в событии (в спецификации это определено как

"Some or all of the participant(s) have not finalized their acceptance of the appointment request"

В соответствующих атрибутах указана информация о дате / времени начала и окончания приема, его длительности (в минутах).

Блок participant перечисляет всех участников приёма. В нашем случае это "Patient/76433" и "Clarence cardiology clinic". Атрибут "status" со значением "accepted" определяет, что конкретный участник подтвердил свое участие в событии.

Назад к Resource Browser

Наконец, четвертая (самая правая) колонка, содержит списки связанных ресурсов. Стандарт FHIR предусматривает два вида "ссылок" - outward references (внешние ресурсы, на которые ссылается данный ресурс) (большая часть ресурсов ссылается на ресурс типа Patient именно по outward reference) и inward references (ресурсы, которые ссылаются на данный ресурс). Зачем понадобилось указывать два вида взаимосвязей? Согласно спецификации ссылки между ресурсами организуются всегда только в одном направлении - от объекта-источника (source) к целевому объекту (target). Хотя логическая связь между объектами существует, она явно не представлена в ресурсе.

Создаем экземпляр ресурса Encounter по стандартному профилю

После того, как мы создали и выбрали пациента (напомню: Eugene Mozolev (76433)), выберем профиль ресурса, по которому будет создан ресурс нужного нам типа. В выпадающем меню в центральной части рабочей области, посвященной работе с профилями (My recent profiles) выберем сервер "Public HAPI server STU3". В открывшемся окне в параметрах запроса (Query Parameters) выберем интересующий нас тип ресурса - "Encounter". Это стандартный базовый тип ресурса, определенный спецификацией FHIR. Нажмем на кнопку "Select Encounter".

В окне поиска профиля укажем только Resource Type и нажмем Select Encounter

Вот что должно получиться в конечном итоге:

Обратите внимание, что в верхней панели справа, рядом с кнопкой главного меню (в виде "шестеренки") появилась кнопка "New Resource".

Теперь можно переходить непосредственно к созданию ресурса. Нажмем на кнопку New Resource в верхней панели меню. Появится рабочая область следующего вида:

Так выглядит рабочая область для создания ресурса по профилю

Как и главная страница Resource Creator, рабочая область разделена на три секции:

• В области слева (Resource Navigator) в форме дерева отображена структура создаваемого нами ресурса. Чем больше "полей" ресурса будет заполнено значениями, тем "обширнее" ("ветвистее") будет дерево элементов ресурса. Чтобы заполнить данными какой-либо элемент, необходимо выбрать в Resource Navigator родительский (по отношению к нему) элемент. Encounter (т.е. сам ресурс) является родительским элементом верхнего уровня. Его нужно выбирать для заполнения элементов второго уровня.
• В центральной области (Element Details) размещается подробная информация по выбранному ресурсу (в нашем случае это Encounter) и всем его элементам-потомкам. Здесь же наряду с другими элементами показаны расширения (extensions), намеренно выделенные цветом. При нажатии на элементы в центральной области, в области справа появляется форма ввода данных, которая позволяет вводить неформатированный текст, выбирать значение элемента из списка доступных (если выбранный элемент привязан к некоторому "набору значений" - value set), т.е. всячески "задавать содержимое" нужного нам поля ресурса.
• В правой части рабочей области (Resource: JSON) показано JSON-представление ресурса, область ввода данных (Data Entry), которая изменяется в зависимости от того, какой параметр (поле) ресурса мы собираемся заполнить данными в текущий момент.

Так выглядит процесс создания ресурса по стандартному профилю:

1. Выбираем родительский узел в Resource Navigator,
2. Выбираем заполняемый элемент ресурса в Element Details,
3. Вводим данные в правой части рабочей области,
4. Повторим столько раз, сколько необходимо.

Любой ранее заполненный нами элемент можно удалить, предварительное выбрав его в Resource Navigator и затем нажав на красную кнопку "Remove" в центральной области.

Работает функция "отложенного заполнения" ресурса (park resource). Это означает, что заполнение элементов ресурса можно отложить, чтобы создать другой ресурс (это может быть необходимо для организации взаимосвязей между ресурсами). Данная функция (park) доступна только в процессе создания ресурса.

Создаваемые ресурсы сохраняются на тот же сервер, на котором размещен выбранный нами ранее ресурс типа Patient (кнопка "Сохранить" в правом верхнем углу навигационной панели). Рядом с кнопкой "Save" также находится кнопка "Validate", которая проверяет корректность заполнения ресурса (т.е. его "валидность"). Фактически, когда пользователь нажимает эту кнопку на (ранее выбранный) сервер отправляется запрос типа:

POST [server]/[resource type]/$validate 

После создания (и, соответственно, сохранения) ресурса, просмотреть все существующие ресурсы можно перейдя в Resource Viewer (нужно просто нажать на ссылку Details, размещенную в верхней панели рядом с именем и id пациента).