Жизненный цикл статусов заказа

Обоснование

Взаимодействие МИС и ЛИС предполагает, что заказ должен создаваться МИС, а результаты исследования - ЛИС. Крайне желательно чтобы ЛИС не могла вносить изменения в оригинальный заказ, а организация - в результаты. Идеальный случай - права только на чтение для ресурсов, созданных второй организацией. Такой подход создает проблему, что организация не может изменять статус чужих ресурсов. Для решения проблемы в Fhir существует ресурс Task, который может управлять workflow.

При создании заявки на лабораторное исследование МИС должна кроме основных ресурсов создать ресурс Task и установить для второй компании права на чтение и запись. Управление статусом будет осуществляться через ресурс - Task. Так же Task указывает получателю какое именно действие должно быть произведено с заказом.

Полная схема жизненного цикла Task с точки зрения Fhir представлена ниже:

Жизненный цикл заказа

Лаборатории обычно используют подмножество машины-состояний и работают следующим образом:

1. МИС может создать Task со статусом Draft, но он не должен обрабатываться лабораторией, до перевода в статус Requested.
2. При создании заказа МИС может:
   • создать Task со статусом Requested
   • переводить статус из Draft в Requested
3. ЛИС забирает заказ со статусом Requested и переводит его в статус Received при получении (если нет ошибок, в output ресурса Task записывается номер заказа в лаборатории) и в статус Cancelled (если есть ошибки, то они записываются в output ресурса Task)
4. ЛИС при начале обработки заказа переводит статус Task в Accepted
5. Когда ЛИС считает, что заказ выполнен, она выгружает результаты и переводит статус ресурса Task в Completed (если заказ выполнен успешно) или статус Cancelled (если произошли ошибки)

Контрагент может подписаться на изменение статуса ресурса Task, искользуя подписку на изменения