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

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

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



Именно потому, что логические модели имеют машинное представление, процесс создания профилей в формализованной форме становится намного проще. Кроме того, возможна разработка и использование инструментов для создания моделей (каждая из которых может быть использоваться для генерирования одного или более профилей). Один из таких инструментов - clinFHIR Logical Modeler - мы и рассмотрим. Еще одно замечание: логическое моделирование упрощает создание примеров, которые не только позволяют глубже понять особенности конкретного клинического домена, но и протестировать адекватность самой модели.
Цепочка последовательных шагов от ["формулирования"] клинического требования до создания руководства по реализации:

1. Построение логической модели. На данном этапе необходимо обеспечить близкое взаимодействие с сообществом медицинских работников и "представителями медицинского бизнеса" (если речь идет о "коммерческой" модели здравоохранения): может потребоваться многократное обсуждение модели, ее уточнение и некоторое понимание стандарта FHIR (например, не удастся обойтись без понимания типов данных). Итогом этапа станет создание логической модели и наборов значений (справочников), которые могут потребоваться на этапе эксплуатации системы (в крайнем случае такие наборы значений могут быть просто "обозначены" для дальнейшей разработки).
2. Подготовка Руководства по реализации и других fhir-артефактов, их объединение с артефактами, созданными на первом этапе. На данном этапе потребуется более глубокое понимание стандарта FHIR, но все еще на уровне "бизнес-процессов", а не на чисто техническом. Выполнение такого рода деятельности находится в компетенции бизнес-аналитика или "мотивированных" медицинских работников (в том смысле, что такая работа выходит за рамки непосредственно деятельности по лечению).

Для чего можно использовать clinFHIR Logical Modeler уже сейчас:

(На октябрь 2016 года описанные функции будут доступны только при работе с сервером Грэма (Grahames STU-3 server), поэтому, при выборе данного сервера в качестве comformance-сервера, в главном меню (открывающимся по нажатию на "шестеренку") появится ссылка на Logical Modeler.)

Итак, когда Modeler загрузится, найдет существующие модели на сервере и сформирует список моделей. При выборе одной из моделей главный экран приложения приобретет следующий вид:

На экране представлен архетип openEHR Кровяное давление, приведенный к структуре логической модели.

Logical Modeler имеет три панели:

1. Слева расположен "селектор моделей" ("model selector"). На скриншоте в области слева показаны все модели, доступные на сервере.
2. В середине поместилась панель редактирования ("editing panel").
3. Справа - "панель параметров" с детальной информацией о модели (details panel), т.е. описание выбранной модели и текущего элемента модели.

Большинство операций совершается пользователем именно в области редактирования, в которой размещаются 5 вкладок:

1. Конструктор ("Designer") - отображает иерархическое (или "древовидное", т.е. "tree-view") представление модели. При выборе элемента [в области слева], правая панель отобразит "подробную информацию" о нем. При необходимости узлы дерева можно разворачивать и сворачивать для удобства просмотра.
2. Mind Map (технически, это граф, но клиницисты лучше знакомы именно с Mind Map'ами, а не графами) позволяет представить компоненты модели в иерархическом виде. Так же как и в режиме "Конструктора", можно выбрать узел и просмотреть подробную информацию о нем панели параметров (details panel). Узлы дерева можно перетаскивать, а сам граф можно перемещать и масштабировать.
3. В таблице подряд перечислены все элементы модели. Табличное представление все также похоже на конструктор, но более компактно. Аналогично, можно выбирать элемент для просмотра его параметров (details).
4. Вкладка JSON отображает ресурс "StructureDefinition" (В ресурсах данного типа хранится подробная информация о модели.) Данная вкладка полезна, если нужно просмотреть fhir-представление модели (она понадобится, если вас глубоко интересует техническая сторона).
5. И наконец, TreeData - любимая вкладка разработчика Logical Modeler, которая, возможно, со временем исчезнет.

Вот так выглядит MindMap:

А вот так - таблица:


Как сказано выше, панель параметров (Details Tab - левая область интерфейса clinFHIR Logical Modeler ) делится на 2 подобласти. Верхняя подобласть содержит информацию о модели в целом и также разделена на две вкладки:

1. Summary (Сводка) - позволяет работать с параметрами модели. Можно изменить параметры модели, кликнув на вкладку "Edit" (Редактировать) сверху справа (На скриншоте видно, что в области справа модель описана не очень подробно - это скорее всего изменится с течением времени).
2. Вкладка History показывает предыдущие версии модели и дату их создания. Выбрав одну из версий, в области редактировании (editing pane) пользователь увидит параметры выбранной модели. Параметры модели можно просматривать, но нельзя редактировать. Выше области редактирования (editing pane) отображается уведомление о том, что пользователь работает с архивной версией модели. Также у пользователя есть два варианта:
   
   • Вернуться к текущей версии модели ("Back to Current"), т.е. загрузить модель, с которой он работал до просмотра архивной версии (возобновляется возможность редактирования модели).
   • Откатить до текущей архивной версии, т.е. сделать просматриваемую архивную версию текущей. Это нужно, если на каком-то этапе работы с моделью вы "пошли не тем путем".

Ниже панели параметров пользователю доступны параметры выбранного элемента модели. Эта панель также делится на две подобласти:

1. Значение основных элементов (описание, комментарии, типы данных и т.д.)
2. "Ссылки-действия", определяющие возможные действия с данным элементом. Приведем пример:
   
   • "Стрелка вверх" (Up arrow). Перемещение выбранного элемента и его потомков выше по иерархии (если он не находится на вершине иерархии).
   • "Стрелка вниз" (Down arrow). Перемещение выбранного элемента и его потомков вниз по иерархии (если он уже не находится "на дне"). Еще некоторые проблемы с работой этих функций, т.к. их оказалось удивительно сложно реализовать.
   • "Редактировать элемент" (Edit Element). Отображает окно редактирования для данного элемента и позволяет вносить в него изменения.
   • "Добавить элемент" (Add Element). Позволяет добавить дочерний элемент к текущему. Использует окно редактирования элемента для работы с параметрами.
   • "Удалить элемент" (Remove element). Удаляет текущий элемент и его дочерние элементы.

"Ссылки-действия" (Action links) работают для различных режимов просмотра ("Конструктор", "MindMap", "Таблица"). Отображены будут актуальные данные вне зависимости от выбранного режима просмотра. (Данные при любом режиме просмотра будут обновляться в реальном времени, т.е. в процессе внесения изменений в модель.)
Обратим внимание на следующие два скриншота: Кнопка в форме 'глазка' справа от выпадающего списка типов данных (Datatype) работает как ссылка на части спецификации с описанием выбранных типов данных. Если в модель были внесены изменения, в панели "Конструктор" (Designer) появится кнопка "Сохранить" (Save). Щелчок по этой кнопке сохранит модель и вы сможете продолжить ее редактирование. На любом этапе возможно вернуться к предыдущей версии модели: не бойтесь делать что-либо с мыслью "а что если...", так как вернуться к ранней версии не составит труда. Если при сохранении модели возникнут проблемы, в области редактирования появится вкладка "Ошибки" (Error tab). Она будет полезна для продвинутых пользователей в процессе исправления ошибок. Совет бывалых: "сохраняйтесь" как можно чаще в процессе работы.
Для создания новой модели нажмите на ссылку "New Model" (Новая модель). Появится следующее окно:
Введите имя модели - желательно "в одно не слишком длинное слово" - и нажмите кнопку "Проверить" (Check). ClinFHIR проверит, существует ли модель с таким же именем. Если такая модель есть, пользователь будет предупрежден; если нет, активируется кнопка "Save" и пользователь сможет заполнить поля формы.
Многое еще нужно доделать, прежде чем ClinFHIR станет по-настоящему полезным инструментом:

• Пользовательский интерфейс нуждается в доработке: какие элементы окажутся действительно полезными будет понятно только в процессе реального использования программы. Например, было бы неплохо скрывать селектор моделей (model selector), чтобы высвободить место для вкладок редактора. (Очень бы хотелось, чтобы над интерфейсом поработал настоящий UX-специалист.)
• Каждому элементу соответствует только один тип данных; необходимо сделать так, чтобы одному элементу можно было сопоставлять несколько типов. Также хотелось бы иметь возможность описывать единицы изменения кол-ва (units) или указывать систему кодирования для идентификаторов сущностей.
• Было бы неплохо, если одни модели могли ссылаться на другие модели. Например, можно было бы определять шаблонные модели (common models) для многократного использования (например, пользовательскую модель пациента или поставщика медуслуг).

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

Генерирование Руководства по реализации (IG) из модели. Это может быть слишком сложно и мы понимаем, что вряд ли когда-нибудь полностью автоматизируем эту функцию. Тем не менее, мы очень хотим попытаться упростить выполнение данной задачи. Например, в модели может быть определен артефакт, описывающий функционал (conformance-артефакты), косвенно связанный моделью и указан путь к такому артефакту. Затем мы будем использовать личную разработку Грэма - генератор руководств по реализации (включая профили и определения расширений ресурсов).

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

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

В общем, работа над приложением продолжается!