Модуль Value Set Editor (редактор наборов значений) в составе clinFHIR

Перевод оригинальной статьи, опубликованной Дэвидом Хэйем 30 мая 2016 года в блоге Hay on FHIR

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

Но, есть еще одно интересное направление в стандарте FHIR, которые мне не хотелось бы обойти и которое имеет прямое отношение к профилям - это создание и редактирование т.н. "наборов значений" (value sets).

Небольшое отступление: основной целью создания профилей является "адаптация" базовых ресурсов (core resources) для их применения в реальных условиях т.е. для решения конкретных кейсов. Адаптация базовых ресурсов выражается в создании новых "элементов" (полей) ресурса и исключения неиспользуемых. Бывает, что в процессе создания профиля требуется определить некоторый ограниченный набор значений (или набор кодов), которые может принимать заданный элемент ресурса. Для этих целей (т.е. для определения набора таких значений) используется механизм, названный "value set". Проблема заключается в том, что в настоящее время нет какого-либо доступного инструмента для создания наборов значений (кроме тех приложений и инструментов, которые используются непосредственно при разработке спецификации). Именно поэтому мне в голову пришла мысль разработать приложение, ValueSet Editor, т.е. редактор наборов значений.

Пояснение спецификации FHIR: Ресурс "ValueSet" (набор или подмножество значений) используется в стандарте FHIR для определения наборов кодов, в том числе извлеченных из одной или нескольких систем кодирования. Спецификация FHIR разделяет такие (ключевые) понятия, как code system (система кодирования) и value set (набор значений). Под системой кодирования (также используют термины "перечисление", "терминология", "классификация", "онтология") следует понимать набор кодов, где каждому коду сопоставлено отдельное значение. Под набором значений понимается выборка или подмножество кодов, извлеченный из одной или нескольких систем кодирования. Иначе говоря, коды с заданным символьным выражением и смыслом организуются в системы кодирования, а затем извлекаются из одной или нескольких систем и группируются (в наборы значений) для решения конкретных задач.

Наборы значений (ValueSet) могут быть двух типов:

1. Система кодирования (т.е. набор кодов, объединенных по какому-либо принципу) может быть определена при создании набора и в полном объеме быть реализована в наборе значений (in-line);
2. Набор значений может составляться из кодов, извлеченных из других систем кодирования, двумя способами: (1) простым перечислением кодов (in-line) или (2) заданием критериев выбора данных кодов. Простые наборы значений ("in-line", т.е. те, которые составляются простым перечислением кодов) используются в привязке к "простым справочникам", предназначенным для внутреннего использования. Такие справочники представляют собой простое (небольшое) перечисление допустимых значений, набор кодов состояний, списки слов и т.д. Инлайновые наборы значений не предназначены для работы с большими справочниками и терминологиями, поддержка которых осуществляется известными организациями (SNOMED, LOINC). Работа с такими справочниками возможна через наборы значений второго типа.

Набору значений соответствуют два URL - логический идентификатор и указатель на ресурс (локатор) - оба используемые в качестве ссылки на набор значений. Локатор ресурса - это URL-адрес, по которому может быть получен ресурс, чаще всего с FHIR-сервера. Иначе, локатор ресурса - это относительная ссылка на ValueSet-ресурс; ее разрешение происходит относительно сервера, на котором размещен ресурс. Логический идентификатор хранится в самом ресурсе, а именно в поле "ValueSet.ulr" и используется для ссылки на данный набор значений из любой системы.

Также как и возможности clinFHIR по созданию профилей, функционал ValueSet Editor очень ограничен. На настоящий момент некоторые функции ValueSet Editor замкнуты исключительно на SNOMED, хотя предназначаются для работы и с другими терминологиями, если их поддерживает выбранный терминологический сервер (terminology server). Новое приложение позволит создавать и редактировать наборы значений, правда, пока нет возможности редактировать чужие наборы значений, например, те, которые поставляются вместе с спецификацией, по вполне очевидным причинам. Однако, можно создавать их копии и редактировать для использования в рамках конкретного кейса.

Открыв страницу с приложением, выберем терминологический сервер (terminology server), на котором будем хранить создаваемые наборы значений. Терминологический сервер можно выбрать в панели меню в верхней части экрана. Приложение требует от сервера реализации ряда служб (определенных в STU-3), а именно:

• Поиск концепций (concept lookup) используется для просмотра концепций (терминов или понятий), организованных в иерархическую структуру;
• Развертывание набора значений (value set expansion) используется для поиска концепций "по имени".

(К слову сказать, на данный момент только сервер Грэма поддерживает третью версию стандарта HL7 в отношении терминологических сервисов (Наверное, речь идет о hl7 v3 core principles). Надеюсь, что и другие серверы скоро будут поддерживать v3!)

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

Чтобы просмотреть находящиеся на сервере наборы значений введем что-нибудь в поле поиска (например, "condition") и нажмем "find". Наборы значений, соответствующие введенному ключевому слову (поиск применяется к имени набора значений, а не к его содержимому), будут представлены пользователю в виде списка. Можно предварительно просмотреть (preview) набор значений (т.е. просмотреть json valueSet-ресурса) или сразу перейти к нужному набору значений (select). Во втором случае откроется редактор в режиме просмотра (view mode). Ниже показан список наборов значений в режиме поиска.

Редактор (Editor) - это основной инструмент для работы с наборами значений. Открыть редактор можно только после выбора или создания набора значений (иначе, для редактирования уже существующего набора).

В области слева размещаются 4 вкладки.

• Вкладка "Contents" отображает концепции, включенные в выбранный набор значений. Value Set Editor поддерживает работу с 2-мя типами наборов значений: (1) перечислением концепций и (2) наборами значений, определенными фильтром, который выбирает из справочника (в нашем случае SNOMED) концепции, связанные отношением "является" ("is-a").
• Вкладка "Description" содержит описание набора значений (краткое описание, требования, информацию о его создателе и т.д.). Эту информацию можно изменить при создании нового или производного набора значений. Во всех иных случаях данная информация предназначается только для чтения.
• Вкладка "Expansion" позволяет выполнять развертку набора значений (ту же операцию позволяет выполнять и Resource Builder). В поле поиска вводятся ключевые слова, по которым терминологический сервер фильтрует "развертку" набора значений, т.е. отображает только концепции, соответствующие введенным поисковым критериям.
• Вкладка "JSON" отображает json-код ValueSet-ресурса (по сути выполняет функцию, аналогичную "preview" при поиске).

Небольшое пояснение: Развертка набора значений "превращает" ValueSet-ресурс в простую коллекцию пронумерованных кодов, используемых при вводе данных или для валидации значений элементов ресурсов.

Описать процесс развёртывания набора значений (Value Set Expansion) можно следующим образом: приложение, поддерживающее стандарт FHIR, опрашивает терминологический сервер о конкретном наборе значений, сервер возвращает список кодов, входящих в заданный набор значений. Данный процесс называется именно развёртыванием, потому что входящие в набор коды, могут быть определены через описание критериев, по которым они извлекаются из заданных справочников и включаются в набор значений. Применение фильтра (т.е. выполнение описанных критериев отбора) по отношению ко всем кодам справочников и формирование из них некоторого подмножества и есть "развертывание набора значений". Иногда, если в запрашиваемый набор значений входит слишком большое кол-во кодов, сервер может возвращать код ошибки "too-costly" (операция требует слишком много ресурсов сервера).

Последнее, что еще хочется отметить: развертка может выполняться с применением фильтра, т.е. на список кодов, полученный в результате развертки, накладывается дополнительный фильтр. Развертка выполняется над набором значений, хранящимся на терминологическом сервере, поэтому, при внесении каких-либо изменений, следует их обязательно сохранять!

А теперь небольшой скриншот (сконцентрируем внимание на вкладках "contents", "description", "expansion", "json"):

На скриншоте показан созданный мною тестовый набор значений, содержащий три простые концепции (specified concept) и одну концепцию, заимствованную из справочника и имеющую связь "является" ("is-a").

Область справа (на скриншоте она была незаполненной) используется для добавления концепций в наборы значений, доступные для обновления. Давайте этим сейчас и займемся. Добавление концепций возможно двумя способами: (1) можно создать копию существующего набора значений или (2) создать новый набор значений "с нуля". Функция создания копии набора значений достаточно удобна, однако, что ClinFHIR слишком простое приложение, которое не может редактировать сложные наборы значений. Можно просмотреть json сложных ValueSet-ресурсов, они также будут работать в Value Set Editor (например, можно будет выполнять развертку), однако возможность по внесению изменений будет ограничена.

