Workflow-менеджмент

1. 12.8.1 Вариант F: Создание Задачи в системе россыпи
2. 12.8.2 Вариант G: POST Задачи для системы исполнителя
3. 12.8.3 Вариант H: POST of Task для посредника рабочих процессов
4. 12.8.3.1 Шаги
5. 12.8.3.5 Примеры использования
6. 12.8.5 Вариант J: Задача обмена сообщениями от россыпи к исполнителю
7. 12.8.5.1 Шаги
8. 12.8.5.5 Примеры использования
9. 12.8.6.1 Шаги
10. 12.8.6.5 Примеры использования
11. 12.8.7.1 POST ресурса "request" для системы-заполнителя, ответ через Task

Это текущая официально выпущенная версия FHIR, которая R4 (V4.0.0). Полный список всех версий см. В Каталог опубликованных версий ,

TODO: Обсуждение (или ссылка на него) на опрос и подписку

12.8.1 Вариант F: Создание Задачи в системе россыпи

12.8.1.1 Шаги

1. Placer создает запрос в своей собственной системе через POST, внутреннее действие или отправляет его в систему сервера очередей.
2. Placer создает ресурс Task в своей собственной системе через POST, внутреннее действие или передает его в систему сервера очередей, указывая на ресурс запроса и ища выполнение.
   Задание может иметь определенного исполнителя, и в этом случае ожидается, что этот исполнитель выполнит шаг 3.
   Если Задача не имеет указанного «исполнителя» (хотя может иметь тип исполнителя), то это случай «открытой» задачи, когда любое количество исполнителей может попытаться «потребовать» задачу. Кто добьется успеха, определяется местными политиками и процедурами.
3. Система Fulfiller использует опрос или pub / sub, чтобы узнать о существовании задачи.
   1. Распространенным случаем может быть передача идентификатора задачи исполнителю другими способами. Например, заказывается лабораторный тест, и пациент берет заявку в лабораторию по своему выбору. Заявка содержит идентификатор задачи (в виде штрих-кода или хранится в смарт-карте пациента), и лабораторная система может выполнить прямое GET для задачи, что устраняет необходимость подписки или опроса.
4. Система Fulfiller запрашивает, чтобы получить указанный запрос, и обновляет Задачу, чтобы указать «принятие» и согласие на выполнение.
5. Fulfiller может обновить задачу, чтобы указать промежуточные промежуточные заметки
6. Placer информируется о принятии Задачи и любых изменениях в Задаче либо через владение ресурсом, либо с помощью опроса или подписки на систему сервера очередей для определения того же
7. Fulfiller создает ресурс событий в своей собственной системе через POST или внутреннее действие или отправляет его в систему сервера очередей.
8. Fulfiller PUT обновляет ресурс Задачи, чтобы изменить его статус на завершенный и указать на ресурс события
9. Placer знает о завершении Задачи либо через владение ресурсом, либо через опрос или подписку на систему сервера очередей, и извлекает указанный ресурс события
10. Placer обновляет ресурс запроса, чтобы указать завершение через PUT или внутреннее действие, или PUT передает обновление в систему сервера очередей

12.8.1.2 Преимущества

• Использует FHIR REST API для управления рабочим процессом
• И россыпь, и исполнитель могут отслеживать состояние рабочего процесса.
• Может использовать этот подход для запроса, отличного от простого выполнения (например, для запроса изменения статуса или других обновлений)
• Есть возможность договориться о выполнении - то есть способность сказать «нет»
• Явное подтверждение того, что заполнитель получил и согласился действовать по запросу
• Поддерживает отмену через способность россыпи изменять статус Задания на отмененный.

12.8.1.3 Ограничения

12.8.1.4 Рекомендации по использованию

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

12.8.1.5 Примеры использования

Лабораторный заказ известному исполнителю

Поставщик назначает пациенту тест на билирубин, который должен быть проведен в лаборатории поставщика.

«Открытый» лабораторный заказ

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

12.8.2 Вариант G: POST Задачи для системы исполнителя

12.8.2.1 Шаги

