当前位置： 工作流- 工作流通信模式
当前位置： 工作流工作组:FHIR Infrastructure  |
成熟度: 2 | 标准状态: Trial Use |
如前几节所述，有很多FHIR资源可以直接独立的用于工作流中，而不须使用FHIR来管理工作流的执行。 当我们想使用FHIR来管理工作流的执行时，有几种可用的机制。 除了用FHIR来管理工作流，还有一些情况并不需要管理工作流的执行，而只需简单的以“点对点”(ad-hoc)的方式使用 资源模型 来支持工作流。在选择FHIR工作流的交互模式时，为了达到最佳效果，需要考虑以下几个方面：
回答以上问题，可以指导您为特定的交互用例选择合适的通讯模式。 建议领域工作组根据他们的业务领域分析可以支持哪些工作流，并通过讨论在哪使用和怎么使用工作流， 就其性质而言，实施指南还应对通信模式作出规定，通信模式用于工作流程执行管理。
本节重点介绍一些更常见的模式，并指出它们的特点和局限性，并就何时使用哪个种模式最有效提供建议。 请注意，这个模式列表并不详尽。模式可以以各种方式组合，并且可能存在一些我们还没有想到的可能性。 此外，这些建议仅仅是建议而非指南。实现者可以自由选择他们愿意支持的模式。 因此，围绕工作流执行的紧密互操作性（与使用FHIR的任何其他紧密互操作性一样） 将依靠参与的各方围绕如何支持工作流执行进行一些事先协商， 或者所有参与方都遵守的实施指南需要明确互操作性的相关要求。
在查看此可选方案的列表之前，鼓励读者熟悉以下页面和资源： REST, 消息, 操作 , 服务 和订阅资源。
本页稍后介绍的“模式”会用场景来说明，这些场景都使用了以下约定：
One of the key distinguishing characteristics in the patterns below is whether the pattern supports the tracking of the workflow's state by both the placer and the filler. The workflow state is represented by the Task resource. The Task state machine, which is also presented here, shows the use of Task.status to represent the general infrastructure state of the Task resource.
The combination of Task.status, Task.statusReason and Task.businessStatus provide the mechanism for tracking the workflow state. The following two examples illustrate how that could be accomplished with regards of specific workflows. Note that these examples avoid any specificity on where the described resources exist, or any reference to a specific communication pattern. The goal of the examples is to demonstrate the use of the Task attributes to represent the workflow state.
The following table shows the steps for a simple blood test order, and the corresponding values of the Task attributes. A lot of details on other attributes have been omitted in order to focus on the state changes.
| Workflow step | Task.status | Task.statusReason | Task.businessStatus |
|---|---|---|---|
| Provider orders a blood test for a patient. A ServiceRequest resource is created to represent the order, and a Task resource is created to represent the request to the lab. Task.basedOn points to the ServiceRequest instance. | Requested | New order | Ordered |
| The lab accepts the order. | Accepted | Able to perform the test. | Accepted |
| The patient is at the lab, and blood is drawn. | In progress | Obtained the specimen | Specimen available |
| Work on the blood sample is in progress, preliminary results are available, a DiagnosticReport resource is created, and Task.output.value[1] references the DiagnosticReport resource. | In progress | Preliminary results available | Preliminary results |
| Final results are available | Complete | Final results are available | Final results |
The following table shows the steps for a referral workflow, and the corresponding values of the Task attributes. A lot of details on other attributes have been omitted in order to focus on the state changes.
| Workflow step | Task.status | Task.statusReason | Task.businessStatus |
|---|---|---|---|
| Provider A is seeing a patient with a specific complaint. Based on the exam, Provider A refers the patient to a specialist at clinic B. It is an urgent referral, requesting to see the specialist within 4 days. A ServiceRequest resource is created to represent the referral order, and a Task resource is created with Task.priority set to Urgent, and Task.restriction.period.end set to 4 days in the future. | Requested | New referral | Referred |
| Clinic B receives the referral and puts it on the urgent queue to be reviewed. | Received | Received by organization | Pending |
| Upon reviewing the referral, the clinic determines they have no capacity to see the patient within the specified time period, and they decline the referral. | Rejected | Provider unavailable | Declined |
| Provider A changes the referral request to clinic C. This creates a new Task resource, with the appropriate information | Requested | Changed the referred to provider | Referred |
| Clinic C accepts the referral and it is placed on a scheduler's queue. | Accepted | Able to provide the service. | Accepted |
| An appointment is scheduled for the patient at Clinic C. | In progress | Appointment scheduled | Scheduled |
| Soon after the appointment is scheduled, the patient calls provider A to ask for a different location for the referral appointment, as he lost his transportation, and he cannot reach Clinic C. The provider requests a cancel for the referral. | Suspended | Patient unable to make appointment. | Cancel requested |
| Clinic C confirms the cancellation of the existing task. |
In progress Failed |
Referral cancelled | Cancelled as requested |
| Provider A changes the referral to Clinic D, which is located close to where the patient lives, and can be conveniently reached using public transportation. This creates a new Task resource, with the appropriate information. | Requested | Changed the referred to provider | Referred |
| Clinic D accepts the referral and it is placed on a scheduler's queue. | Accepted | Able to provide the service. | Accepted |
| An appointment is scheduled for the patient at Clinic D. | In progress | Appointment scheduled | Scheduled |
| Patient is seen at Clinic D. A diagnosis is made by the specialist, a prescription is given, and a follow-up appointment is made at clinic D. Task.output.value[1] references a Compositions resource, which contains the encounter summary. | In progress | Intermediary consultation note available | Preliminary notes |
| Patient comes for follow-up appointment at clinic D. The specialist is satisfied by the progress the patient has made and creates the final consultation note. Task.output.value[2] references a Compositions resource, which contains consultation note. | Completed | Final consultation note available | Final notes |
The patterns that facilitate the execution of workflow using the Task resource are grouped in the Workflow Management Patterns section. The patterns where no Task resource is used are grouped in the Ad-hoc Workflow Patterns section. The list of patterns is as follows:
TODO: Insert Jose's decision tree here?