Создать копию или новый экземпляра ValueSet-ресурса можно нажатием на соответствующие кнопки в панели меню справа вверху.

• На главной странице приложения (в этой области) размещается кнопка "new".
• Кнопка "copy" появляется при просмотре уже существующего на сервере набора значений.

В любом случае (как при создании "с нуля", так и при работе с копией ресурса) потребуется ввести новое имя. Присвоенное имя должно быть уникальным в рамках данного терминологического сервера; оно также будет использоваться в качестве id ValueSet-ресурса. Введите имя ресурса в появившееся диалоговое окно, а затем нажмите кнопку "Check". Если введенное имя будет уникальным для данного сервера, появится кнопка "Select", иначе будет сообщено об ошибке и потребуется ввести другое имя.

Выбрав валидное имя для нового набора значений, вы будете возвращены в редактор, где в правой части появится панель "Add concept" (область справа специально предназначена для добавления концепций в набор значений).

Существуют два способа добавить новую концепцию в набор значений и 2 роли, которые могут выполнять концепции (все это описано выше).

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

Чтобы выбрать концепцию можно воспользоваться вкладками "select from binding" или "enter directly". "Select the binding" имеет аналог и в Resource Builder: сервер выполнит поиск концепций, соответствующих критериям поиска, предварительно выполнив развертку набора значений.

Из списка концепций, которые я добавил в мой набор значений, я выбрал "Asthma finding (finding)" (то есть "is-a included concept" или "концепцию-фильтр", как мы определили выше):

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

Чтобы добавить выбранную концепцию в набор значений, нажмите на кнопку "Add" или “Add as ‘is-a' ”. Разница между этими кнопками заключается в следующем:

• Кнопка "Add" позволяет добавить только одну концепцию. В таком случае, если набор значений был изначально пуст, то он будет содержать (теперь) только одно значение.
• Кнопка “Add as ‘is-a' ” добавит концепцию-фильтра (то есть, по сути целую группу концепций, связанных с данной концепцией связью типа "as is"). В моем примере концепция "абсцесс легкого с пневмонией " (Abscess of lung with pneumonia) будет включена в набор, т.к. она является потомком "pneumonia", а саму концепцию pneumonia мы добавили как "фильтр".

На скриншоте также ясно видно, что (по крайней мере, в SNOMED) одна концепция может быть потомком нескольких "родителей" (SNOMED поддерживает сетевую модель отношений для входящих в нее концепций). Т.е. концепции SNOMED связаны отношением "is-a" ("является") сразу с несколькими концепциями.

Некоторые замечания:

• Приложение автоматически маркирует создаваемые в нем наборы значений меткой "clinfhir" (отмеченные наборы значений можно редактировать).
• Когда речь идет о "концепциях-фильтрах" (может быть, не совсем корректно мы определили этот тип концепции в русском переводе, но "пусть будет так"), помните, что поиск среди потомков осуществляется по имени концепции. Используйте ключевые слова, в смысловом отношении связанные с концепцией-фильтром (то есть с родительской концепцией). По умолчанию в качестве поискового термина будет использоваться имя, присвоенное набору значений при его создании (оно также используется в качестве идентификатора valueSet-ресурса на сервере).
• Иногда вместо имени сервера редактор может показывать "undefined". Хотя в этом случае редактор будет работать нормально, для исправления проблемы можно запустить Resource Builder и сбросить настройки конфигурации (выбрать "reset config" в меню в верхнем правом углу). При повторном запуске ValueSet Editor имя сервера будет определено как "Grahames Server".
• При создании набора значений (ValueSet) "с нуля", лучше перезагрузить приложение, чтобы "обнулить" все внутренние переменные.
• Периодически сервер Грэма сообщает о проблеме с базой данных ("deadlock"), поэтому, если такая проблема возникнет и у вас, просто повторите выполненные действия.
• При поиске концепции по имени (также как и в Resource Builder) приложение использует в качестве базового набор значений http://hl7.org/fhir/ValueSet/condition-cause т.к. как он является ссылкой на все коды номенклатуры SNOMED. Это временно и скоро появится возможность задавать "корневую концепцию" (root concept) для поиска по ограниченному набору концепций.

