вторник, 7 марта 2017 г.

Разворачиваем собственный FHIR-сервер

Перевод оригинальной статьи блога "Hay on FHIR" от 19 октября 2016

Мне неоднократно приходилось беседовать с одной командой, которая очень хотела бы использовать clinFHIR "полноценно", т.е. для создания и редактирования профилей ресурсов (и создания "шаблонизированных" вариантов ресурсы на базе таких профилей). Для этих нужд парни уже давно используют Forge, и, если честно, лучше, чем Forge пока ничего нет, но, тогда зададимся другим вопросом: "куда загрузить (созданные нами в Forge) профили, чтобы они были доступны для clinFHIR?".


среда, 1 марта 2017 г.

Логические модели в стандарте FHIR

Перевод оригинальной статьи Дэвида Хэя от 17 октября 2016 года.

В этом статье обсудим новую функцию ClinFHIR: теперь серверная инфраструктура, отвечающая за "соответствие стандарту" (conformance-ресурсы, наборы значений (ValueSets), StructureDefinition и "иже с ними"), может использоваться для генерации логических моделей. Тем не менее не будем забывать, что основное назначение такой инфраструктуры - описание типов поддерживаемых сервером fhir-ресурсов и т.д.
В чем цель использования логических моделей? В первую очередь это сбор требований от клиницистов и других работников здравоохранения, которые таким образом могут принимать участие в процессе создания профилей и руководств по реализации (IG). Хотя профили можно описывать "руками" и, кстати, это одна из базовых функций ClinFHIR, для определения профилей вручную может потребоваться далеко не элементарное понимание FHIR, структуры и назначения существующих типов ресурсов. В то же время, использование логического моделирования позволяет описывать клинические требования не касаясь дополнительных ограничений структуры модели.

вторник, 1 ноября 2016 г.

FHIR/XDS: обновление документа

Перевод оригинальной статьи Дэвида Хея от 20 ноября 2013 года.

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

Получение документов из FHIR/XDS-инфраструктуры

Перевод оригинальной статьи Дэвида Хея от 19 ноября 2013 года.

Мы коротко обсудили, как ресурсы fhir могут полноценно использоваться в инфраструктуре обмена ЭПМЗ, изучили возможности document creator может создавать и загружать ЭПМЗ в репозиторий и / или обновлять реестр документов, коснулись использования ресурса DocumentReference. Теперь уделим внимание действующему лицу "пользователь сервиса" (service consumer).
Нас интересуют два кейса (которые должен решать FHIR/XDS-хранилище):

  • Получение списка документов для конкретного пациента (используя различные параметры поиска - в диапазоне дат, по типам документов и т.д.) и представление пользователю метаданных о документах в виде списка.
  • Выгрузка конкретного документа для просмотра.

FHIR и XDS: отправка документа в репозиторий

Перевод оригинальной статьи Дэвида Хэя от 6 ноября 2013 года.

В данном посте мы уделим основное внимание такому действующему лицу как XDS Document Source ("источник документа"), механизму загрузки документа в репозиторий и регистрации его метаданных в XDS-инфраструктуре хранения ЭПМЗ. Рассмотрим некоторые аспекты реализации интеграционного профиля XDS в привязке к REST-архитектуре.
Метаданные о документе будем хранить в ресурсе DocumentReference; основную сложность для нас составит управление "идентификаторами сущностей" (enitity identifiers), т.е. идентификаторами пациентов, врачей и медорганизаций, как предписывает профиль XDS. В стандарте FHIR акцент смещен на идентификаторы ресурсов, которые используются для представления сущностей. Идентификаторы fhir-ресурсов используются для установления взаимосвязей между ресурсами.


понедельник, 31 октября 2016 г.

FHIR и XDS: краткий обзор

Первая из цикла статей о FHIR и XDS, опубликованных в блоге Дэвида Хэя.

Стандарт FHIR со своей REST-архитектурой успешно может использоваться в реализациях профиля обмена документами IHE XDS (Cross Enterprise Document Sharing). Организация IHE разработала интеграционный профиль MHD (мобильный доступ к документам о здоровье) (кстати, также как и FHIR реализующий архитектурные принципы REST), чтобы упростить доступ к XDS-инфраструктуре для мобильных устройств. С появлением FHIR, IHE и HL7 уже могли объединить свои усилия и начать разработку второй версии профиля MHD, полностью базирующегося на стандарте FHIR. Стандарт FHIR не отменяет XDS - в некоторых ситуациях необходимо развертывание именно XDS-инфраструктуры - особенно, если речь идет о крупных развертываниях сети обмена медицинской информацией; однако, простота реализации и использования FHIR побуждает многих интеграторов использовать именно его в качестве интерфейса взаимодействия.


