Перевод статьи Orders in FHIR, автором которой является Дэвид Хэй, специалист по продукту в Orion Health, проявляющий большой интерес к информационным технологиям в области здравоохранения, в особенности к вопросам совместимости HL7 и нового стандарта FHIR. Дэвид Хэй активно продвигает новый стандарт и ведет блог, в котором доступным языком пишет о FHIR.

Заказы (ордера) в FHIR

Одним из направлений следующего FHIR Connectathon будет обслуживание лабораторных заказов, целью которого является проработка рабочего процесса компонентов FHIR. До сегодняшнего момента основными приоритетами команды была разработка базовых ресурсов и поддержка инфраструктуры, но поскольку теперь они уже в хорошем состоянии, одним из следующих приоритетов будет рабочий процесс. На данный момент ещё много всего обдумывается: есть выделенный проект рабочего процесса, Keith описывал его недавно, и текущий способ управления рабочим процессом, скорее всего, очень сильно поменяется — вероятно, в рамках версии 2.1, запланированной к выпуску под конец следующего года.

Меня спросили, можно ли использовать clinFHIR как клиент при применении на практике рабочего процесса в Connectathon, и мне пришлось потратить время недавно, чтобы придумать, как это сделать.

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

Существует чёткое разделение между «действием» (или действиями), которое было запрошено, и информацией про то, что нужно для того, чтобы это действие выполнить. Действие воплощают два ресурса: Order и OrderResponse.

· Order определяет, кто инициировал заказ, когда он должен быть выполнен и для кого он должен быть выполнен. Он включает в себя ссылки на конкретные ресурсы, определяющие, что именно было заказано — например MedicalOrder (для предписания), DiagnosticOrder (для лабораторных анализов) или RefferralRequest (для направлений). Единичный заказ может ссылаться на любое количество «информационных» ресурсов, и они не обязательно должны быть одного типа.

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

Взгляните на рисунок, приведенный ниже:

В желтый прямоугольник включены ресурсы, созданные на момент установки заказа. Они включают:

· собственно заказ;

· того, кто сделал этот заказ;

· пациента, для которого надо выполнить заказ;

· DiagnosticOrder с деталями того, что нужно сделать.

В процессе обработки/выполнения заказа будут созданы и другие ресурсы.

Пара ресурсов OrderResponse — первый, вероятно, подтверждает, что заказ был принят лабораторией, а второй будет создан, когда результат выполнения будет доступен. Он будет содержать ссылку на DiagnosticReport, созданный вместе с результатами.

(На диаграмме не показано, что каждый из ресурсов, за исключением OrderResponse, содержат ссылку на пациента).

Этот шаблон может быть использован в любой из доступных парадигм. Если вы используете REST, это может быть, например, так:

1. Клиент получает ссылку на пациента.

2. Он создает и сохраняет DiagnosticOrder. (Для упрощения мы предположим, что всё будет сохраняться на одном и том же сервере, хотя на практике у вас может быть один дата-сервер для EHR-ссылок в записи пациента, и другой для «рабочего процесса», где будут происходить действия). В этот момент DiagnosticOrder ничем не отличается от любых других ресурсов.

3. Он создает и сохраняет ресурс заказа (со ссылкой на DiagnosticOrder). Это приводит к запуску общего рабочего процесса.

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

1. Сервер решает, примет ли он заказ (это может происходить в ручном режиме или автоматизированно). Он создает OrderResponse, где указывает это, устанавливая соответственный OrderResponse.status.

2. Заказ идет в обработку (к примеру, у пациента берётся кровь и передаётся на анализ, в результате которого создаётся ресурс DiagnosticReport/Observation). Потенциально, возможно создание последующих OrderResponse на различных шагах выполнения, чтобы держать клиента в курсе рабочего процесса.

3. Когда результат готов, создаётся финальный OrderResponse (status которого устанавливается в значение “completed”) со ссылкой на Order и на DiagnosticReport.

Так как же клиенту узнать, что процесс завершён, или что случилось что-то важное? Ну, это опять-таки зависит от реализации: это может быть процесс постоянного опроса (не очень элегантное решение) или механизм подписки, который уведомит клиента в режиме реального времени — зависит от вас.

Исходя из вышесказанного, а как clinFHIR может тут помочь?

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

Если вы загрузите эту страницу, выберете пациента и потом перейдёте на закладку Orders, вы увидите следующее:

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

Есть 3 закладки:

· На вкладке Builder присутствует компонент конструктора ресурсов — тот же, что используется и в основном приложении clinFHIR.

· Вкладка Recourses показывает список ресурсов для выбранного пациента — опять же, такой же, как и везде в приложении.

· На вкладке Orders вы можете управлять заказами.

Вкладка Orders показывает список всех заказов по текущему пациенту и включает:

· Дату создания заказа.

· Текущий статус. Вообще говоря, это статус последнего OrderResponse для данного заказа, т. к. сам по себе заказ статуса не имеет. (Если бы имел, то любое действие, которое сохраняет OrderResponse, должно было бы также обновлять Order, а нам хотелось бы этого избежать).

  • Причина заказа. В этой колонке есть две вещи:
  1. Собственно причина. (Сейчас это значение берётся из Order.reasonCodeableConcept.text — это надо улучшить, т. к. причина может содержать ссылку на внешние ресурсы).
  2. Список ресурсов, которые связаны с этим заказом. Показываются только id ресурсов — чуть позже мы увидим, как по ним просмотреть детальную информацию.
  • Колонка when выводит значение order.when.text — опять же, это надо улучшить, чтобы время выводилось должным образом.
  • Колонка Responses показывает все ресурсы OrderResponse, которые ссылаются на этот заказ. Это вложенная таблица с датой, статусом и описанием ответа. Если в ответе присутствуют ассоциированные с заказом ресурсы (к примеру, DiagnosticReport), они также будут показаны.
  • Ссылка в последней колонке позволяет создать новый OrderResponse для заказа. В реальной жизни, конечно же, это будет сделано сервером обработки заказов, а не клиентом, но здесь он добавлен для полного охвата рабочего процесса и моделирования необходимых ресурсов (и профилей). По нажатию на ссылку будет показан следующий диалог:

Здесь можно создать новый OrderResponse и указать для него следующее:

  • Новый статус заказа.
  • Описание.
  • Связанные ресурсы. Это понадобится, когда вы захотите «выполнить» заказ. Перед тем, как это сделать, создайте «ресурс завершения» в конструкторе (возможно, DiagnosticReport со связанным Observations) и потом свяжите их тут.

(Напоминаю, что все это можно также сделать и на вкладке Builder — здесь это для упрощения процесса).

Это всё может показаться немного сложным (вообще говоря, рабочий процесс сам по себе сложный), и визуализация результата не проста. Вы, возможно, заметили, что колонка даты заказа — это кнопка. Нажатие на кнопку покажет заказ на вкладке Resources, где вы можете посмотреть все ссылки этого заказа. Вот пример: у заказа есть пара ресурсов OrderResponse, которые на него ссылаются. А также он сам ссылается на ресурсы Patient и DiagnosticOrder.

Помните, что вы можете выбрать любой ресурс на закладке References, при этом ресурс будет взят «в фокус», что даст возможность просмотреть его содержимое (как XML или JSON) и ссылки, которые в нем есть.

Чтобы создать новый заказ, вам надо будет, в первую очередь, создать и сохранить «информационный» ресурс (например DiagnosticOrder или MedicationOrder), и потом создать Order, чтобы запустить действие.

Используйте закладку Resources, чтобы создать ресурс обычным способом, и имейте в виду, что интерфейс конструктора был немного упрощен: чтобы выбрать профиль (с списке доступны базовые профили ресурсов), нажмите на ссылку «Load new profile», потом выберите базовый профиль из развернутого списка на диалоге, который появится перед вами. После этого вы можете сразу выбрать профиль или посмотреть на другие профили этого базового (имеет смысл это сделать!). Это показывает, что в FHIR все определения ресурсов на самом деле являются профилями (или ресурсом StructureDefinition, чтобы быть более точным).

Чтобы создать новый заказ вы можете либо использовать построитель или создать его на закладке Orders. Выберите эту закладку потом нажмите кнопку “new order” в левой части экрана. Введите причину заказа, приоритет и информационные ресурсы которые будут в выпадающем списке правой верхней области экрана.

(По правде говоря, интерфейс еще несколько сырой, на Connectathon он будет лучше!)

Любой из двух способов приведет к тому же результату — ресурсу Order, который ссылается на информационные ресурсы, и который будет сохранен на сервере и покажется в списке заказов.

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

Это скорее всего моя последняя публикация перед Рождеством, желаю вам всего хорошего и надеюсь, что вы хорошо отпразднуете новогодние праздники в семейном кругу и кругу друзей. Следующий год обещает быть безумным!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.