Визуализация взаимосвязей ресурсов в clinFHIR

Перевод оригинальной публикации Дэвида Хэя от 14 июня 2016 года в блоге Hay on FHIR

Недавно я обсуждал с одним из моих коллег (Viet Nguyen) улучшения в интерфейсе ClinFHIR, позволившие отображать некоторые типы ресурсов (Encounter, Observation, Condition) в более "удобоваримом" для пользователя виде. После демонстрации всех новых возможностей он предложил мне

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

Принимая во внимание то, что сама по себе концепция ClinFHIR заключается в отходе от традиционной ("документарной") парадигмы отображения медицинских данных, я принял решение немедленно реализовать такую диаграмму в интерфейсе ClinFHIR, тем более, что в свободном доступе есть целая библиотека (vis.js), существенно упрощающая построение таких графических моделей!
Итак, чтобы "насладиться" новой функцией ClinFHIR, выберите модуль Resource Builder на сайте http://clinfhir.com. Выберите дата-сервер (тот который хранит ресурсы типа patient и называется patient server). Конечно, данная функция может работать с любым сервером, т.е. анализировать взаимосвязи между ресурсами на любом сервере, но целесообразнее всего обращаться именно к data server для визуализации осмысленных с точки зрения пользователя взаимосвязей.
Прежде чем визуализировать взаимосвязи между ресурсами их необходимо определить. Для этого у нас есть несколько вариантов:

1. Вручную определить взаимосвязи (ссылки) между ресурсами, в смысловом отношении привязанным к конкретному пациент, средствами Resource Creator. Это конечно "сложно, но можно".
2. Воспользоваться функцией sample creator, встроенной в clinFHIR. Для этого нажмем на ссылку "Select Patient", "Add new Patient" и создадим нового пациента с сопутствующим набором тестовых ресурсов (create a patient with samples) (есть там такая "галочка"). Общедоступный сервер HAPI STU-3 позволяет создавать новых пациентов с богатым набором тестовых данных.
3. Также можно выбрать любой другой сервер, который обеспечивает большое разнообразие тестовых данных.

Так я поступил в этот раз (то есть остановился на третьем варианте), выбрав сервер Мичиганской сети информации о здоровье (Michigan Health Information Network) в качестве источника клинических данных пациентов (в списке серверов он называется MiHIN). Данная организация занимается формированием наборов тестовых данных о здоровье, критически необходимых и важных для дальнейшего внедрения и реализации стандарта FHIR в реальных проектах здравоохранения. Если сервер MiHIN сразу не появился в списке доступных серверов Resource Builder, вам понадобиться сбросить кэш вашего браузера, выбрав в меню модуля пункт "reset config", а затем перезагрузить страницу.
Выберем пациента (в моем случае это Karen Florence Smith) и затем перейдем по ссылке "Details" в верхней навигационной панели, чтобы перед нами открылся просмотрщику ресурса (resource viewer). Resource viewer включает в себя три вкладки:

• Проводник ресурсов (Resource Explorer)
• Граф взаимосвязей ресурсов (Resource References Graph)
• Временная шкала обращений за медицинской помощью (Encounter timeline)

Поговорим подробнее о каждой из вкладок.
Resource Explorer - это просмотрщик, отображающий типы ресурсов, связанных ссылками с конкретным ресурсом типа patient. Он позволяет просматривать json или xml других (типов) ресурсов, связанных с конкретным пациентом, скачивать их и передвигаться по ссылкам между ресурсами. При выборе ресурса (например, encounter) появится новая вкладка "References" в центральной части рабочей области (там же, где вкладки "Json", "XML", "Display"). Открыв эту вкладку мы увидим "граф взаимосвязей" ресурса, отображающий все ресурсы, на которые ссылается "центральный" (или иначе, "активный") с точки зрения пользователя ресурс. В настоящий момент речь идет о некотором ресурсе типа encounter и других ресурсах, которые связаны с ним ссылками.

