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

Создаем профили средствами ClinFHIR

Создание пользовательских профилей или "профилирование ресурсов" ("profiling") - довольно "избитая" тема в англоязычном блоге Hay on Fhir. Суть "профилирования", о котором мы обещали подробно поговорить в предыдущей статье, заключается в возможности реализации спецификации FHIR с учетом локального "контекста" здравоохранения. В официальной документации стандарт FHIR назван "платформенной спецификацией" ("platform specification"), т.е. стандартом предусмотрена "платформа", на которой строится инфраструктура обмена данными. Сама инфраструктура определяет форматы передачи данных (wire formats), структуры и типы данных, информационные модели, справочники и интерфейсы, использование которых в конкретном контексте уточняется ("ограничивается" и "расширяется") пользователем.

Существует мощный и понятный простому пользователю ("простому" с некоторыми оговорками) инструмент для работы с профилями от Furore - Forge. Его удобство заключается в том, что (от пользователя) не требуется досконально знать структуру ресурса (нет необходимости "заучивать" спецификацию) или уметь редактировать XML-код ресурса. Вся работа будет выполнена с помощью удобного пользовательского интерфейса. Кроме того, единожды установленное приложение будет автоматически обновляться по мере выхода новых версий, а также для обеспечения соответствия новым версиям спецификации FHIR.

Тем не менее, работа c Forge от Furore предполагает как минимум общее понимание "профилирования", занимающего особое место в стандарте FHIR. CLinFHIR, в свою очередь, позволяет "пощупать" процесс создания профилей без необходимости "углубляться в дебри стандарта". Нам предлагается "быстро" создать профиль, например, для последующего его обсуждения и редактирования / изменения совместно с другими заинтересованными лицами. Результат, который получится при работе с ClinFHIR не будет продуманным до мелочей, "технически" сложным и совершенным. Скорее, на выходе получится "пробная" версия профиля, открытая для коллективного обсуждения и последующего дорабатывания.

Какой можно сделать вывод? ClinFHIR выполняет функции инструмента моделирования информации о здоровье (сlinical modelling): для решения конкретного кейса требуется дополненная модель какой-либо клинической концепции, однако, пока наилучшее решение (по модели) не очевидно, требуется инструмент, который позволит создавать промежуточные решения.

Небольшое "техническое" отступление о профилях

"Профилирование ресурсов" подразумевает их расширение за счет введения в структуру дополнительных полей или ограничение, например, допустимых значений полей. Речь может также идти и о "привязке" значений некоторого поля ресурса к пользовательскому справочнику (в том числе переопределение набора значений со стандартного на пользовательский). Все это становится возможными благодаря ресурсам особого типа - "StructureDefinition". Ресурс StructureDefinition может использоваться для исключения из структуры базового ресурса какого-либо поля (например, путем переопределения его кардинальности (cardinality) к значению [0..0]), для ограничения внутренней структуры ресурса и его содержимого (запрет вложенности в элементах), для наложения дополнительных ограничений на внутренние или внешние элементы ресурса, связанные с ним по ссылке (target of a resource reference).

Вернемся "на землю"

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

Создаем профиль базового ресурса

Откроем ClinFHIR перейдя по этой ссылке. ClinFHIR находится в процессе переезда на новый сервер, поэтому лучше воспользоваться предоставленной ссылкой и, кроме того, кликнуть по пункту "Reset Config" в выпадающем меню ClinFHIR ("шестеренка" в верхней панели), чтобы очистить кэш браузера. После очистки кэша будут установлены следующие параметры:

• Сервер данных (data server) для хранения пациентов и других базовых ресурсов: HAPI STU-3 server;
• Сервер для хранения профилей и других ресурсов, обеспечивающих "соответствие" (conformance server): Grahames STU-3 server;
• Терминологический сервер (terminology server), обслуживающий терминологические службы: Grahames STU-3 server;

Совершенно не обязательно работать именно с такой конфигурацией: можно выбрать другие серверы. Главное, чтобы они "опирались" на одну версию спецификации FHIR (например, STU-2), чтобы избежать "неприятных сюрпризов". (ClinFHIR даже может предупредить Вас, о том, что

"weird things may happen..."

)

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

