工作组: FHIR Infrastructure 标准状态: Informative

12.0 工作流组件

工作流组件主要用于活动之间的协作，包括系统内部和跨系统的活动。这包括三个主要方面：

  • 我们如何要求另一个人、设备或系统做一些事情？
  • 我们如何跟踪活动之间的联系和依赖关系? 例如，操作如何得到授权、如何将复杂的活动分解为单个步骤、如何从医疗方案的制定到计划安排再到医嘱的下达等等。
  • 我们如何定义可能有哪些活动，以及这些活动中步骤的预期顺序和依赖性？即流程/业务流程定义

12.0 索引

基础框架
日程安排
临床过程

12.0.1 介绍

工作流可以通过四种方式来执行： 直接将资源发布到目标服务器（与特定标记结合）、使用任务Task资源、使用消息交换 、使用FHIR服务。 本规范的工作流部分介绍了工作流的基础概念，并描述了各种通信架构的工作流模式。

除了任务Task资源外，本规范还定义了三个逻辑模型—— 定义, 请求和事件 ，这些模型为工作流中常涉及的资源定义了模式。 这些模式中包含的元素用于定义各种资源类型的公共属性以及它们之间的关系。 工作流页面总结了这些关系，并提供了一个完整的资源列表，这些资源遵循（或期望其遵循）请求和事件模式。

最后，方案定义PlanDefinition资源与活动定义ActivityDefinition资源结合起来， 通过描述可能发生的活动类型并设置活动的组成、顺序、相互依赖性和流程的规则，以支持创建医疗方案、医嘱组合、指南和其他工作流定义。

12.0.2 常见用例

在卫生健康的许多场境中都涉及到工作流的使用：

  • 下达实验室医嘱、药品处方或其他临床医嘱 以及保险理赔、登记查询、预约 或类似管理请求，并要求由相关组织或个人响应请求。
  • 在实施的过程进行协商，例如在接受保险赔付或转诊之前请求更多的信息，或在执行医嘱时提出替代疗法。
  • 让下达医嘱的医生知道当前医嘱执行的进度（例如，已抽血、正在处理样本、初步结果已出等等）。
  • 为管理患者健康，将一组临床或管理活动定义为一个计划或建议， 然后跟踪这些计划和建议是如何（或没有）根据排期来执行的。
  • 为满足系统需求，将状态的变更传达给某个请求或医嘱（例如暂停、更新、取消等），以便适时进行调整。
  • 请求状态更改、请求患者合并、以异步方式调用某些操作或决策支持—例如，需要人工干预的情况
  • 设计或遵循研究方案、化疗方案、实例化医嘱集或其他计划定义

FHIR提供了多种方法来应对这些场景（以及许多其他场景）。 常用机制及其优缺点可以在工作流章节的模式介绍中找到。 .

12.0.3 Security and Privacy

Resources related to workflow need to adhere to the same security and privacy guidelines that apply to all FHIR resources, including specific considerations for those that may contain personally-identifying information. There are a couple of additional security and privacy considerations specific to workflow:

1. Some workflows are ad-hoc without pre-defined participants or flows. These can be challenging for security and privacy processes to manage appropriately

2. Workflow can drive automated behavior. I.e. The mere existence of an electronic record can cause information to flow, procedures to be performed, records to be changed and money to be transferred, potentially without any intervention, oversight or sanity checking by a human being. As such, even greater care must be taken to ensure that:

  • constraints are placed on what systems (and users) can initiate workflow processes
  • requests for action are appropriately authenticated before action is taken
  • patient consents and other relevant policies are enforced either by the system storing the request or the system acting upon it (and that if enforcement is not performed by the actor, that they are confident that relevant policies have been enforced on the request prior to action)

For more general considerations, see the Security and Privacy module.

12.0.4 Developmental Roadmap

Initial work has taken place on aligning most (though not yet all) resources with the Definition, Request and Event patterns. In the lead-up to R5, we'll be moving the alignment checks into the build process and more formally documenting (and potentially reporting) on variations along with their justifications. Further alignment is also possible (where beneficial to implementers). We'll also be examining the potential for exposing alignment with the patterns in a computably useful manner (e.g. as interfaces).

Work will continue on the workflow patterns, including vetting the patterns against various clinical scenarios and enhancing pattern documentation. We also hope to examine both messaging and services in more detail with further guidance about when and how such mechanisms should be used for workflow and how they relate to the Task resource. As well, we'll examine the possibility for developing "standardized" workflows for certain domains and how such patterns might be documented, particularly through the use of the ExampleScenario resource. We will look for implementer feedback to guide this work.

The PlanDefinition and ActivityDefinition resources will continue to evolve based on feedback from the implementer community. We'll explore using them in a variety of ways, including clinical order sets, medication protocols, workflow protocols, clinical pathways, administrative protocols, etc. We hope to develop several example workflow protocols.

Additional topics for future work include:

  • The initial effort to align with workflow patterns has been a bit over-zealous for some resources, resulting in the loss of domain-specific context or occasionally the introduction of elements that might be more properly represented as extensions. In R5, we'll continue to work on improving the balance, ensuring that consistency with patterns does not overshadow the essential requirements for implementer intuitiveness and simplicity
  • Resolving the overlap between the SupplyRequest, DeviceRequest and VisionPrescription resources
  • Improving mapping and alignment of the elements and status codes of the Task resource with the WS-HumanTask specification
  • Creating "best practice" guides for how to implement workflow for different business patterns
  • Examining how workflow is used for compensating actions E.g. account transactions and reversals