По сути, на графе отражена та же информация, что и в панели справа в текстовом представлении. Тем не менее, на мой взгляд графическое представление делает связи между ресурсами более понятными. Можно даже "подергать" прямоугольники ресурсов мышкой и увидеть, как они сцеплено двигаются в выделенной для графика рабочей области. Нажатие на любой из ресурсов на графе (также как и в панели справа) переведет выбранный ресурс "в фокус", что позволяет передвигаться между ресурсами по ссылкам. (Кстати о цветах: не помешала бы помощь UI/UX дизайнера в выборе цветовой гаммы для элементов графа!)
Во вкладке "Display" ресурсы типа Encounter, Observation и Condition будут представлены в более понятном для пользователя виде (этот вариант отображения ресурсов скоро будет доступен и для других типов ресурсов). На скриншоте ниже по тексту отображен ресурс типа enocounter. Вкладка "Display" не обязательно будет отображаться все данные, которые содержит код ресурса. Для этого у пользователя есть возможность просмотреть xml или json ресурса. (На данный момент, например, вкладка Display не отображает "расширения").

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

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

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

Граф взаимосвязей выбранного ресурса типа encounter (ничем не отличающийся граф покажет и resource browser). При нажатии на ресурс в области справа будет показан его json

json-представление ресурса типа "encounter"

(Т.н. "summary display", вынесенный в отдельную вкладку и отображающий ключевые данные на скриншоте не показан.)

В области слева находится список всех ресурсов типа "condition", связанных с данным пациентом (ресурс condition описывает заболевания и проблемы со здоровьем). Ресурсы condition существуют в привязке к конкретным обращениям за медицинской помощью (т.е. к ресурсам encounter). Ссылка определяется в поле "Encounter.indication". Выбор любого из ресурсов condition произведет фильтрацию результатов, показанных на временной шкале: график отобразит только те обращения (encounters), которые связаны с выбранным заболеванием (condition).
Что бы еще хотелось добавить, чтобы сделать визуализацию еще лучше:

• К сожалению пока не удалось отобразить возможные расширения ресурсов (как на графе, так и во взаимосвязях);
• Лишь для немногих ресурсов доступен детализированный просмотр;
• При быстром переключении между ресурсами, отображенными на графе, приложение может немного "подвисать";
• Применена базовая цветовая схема; (Кто-то из коллег назвал эту рождественскую схему "новогодней" =) ) Поэтому, пожалуйста, посоветуйте что-нибудь "по дизайну"!

FHIR в стиле REST.

Перевод оригинальной статьи от 15 октября 2013 года с дополнениями.

REST - это концепция

Сегодня мы поговорим о концепции REST и ее реализации в контексте стандарта FHIR. Аббревиатура REST расшифровывается как «передача состояния представления» («REpresentational State Transfer») и подразумевает под собой архитектурный подход (или стиль) в построении распределенного программного обеспечения. Суть REST заключается в манипулировании т.н. ресурсами (resource), т.е. в их создании, изменении и обмене по правилам протокола http. О веб-сервисах, системах и приложениях, реализующих данные принципы, говорят как о RESTful-сервисах, т.е. соответствующих ограничениям спецификации REST. Мы лишь поверхностно коснемся реализации REST-принципов в стандарте FHIR, поэтому, за более полной информацией лучше обратиться к спецификации REST.

Стандарт FHIR хорошо "ложится" на любую из парадигм обмена данными, которые он называет "interoperability paradigms". К возможным "парадигмам" относятся (1) обмен документами, (2) обмен сообщениями, (3) REST-обмен и (4) развертывание веб-сервисов, однако, наиболее просто и удобно стандарт FHIR реализуется именно "поверх" REST. Несмотря на большой энтузиазм вокруг REST и большую популярность данного архитектурного подхода, он лишь является набором простых рекомендаций, изложенных в спецификации. По факту, сегодня почти весь веб работает в соответствии с принципами, изложенными в спецификации REST.

REST и HTTP