1. Placer создает запрос в своей собственной системе через POST или внутреннее действие или отправляет его в систему сервера очередей.
2. Placer отправляет ресурс Task в систему-заполнитель, указывая на ресурс запроса и ожидая выполнения
3. Система Fulfiller ПОЛУЧАЕТ ссылочный запрос
4. Fulfiller обновляет задание, чтобы указать принятие задания
5. Placer либо опрашивает задачу, чтобы отметить принятие, либо использует подписку для определения того же
6. Fulfiller может дополнительно обновить задачу, чтобы отразить достигнутый прогресс. Используя тот же метод, что и на шаге 5, россыпь узнает об этих обновлениях
7. Fulfiller создает ресурс событий в своей собственной системе через POST или внутреннее действие или передает его в систему сервера очередей.
8. Fulfiller Обновляет ресурс задачи, чтобы изменить его статус на завершенный и указать на ресурс события
9. Placer либо опрашивает задачу, чтобы отметить завершение и изменения, либо использует подписку для определения того же
10. Запрашивающая система запрашивает ресурс упомянутого события
11. Placer обновляет ресурс запроса, чтобы указать завершение через PUT или внутреннее действие, или PUT передает обновление в систему сервера очередей

12.8.2.2 Преимущества

• Использует FHIR REST API для управления рабочим процессом
• Подписка / опрос ориентированы на конкретный экземпляр ресурса - намного проще, чем общая инфраструктура подписки / опроса
• И россыпь, и исполнитель могут отслеживать состояние рабочего процесса.
• Может использовать этот подход для запроса, отличного от простого запроса на выполнение (например, для запроса изменения статуса или других обновлений)
• Есть возможность договориться о выполнении - то есть способность сказать «нет»
• Явное подтверждение того, что заполнитель получил и согласился действовать по запросу
• Placer может попытаться отменить задачу в случае отмены заказа, но без гарантии
• Заполнитель имеет контроль над тем, можно ли отменить задачу

12.8.2.3 Ограничения

• Дополнительная сложность использования Task
• Дополнительная сложность использования подписки или опроса
• Заполнитель и исполнитель должны иметь сервер FHIR, а сервер FHIR исполнителя должен разрешать «запись» создания ресурса «Задача» средством размещения
• Заполнитель и наполнитель, возможно, должны быть в состоянии общаться напрямую (т.е. знать соответствующие конечные точки друг друга)
  • Это может стать неуправляемым, если существует большое (или динамическое) количество россыпей и наполнителей, которые должны взаимодействовать
  • Может не применяться, если есть сервер очередей
• Placer может не знать сразу, когда система-заполнитель получит запрос

12.8.2.4 Рекомендации по использованию

• Когда важно следить за состоянием рабочего процесса
  • Когда необходимо знать, что исполнитель согласился выполнить запрос
  • Когда необходимо изменить статус рабочего процесса либо россыпью, либо исполнителем
  • Когда есть несколько шагов в выполнении запроса
• Когда исполнителю необходимо управлять ресурсом Задачи

12.8.2.5. Примеры использования

Амбулаторный рецепт

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

12.8.3 Вариант H: POST of Task для посредника рабочих процессов

ТОДО: Еще нужно пересмотреть и обновить

12.8.3.1 Шаги

1. Placer отправляет запрос в свою собственную систему или в систему сервера очередей
2. Брокер обнаруживает, что новый неназначенный запрос (без созданной Задачи и попадает в сферу Брокера для обеспечения выполнения) посредством опроса или подписки
3. Посредник размещает ресурс задачи в своей собственной системе или в системе сервера очередей, указывая на ресурс запроса и ожидая выполнения от определенного заполнителя.
   Задача не имеет указанного «исполнителя» (но может иметь тип исполнителя)
4. Если Задача отклонена одним потенциальным получателем, брокер может создать новую задачу, чтобы добиваться выполнения от других.
5. Продолжайте согласно Вариант G

12.8.3.2 Преимущества

• Снимает ответственность за поиск выполнения из системы россыпей, но более активно требует выполнения, чем простое «опубликовать задачу и посмотреть, кто ее принимает». Кроме того, позволяет приоритетное назначение задач (то есть некоторые наполнители могут быть предпочтительнее, чем другие)

12.8.3.3 Ограничения

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

12.8.3.4 Рекомендации по использованию

