FHIR Release 3 (STU)

Переводит компания Health Samurai . Приглашаем поучаствовать в русификации стандарта FHIR: GitHub , Email.

Work Group FHIR Infrastructure Ballot Status: Informative

Модуль рабочего процесса направлен на координацию деятельности внутри и между системами. Сюда входят три основных аспекта:

  • Как мы просим другого человека, устройство или систему что-то сделать?
  • Как мы отслеживаем связи и зависимости между активностями - действиями и их разрешением, сложной активностью и отдельными шагами, протоколами планов и заказами и т.д.?
  • Как мы задаём, какие активности возможны и ожидаемый порядок и зависимости шагов в рамках этих активностей? Т.е. определение процессов и их координации
Инфраструктура
Расписание
Клинический процесс

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

В дополнение к ресурсу Task, данная спецификация определяет три логические модели - Definition, Request и Event с образцами ресурсов, которые обычно используются в рабочем процессе. Эти образцы включают элементы, определяющие общие атрибуты каждого типа ресурса, а также взаимосвязи между ними. Эти взаимосвязи перечислены на странице workflow, наряду с полным списком ресурсов, которые соответствуют (ну или надеемся, что соответствуют) моделям "запрос" и "событие".

Ресурсы PlanDefinition и ActivityDefinition комбинируют для создания протоколов, наборов заказов, руководств и других определений рабочих процессов путём описания активностей, которые могут происходить, и установки правил их сочетания, последовательности, взаимозависимости и выполнения.

Рабочие процессы обнаруживаются во многих местах среды здравоохранения:

  • Создание заказа на лабораторное исследование, рецепта на лекарство, направления или другого медицинского заказа, требования о страховом возмещении, enrollment request, записи на приём или других подобных административных запросов и запрос на его выполнение определённой организацией или медицинским специалистом
  • Обсуждение процесса исполнения, например запрос более подробной информации перед принятием требования о страховом возмещении, выдачей направления или предложением альтернативного лечения при выполнении заказа
  • Уведомление заказавшего врача о текущем прогрессе исполнения заказа (например проба крови взята, образец для анализа обрабатывается, получены предварительные результаты и т.п.)
  • Создание плана по уходу или рекомендаций, включающих ряд медицинских и/или административных мероприятий по уходу за пациентом и дальнейшее отслеживание их выполнения (или невыполнения).
  • Сообщение изменения состояния запроса или заказа (например приостановка, обновление, отмена и т.д.) исполняющей системе, чтобы она могла принять необходимые действия
  • Осведомление об изменении статуса, запрос на слияние пары записей пациента или вызов какой-то операции или решения, работающего асинхронным способом - к примеру такое, где требуется вмешательство человека
  • Проектирование или следование протоколу исследования, протоколу химиотерапии, создание набора заказов или другого плана

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

Ресурсы, связанные с рабочим процессом, должны следовать тем же security and privacy guidelines, которые применяются ко всем FHIR-ресурсам, включая специфичные соображения для тех, что могут содержать информацию, по которой можно опознать человека. Есть пара дополнительных соображений по поводу безопасности и конфиденциальности, специфичных для рабочего процесса:

1. Некоторые рабочие процессы являются узкоспециализированными без предварительно определённых участников или процессов. Это может вызвать трудности в соблюдении конфиденциальности и безопасности

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

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

Более общее обсуждение см. в модуле Безопасность и конфиденциальность.

Начальная работа состояла в основном в приведении (пока ещё не всех) ресурсов к моделям Definition, Request и Event. При подготовке к R4 мы рассчитываем привести к этим моделям все оставшиеся ресурсы, пересмотреть и, возможно, выверить уже приведённые ресурсы (где это будет полезно для реализаторов) и рассмотреть возможность оформить приведение к моделям вычислительным способом (например как интерфейсы). Мы рассмотрим возможность совмещения ресурсов ProcessRequest и ProcessResponse

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

Мы продолжим развивать ресурсы PlanDefinition and ActivityDefinition на основе отзывов от сообщества реализаторов. Мы проанализируем их применение разными способами, включая медицинские наборы заказов, протоколы лекарственных средств, протоколы рабочих процессов, траектории рабочего процесса, административные протоколы и т.д.

Дополнительные темы для будущей работы:

  • Начальные усилия по приведению ресурсов к моделям рабочего процесса были чрезмерно усердными для некоторых из них, что вылилось в потерю контекста предметной области и, порой, к внедрению элементов, которые по-хорошему следовало бы сделать расширениями. В R4 мы постараемся привести эту работу к балансу, гарантирующему, что стремление соответствовать моделям не затмит важные требования к интуитивности и простоте реализации
  • Разрешить проблему частичного совпадения ресурсов SupplyRequest, DeviceRequest и VisionPrescription
  • Модель описания медицинского специалиста Practitioner плюс "onBehalfOf" организации (Organization) и, возможно, их роль сделаны не лучшим образом. Мы проанализируем возможность добавить вместо этого ресурс PractitionerRole в качестве альтернативы для упрощения моделей
  • Улучшить мэппинг и приведение элементов и статус-кодов ресурса Task в соответствие со спецификацией WS-HumanTask
  • Создать руководство с установившимися практиками реализации рабочего процесса для различных бизнес-моделей
  • Проверить, как рабочий процесс используется для "компенсирующих действий", например бухгалтерских транзакций и кассаций (reversals)