REST-взаимодействия основываются на правилах, определенных протоколом HTTP. Любое взаимодействие происходит по схеме "запрос-ответ": в запросе указываются запрашиваемые данные или описывается транзакция, подлежащая выполнению на сервере, в ответе возвращаются данные или статус выполнения транзакции. Существует прямое соответствие между CRUD-операциями, определенными протоколом HTTP, и их реализацией в RESTful-интерфейсах. Также подразумевается, что взаимодействие в RESTful-интерфейсах происходит в строгом соответствии с "семантикой" определенных протоколом методов. Т.е. например, метод get должен использоваться только для получения данных, но никогда для вызова выполнения транзакций (создания новых ресурсов или внесения изменения в существующие), хотя технически это и возможно, ввиду ошибок, часто допускаемых при проектировании и разработке веб-интерфейсов.

Идентификация ресурсов

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

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

По отношению к URI рекомендуют следующее: (1) не указывайте формат хранения ресурсов (json, xml) в URI, чтобы не "замыкать" ресурсы на один формат, (2) используйте только строчные буквы. (3) Любые пробелы в URI ресурса должны быть заменены на тире или нижние подчеркивания. (4) Насколько возможно, лучше не пользоваться строчными запросами (query strings).

Взаимодействия не зависят от контекста (statelessness)

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

Действенные методы FHIR

Для манипулирования ресурсами доступен ограниченный набор операций (методов), заимствованных из http. Разберем наиболее интересные:

GET. Используется для получения ресурса, идентификация которого происходит по URI. URI ресурса составляется из физического адреса сервера и идентификатора (ID) ресурса. Метод GET может использоваться как для получения одного ресурса, так и для выполнения поисковых запросов, результатом которых могут быть группы ресурсов.

Метод POST позволяет создавать новые ресурсы на указанном сервере. Сервер, на котором будет размещен создаваемый ресурс, самостоятельно присвоит ему уникальный идентификатор. Физический адрес сервера и уникальный (в масштабе данного сервера) идентификатор будут использоваться в качестве URI данного ресурса.

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

Для выполнения метода DELETE клиентская сторона также должна знать URI удаляемого ресурса. Рекомендуется, хотя, это и не является строгим требованием, сохранять ресурс на сервере при выполнении операции DELETE (это вопрос практической реализации стандарта). После удаления ресурс может быть доступен при выполнении операции vread (т.е. при запросе конкретной версии ресурса), однако, метод GET уже не должен возвращать данный ресурс. (Будет возвращен код состояния, сообщающий об удалении ресурса.)

Метод OPTIONS - особый метод в стандарте FHIR, который обращается к корневому каталогу FHIR-сервера и возвращает conformance-ресурс. Данный ресурс содержит информацию о поддерживаемой функциональности сервера.

Ответ на rest-запрос формируется сервером в соответствии с указанным в запросе методом и внутренней логикой сервера. Ответ составляется из нескольких частей. Тело ответа (body) содержит запрашиваемые клиентской стороной данные. Чаще всего данные возвращаются клиенту в ответ на GET-запрос. Сервер всегда возвращает т.н. код состояния (status code), который сообщает клиенту о результате обработки запроса. Код состояния - это число (например, "404"), имеющее определенный смысл в протоколе HTTP. Стандарт FHIR
также предусматривает использование ресурса "operationOutcome", с помощью которого сервер может сообщать клиентской стороне о возможных причинах неудач при их взаимодействии. Как в запрос, так и в ответ могут включаться заголовки (headers), в которых
содержится дополнительная информация для корректной обработки транзакций.

В заголовке может указываться, например, следующая информация:
• В поле Content-type указывается формат cодержимого (XML или JSON).
• В поле Accept клиент сообщает серверу предпочтительный формат (XML или JSON) ответа на GET-запрос. (Сервер, тем не менее, не обязан удовлетворить данное требование клиента.)
• В поле Location сервер сообщит клиенту URI вновь создаваемого ресурса.

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

http://fhir.healthintersections.com.au/open/Patient/100

В итоге будет выполнен GET-запрос к вышеуказанному серверу и браузер отобразит содержимое ресурса в XML-формате.

Разберем URI "по кусочкам":
• "http://" - для обмена данными будет использован протокол http
• hl7connect.healthintersections.com.au/svc/fhir/ – конечная точка, куда следует отправлять fhir-запросы.
• "Patient/" - выполняемая операция будет совершаться над ресурсом типа "patient".
• "100" - указан идентификатор пациента.

Однако, отметим следующее: Единственный тип запросов, которые могут выполняться напрямую из браузера вышеописанным методом - это get-запросы.