Подходит в средах с механизмом рабочего процесса, который берет на себя ответственность за обеспечение выполнения

12.8.3.5 Примеры использования

12.8.4 Вариант I: POST задачи в систему исполнителя, а затем POST подзадачи в системе россыпи

12.8.4.1 Шаги

1. Placer создает запрос в своей системе через POST или внутреннее действие
2. Placer отправляет ресурс Task в систему-заполнитель, указывая на ресурс запроса и ожидая выполнения
3. Система Fulfiller ПОЛУЧАЕТ ссылочный запрос
4. Fulfiller обновляет задание, чтобы указать принятие задания
5. Fulfiller POSTs Задача, которая также указывает на ресурс запроса и использует Task.partOf атрибут для указания на задачу из шага 2 (указывает, что это подзадача)
6. Fulfiller может дополнительно обновить обе задачи, чтобы отразить достигнутый прогресс. Поскольку подзадача находится в системе россыпи, россыпь знает об этих обновлениях
7. Fulfiller создает ресурс событий в своей собственной системе через POST или внутреннее действие
8. Fulfiller Обновляет ресурс задачи, чтобы изменить его статус на завершенный и указать на ресурс события
9. Fulfiller обновляет ресурс подзадачи как выполненный и указывает на ресурс события. Поскольку подзадача находится в системе россыпи, россыпь знает о завершении и изменениях.
10. Запрашивающая система запрашивает ресурс упомянутого события
11. Placer обновляет ресурс запроса, чтобы указать завершение через PUT или внутреннее действие

12.8.4.2 Преимущества

• Использует FHIR REST API для управления рабочим процессом
• Нет необходимости использовать подписку или опрос
• И россыпь, и исполнитель могут отслеживать и изменять состояние рабочего процесса.
• Может использовать этот подход для запроса, отличного от простого запроса на выполнение (например, для запроса изменения статуса или других обновлений)
• Есть возможность договориться о выполнении - то есть способность сказать «нет»
• Явное подтверждение того, что заполнитель получил и согласился действовать по запросу
• Placer может инициировать отмену задачи, но заполнитель решает, можно ли отменить задачу или нет

12.8.4.3 Ограничения

• Дополнительная сложность использования Task
• Необходимо синхронизировать два состояния задач
• Заполнитель и исполнитель должны иметь сервер FHIR и предоставлять другой стороне право «записи» для создания и обновления ресурсов Задачи.
• Заполнитель и наполнитель, возможно, должны быть в состоянии общаться напрямую (т.е. знать соответствующие конечные точки друг друга)
  • Это может стать неуправляемым, если существует большое (или динамическое) количество россыпей и наполнителей, которые должны взаимодействовать
  • Может не применяться, если есть сервер очередей

12.8.4.4 Рекомендации по использованию

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

12.8.4.5. Примеры использования

Амбулаторное направление

Пациент осматривается у своего поставщика первичных медицинских услуг по поводу одышки, и поставщик решает направить ее к кардиологу. Из-за реферала система провайдера создает ресурс ServiceRequest и отправляет ресурс Task в систему практики кардиолога, запрашивая реферал. Это помещает запрос на направление в рабочий список координатора для просмотра. После принятия реферала задача обновляется как принятая, и в системе провайдера создается новая подзадача, ссылающаяся как на ServiceRequest, так и на задачу, созданную системой провайдера. Пациент получает прием у кардиолога, и подзадача обновляется этой информацией, что позволяет системе поставщика информировать поставщика об изменении.

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

12.8.5 Вариант J: Задача обмена сообщениями от россыпи к исполнителю

ТОДО: нужно больше деталей

12.8.5.1 Шаги

1. Placer отправляет сообщение заполнителю с помощью MessageHeader, где элемент «data» указывает на ресурс Task, также содержащийся в сообщении. Сообщение может содержать или не содержать какие-либо другие соответствующие ресурсы (например, фактический ресурс запроса) или код «события», говорящий «пожалуйста, выполните»
2. Система-заполнитель отправляет ответ, содержащий тот же ресурс Task, с указанием получения сообщения и, необязательно, с указанием их намерения выполнить запрос
3. Система заполнения может отправлять инкрементные сообщения в россыпь, показывающую прогресс (например, собранный образец, предварительные результаты, окончательные результаты), путем включения обновленного ресурса задачи
4. Система Placer также может отправлять сообщения исполнителю, содержащему ресурс Task, и обновлять состояние рабочего процесса, например, отменяя задачу.