четверг, 1 сентября 2016 г.

Проекты (projects) в clinFHIR

Этот пост - перевод оригинальной статьи из блога "Hay on FHIR" Дэвида Хэя от 23 августа 2016 года. Оригинал можно почитать здесь.

Resource Builder может одновременно взаимодействовать с целым рядом серверов в соответствии с набором предопределенных для них ролей. Перечислим роли серверов:

  • Conformance-сервер хранит ресурсы StructureDefinition и NamingSystem;
  • Терминологический сервер (terminology server) хранит ресурсы ValueSet (наборы значений), позволяет модулям в составе ClinFHIR работать со справочниками и терминологиями;
  • Data-сервер - на этом сервере хранятся данные о пациенте;
Описанные выше роли не определяются в спецификации стандарта FHIR; это лишь одно из возможных (и предложенных нами) архитектурных решений для приложений, построенных на базе FHIR.

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

Чтобы делать "правильный выбор" было проще, мне пришло в голову добавить в ClinFHIR "проекты" (projects). Целью проекта является выбор "комбинации серверов, профилей, тестовых пациентов" из списка предопределенных комбинаций, а также обмен такими комбинациями с другими пользователями!

Почему мне пришло в голову добавить такой функционал? Во всем "виноваты" мои коллеги из Британии, которые собираются использовать ClinFHIR для визуализации профилей, создаваемых в Forge и хранящихся в репозитории simplifier. Создание проектов (projects), в которые можно обернуть профили, информацию о серверах (с указанием адреса), данные "тестовых пациентов" поможет моим британским коллегам в поисках наиболее подходящих таких комбинаций и профилей.

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

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

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

После нажатия на ссылку "project editor" откроется окно для создания новых проектов, их редактирования или удаления (кстати, если будете создавать тестовый проект "для себя" - удалите "за собой", когда он уже будет не нужен). По нажатию на ссылке "new" откроются поля для ввода информации о проекте:

  • Имя проекта (будет отображаться в меню, поэтому, лучше если оно будет коротким);
  • Описание проекта (будет отображаться при наведении курсора мыши на пункт в меню - вставьте сюда лаконичное описание вашего проекта).

Обратите внимание на то, что серверы будут выбраны автоматически (не совсем правда: на самом деле серверы уже были выбраны вами заранее до создания проекта).

Когда все поля будут заполнены, нажмите кнопку Save (активируется только после того, как вы заполните поля "name" и "description"). Затем можно вернуться на "главную", нажав на ссылку "front page". После перезагрузки главной страницы приложения Ваш проект будет отображаться в списке проектов. (Не забудем выбрать проект из списка в меню, т.к. просто создать его недостаточно).
Текущие проекты также можно просмотреть в project editor: в нем будут отображаться добавленные в него профили и пациенты (минутку, сейчас покажу, как это сделать).

Для того, чтобы перейти к использованию проекта, выберите его из списка. Что затем произойдет на главной странице:

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

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

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

Мне также потребовалось внести несколько изменений в ClinFHIR, чтобы обеспечить поддержку проектов:

  • Теперь пациенты и профили можно удалять из проекта нажатием на "крестик" ("х") справа от имени пациента или профиля
  • Теперь можно выбирать и пользоваться профилями, размещенными не только на заранее заданном confromance-сервере, но и на любом другом сервере. Для этого достаточно выбрать сервер и id профиля, который хранится на этом сервере. Такая возможность была добавлена для того, чтобы использовать ранее выбранный conformance-сервер (например, сервер Грэма или сервер HAPI, на котором лежат все стандартные профили наборы значений, без которых, ну, просто не обойтись), но также позволить пользователю выбирать профили, например, лежащие в репозитории simplifier (очень популярно в Великобритании).

Надеюсь, что проекты ClinFHIR упростят обмен готовыми наборами артефактов для специфических кейсов. Жду комментариев и ваших отзывов!

Еще раз напомню - все проекты открыты для просмотра и редактирования! Пока проектов мало, я думаю, управлять ими достаточно несложно. Как только их количество возрастет, я займусь работой над дополнительными функциями: наверное, было бы неплохо, если бы пользователи могли "подписываться" (subscribe) на определенные проекты, а не иметь доступ сразу ко всем. Ну а пока что, пусть все будет так как есть!