Выполним следующие действия: нажмем на ссылку ‘Find Profile’ в центральной части рабочей области и выберем нужный тип ресурса. После этого, выбранный профиль появится в центральной части рабочей области Resource Creator. Обратите внимание на значок глаза слева от названия профиля. Вот, что мы увидим, нажав на "глазок":

(скопировать и вставить скриншот)

В области слева показано древовидное представление ресурса, причем, отображается список элементов, заполненных значениями, а не все допустимые поля ресурса, предусмотренные спецификацией. Реальный ресурс содержит произвольное кол-во элементов - меньше, чем определено в спецификации (если не все поля необходимы в конкретном контексте реализации) или больше (вводятся дополнительные поля через механизм "расширений"). В центральной части рабочей области находится подробная информация (Details) о содержимом конкретного узла дерева, выбранного в области слева. Кнопка "New Resource" (сверху) создает пользовательский профиль по выбранному нами стандартному профилю базового ресурса. (Помните, профиль - это такой же ресурс, как и все остальные?)

(скопировать и вставить скриншот)

Имя создаваемого профиля задается в поле в центральной части интерфейса. Введенное значение будет использоваться для уникальной идентификации профиля на сервере, "обеспечивающего соответствие" (Conformance Server). В случае, если профиль с таким именем уже существует на сервере, пользователь получит предупреждение.

Рабочая область слева имеет дополнительный набор кнопок: "Remove from profile" удалит выбранный элемент ресурса, кнопки "Child Node" (добавить "потомка") и "Add Sibling Node" (добавить элемент одного уровня вложенности с текущим) используются для добавления новых элементов в структуру ресурса.

По нажатию на кнопку "Add child node" в правой части появятся форма для ввода данных, которые будут передаваться создаваемым пользовательским элементом:


(скопировать и вставить скриншот)

Поставим перед собой комическую задачу - описать структуру ресурса, в котором помимо определенных спецификацией полей будут также передаваться данные о фазе луны (moonPhase) на момент создания экземпляра ресурса. Тип данных нового элемента - простая строка (simple string), значение кардинальности элемента - [0..1]. По нажатию на кнопку "Add", увидим следующее:

(скопировать и вставить скриншот)

Обратите внимание, только что созданный элемент "moonPhase" является потомком (вложен) элемента "created". В нижней части рабочей области перечисляется список внесенных в ресурс изменений (Changes), которые заключаются в добавлении и удалении элементов. Внесенные изменения можно отменить. Нажмем на кнопку "Save" (она, кстати, появляется только тогда, когда пользователь задаст имя создаваемого им профиля без пробелов). В результате будет создан новый "пользовательский" профиль.

С технической точки зрения ClinFHIR генерирует "описание расширения" (extension definition) для каждого из созданных элементов (целый ряд ресурсов structureDefinition), а затем сохраняет профиль, содержащий ссылки на описания расширений для каждого из добавленных пользователем элементов (полей).


Чтобы вернуться на главную страницу Resource Creator закройте диалоговое окно, сообщающее об успешном создании профиля. Теперь наш профиль отображается в списке профилей:

(скопировать и вставить скриншот)

Последний шаг

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

(скопировать и вставить скриншот)

Предостережения от Дэвида:

• Задача, которую ставит перед собой ClinFHIR, заключается в демонстрации (в максимально упрощенном виде) процесса создания пользовательских профилей для базовых ресурсов. Все что делает CLinFHIR в данном случае - это генерирует расширения (extensions) для полей ресурса, которые не предусмотрены базовой спецификацией, а определяются пользователем. В обычной ситуации лучше было бы попытаться найти в репозитории профилей такой профиль, который решает конкретный клинический кейс, и, только если такого профиля нет, создавать собственный.
• ClinFHIR не позволяет создавать по настоящему "сложные" профили со сложными элементами или привязывать допустимые значения пользовательского элемента к наборам значений (value set) (пока что). Причина проста - это и не планируется, так как есть более продвинутые инструменты, такие как Forge от Furore.
• Указывая ссылку на ресурс, нельзя указать тип ресурса
  
  (When you specify a resource reference you can’t specify a resource type/s)
• Эта функция ClinFHIR работает только с серверами, поддерживающими STU-3, однако, все также нужно помнить, что тестовые серверы могут работать нестабильно.

Что будет добавлено и доделано в ближайшее время:

• Можно будет выбирать (из списка) уже существующие описания расширений (extension definition);
• Привязка к наборам кодированных значений;
• Поддержка комплексных (сложных) расширений;
• Возможность указывать тип ресурса, если расширение ссылается на ресурс;
• Поддержка всех типов данных;

Эта статья - перевод оригинальной статьи, опубликованной 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 пациента).

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

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

На одной из относительно недавних встреч рабочих групп HL7 председатель HL7 International Стэн Хафф (Stan Huff) высказался о роли сообщества медицинских специалистов в разработке профилей ресурсов. В его выступлении прозвучала одна немаловажная мысль: "в отсутствие координации усилий по разработке профилей, существует риск создания множества схожих структур данных, используемых для передачи схожих или одинаковых наборов данных". Т.е. без координации усилий по этому направлению мы рискуем начать движение в "обратном от интероперабельности направлении". Стандарт FHIR, в свою очередь, предусматривает возможности для совместного создания профилей (о которых, скорее всего не знают врачи и аналитики), поэтому, важной задачей является распространение информации о такой возможности стандарта.

В последние годы в ходе встреч рабочих групп и именно для привлечения медиков к процессу развития стандарта проводятся т.н. "коннектафоны (или "коннектатоны" - кому как нравится) для клиницистов" ("Clinical Connectathons"). Также как и "коннектафоны для инженеров" (а они проводятся для того, чтобы поставщики решений в сфере HealthIT попробовали интегрироваться друг с другом с использованием стандартных протоколов и интерфейсов от HL7), такие конференции позволяют обмениваться информацией о стандарте FHIR и его (добавленных) возможностях. Для проведения "клинических коннектатонов" были созданы удобные и понятные медикам наборы инструментов для работы с FHIR-ресурсами и их профилями. Такие программные инструменты "жизненно необходимы", потому что позволяют "попробовать" стандарт (протестировать его использование) на практике. Разработка программы для медиков "с нуля" - дело непростое (в силу их специфики). Именно поэтому, ClinFHIR (как "учебный" инструмент манипуляции ресурсами и профилями для медиков) - это открытый (open source) проект, готовый изменяться в соответствии с пожеланиями его пользователей и советами экспертов.

Некоторые важные разъяснения касательно ClinFHIR:

• ClinFHIR - это онлайн-ресурс, взаимодействие с которым осуществляется с помощью браузера (предпочтительно использоваться Chrome, но подойдет также любой современный браузер).
• ClinFHIR находится на стадии развития и будет изменяться с течением времени. Тем не менее мы попытаемся сохранить интуитивно-понятный интерфейс даже при добавлении новых возможностей.
• ClinFHIR не следует расценивать как полноценную ЭМК-систему или редактор медицинских записей. Он лишь нацелен на демонстрацию принципов стандарта FHIR на базовом уровне. Нецелесообразно создавать такой интерфейс для ЭМК-системы (хотя EHR-системы на базе FHIR вполне реальны).
• Все вводимые данные сохраняются на общедоступном тестовом сервере (сервер Грэма Грима) (не принимайте данные на сервере всерьез! - это просто тестовые данные).
• Кроме того, учитывая то, что стандарт FHIR еще не сформировался как "нормативный", мы не можем гарантировать, что загружаемые на сервер данные будут сохранены в неизменном виде (механизмы работы сервера могут измениться).

В настоящий момент ClinFHIR состоит из двух основных модулей:

• Resource Builder (конструктор ресурсов) используется для создания (и сохранения на сервере) FHIR-ресурсов, структура которых определена загружаемыми или встроенными в Resource Builder "определениями ресурсов" (definitions). Под определением ресурса следует понимать описание внутренней структуры и набора содержащихся в нем данных, т.е. "профиль". Resource Builder позволяет просматривать все ресурсы, связанные с конкретным пациентом, отображает взаимосвязи, установленные между ресурсами.
• Profile Builder (конструктор профилей) позволяет редактировать профили, чтобы их можно было использовать для решения конкретных задач, связанных с обменом клиническими данными.

В отличие от Forge (FURORE) данный набор инструментов не следует рассматривать как полноценный продукт для работы с FHIR-ресурсами. тем не менее ClinFHIR достаточно хорошо, чтобы получить представление о принципах работы стандарта FHIR. К тому же не следует забывать, что ClinFHIR создан специально для врачей, а не для инженеров.