12.8.5.2 Преимущества

• Уменьшено количество сообщений
• Все соответствующие данные могут быть отправлены в одном пакете
• Ответы могут быть асинхронными, а контент может маршрутизироваться
• Есть возможность договориться о выполнении - то есть способность сказать «нет»
• Могу запросить что-то, кроме просто выполнения (например, приостановить)
• Явное подтверждение того, что заполнитель получил и согласился действовать по запросу (хотя нет необходимости в проверке россыпи)

12.8.5.3 Ограничения

• Сообщения "тяжелые"
• Необходимо договориться о том, что разрешенные ответы и какие данные могут присутствовать в сообщениях запроса и ответа
• Дополнительная сложность использования Task
• Нужна инфраструктура доставки сообщений

12.8.5.4 Рекомендации по использованию

Подходит, когда можно использовать существующую инфраструктуру обмена сообщениями (например, HL7 по HTTP, v2 LTP, MLTP, веб-сервисы WSI, Direct, VISA, REST и т. Д.), И необходимость оставаться в соответствии с этой архитектурой.

12.8.5.5 Примеры использования

12.8.6 Вариант K: Запрос на обслуживание, ссылающийся на Задачу от россыпи к исполнителю

ТОДО: Этот сценарий требует работы - не очень много опыта использования сервисов FHIR для управления процессом выполнения

12.8.6.1 Шаги

1. Placer создает ресурс запроса в своей системе или на сервере очередей
2. Placer может создать ресурс Task в своей системе или на сервере очередей.
3. Placer вызывает службу в системе-наполнителе, говоря «Пожалуйста, выполните этот запрос», включая содержимое или ссылку на ресурс запроса и любые другие соответствующие данные.
4. Заполняющая система отвечает (синхронно при использовании HTTP, но может быть асинхронной при использовании SOAP или других транспортных механизмов) с подтверждением получения и, при необходимости, указанием намерения выполнить и / или результатов

12.8.6.2 Преимущества

• Нет необходимости выставлять конечные точки RESTful ни для запросов, ни для задач - действует как удаленный вызов процедуры

12.8.6.3 Ограничения

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

12.8.6.4 Рекомендации по использованию

TBD

12.8.6.5 Примеры использования

12.8.7 Дополнительные сценарии

ТОДО: нуждается в рассмотрении и обновлении. Возможно добавьте варианты использования сообщений и / или сервисов вместо опроса / подписки в вышеупомянутых сценариях

12.8.7.1 POST ресурса "request" для системы-заполнителя, ответ через Task

Это вариация Вариант Н где брокер Workflow по существу объединен с исполнителем. Это все еще позволяет россыпи использовать только POST запроса и получать информацию об изменениях других ресурсов посредством подписки или опроса.

1. Система Placer вызывает действие «create», отправляя ресурс «request» (например, ServiceRequest и т. Д.) В соответствующую конечную точку ресурса RESTful (например, [base] / MedicationRequest) в системе сервера-заполнителя, россыпи или очереди и устанавливает «тег» на ресурсе, который указывает, что запрос является «активным»
2. Filler отправляет ресурс Задачи в свою собственную систему или систему сервера очередей, указывая на ресурс запроса и указывая намерение выполнить или отказ выполнить
3. Система Placer использует опрос или pub / sub, чтобы узнать о существовании задачи и намерении ее выполнения
4. Fulfiller может обновить задачу, чтобы указать промежуточные промежуточные заметки
5. Placer либо опрашивает задачу, чтобы отметить принятие и изменения, либо использует подписку для определения того же
6. Fulfiller отправляет ресурс события в свою систему или в систему сервера очередей
7. Fulfiller Обновляет ресурс задачи, чтобы изменить его статус на завершенный и указать на ресурс события
8. Система Placer узнает об обновлении через опрос или подписку
9. Система Placer извлекает событие
10. Система Placer помечает запрос как «полный»

Похожие

Комментарии