工作组: FHIR Infrastructure 成熟度: 2 标准状态: Trial Use

工作流是卫生健康领域的一个重要组成部分——医嘱、健康管理方案、转诊是医院住院场景和社区卫生的主要活动,这些活动驱动着工作流。 当需要共享有关工作流状态或关联关系时,当需要协调或驱动跨系统工作流的执行时,以及当需要定义操作授权、依赖关系统和工作前提时,都涉到FHIR的及工作流。

工作流状态与关联关系

FHIR不需要用于工作流的执行。 医嘱、护理计划、实验室结果、住院、索赔和其他记录都可以通过FHIR资源直接实现数据共享,而无需通过FHIR交易来执行医嘱或索赔。 对工作流执行的互操作支持是一种更高级的FHIR活动,因为它对标准化的程度要求更高。 可互操作的工作流执行不仅需要将交换数据标准化,还需要将跨系统的流程、角色和活动标准化。 然而,即便不使用FHIR来执行工作流,仍然需要将与工作流相关的数据元素标准化: 事件或结果如何关联其开立医嘱?父步骤和子步骤如何链接在一起?护理计划如何确定它遵循的是哪个方案?

FHIR定义了参与活动的三类资源——请求事件定义。 每个类别都有一个与之相关联的“模型”。属于同一类别的资源者鼓励遵守各自的模型。这些模型为每个类别的大多数资源提供了典型的标准元素。 由于工作组不希望典型的领域行为脱离实际的需求,这些需求比“期望的”架构模型更具权威性,所以并不要求严格的遵守这些模型。 在某些情况下,可能使用扩展而不用核心元素来实现功能,在这种情况下,给定资源的模型功能被视为“不常用,但仍然相关”。

模型及其相互关系将在本页的 工作流资源模型章节详细介绍。

工作流执行

除了为工作流过程中使用的资源定义模型外,FHIR还支持这些过程的执行。但FHIR并没有为工作流架构定义“一刀切”的解决方案。 FHIR支持各种互操作性范式,其中大多数(REST消息传递 服务)都能驱动工作流执行。(文档 Document范式可以与其他模型结合使用,但不直接驱动工作流执行。) 此外,根据工作流过程的场景和需求,其中一些范式允许多种方法来支持工作流。

工作流执行和通信模型部分描述了工作流执行的许多选项,总结了它们各自的优缺点,并给出了建议的最佳使用场景。

工作流定义

医疗方案、医嘱组集、指南和其他结构(包括对应发生的活动类型、应发生的顺序、相关依赖性、在什么情况下应开始或结束等的定义)的定义由一对资源来实现:

这“一对”资源的使用将在此处讨论。

并不是FHIR中的所有资源都与工作流相关——许多资源用于描述实体和角色(患者、药物等)或基础框架(结构定义、值集等)。 然而,大部分的FHIR资源都以某种方式用于对活动的描述,这些资源几乎都参与到工作流领域中——它们描述了可以完成(定义)、需要完成(请求)或已经完成(事件)的事情。 下表汇总了与工作流相关的资源:

定义 此类资源用于定义与患者相关但与时间无关的某种可能发生的事件。
请求 此类资源用于请求或表达对要做的事情的愿望和意图。
事件 此类资源用于表示某些已经完成的事件和由于某个请求的发起而将会完成的事件
* AppointmentAppointmentResponse资源不遵循与其他资源相同的请求/响应模型。 它们的设计基于iCal标准(又称iCalendar,一种标准的互联网日历格式),因此它们不会像大多数其他资源那样严格地遵循模型。 为了完整的汇总与流程相关的资源,此列表才将它们包含在内。
Task资源同时具有“请求”和“事件”的特性,所以将其同时放入此列表的这两个分类中。

注意:请求、事件和定义不是1:1:1的关系。一些请求和事件有明显的成对关系。例如,SupplyRequest 通常会与SupplyDelivery.配对。 EnrollmentRequestEnrollmentResponse等也是如此。 然而,另一些资源却没有严格的成对关系。 ServiceRequest 可能由 DiagnosticReportProcedureRiskAssessment等资源来响应。 类似的,Procedure也可以由 ServiceRequest触发。 应该在这些资源中声明一组通用链接。请求由哪种资源来响应受三个因素控制:Request.code、引用的相关工作流定义/医疗方案、本地约定。

资源的这三种模型有一套标准的关系,既自相关,又彼此相关。

工作流关系图,展示了请求、事件和定义及其相互之间的关系

具体而言:

  • 请求、事件和定义可以指向它们各自的定义
  • 事件和请求可以指向它们所基于的医疗方案、计划或医嘱
  • 事件和定义可以组织成父模块和子模块的父子关系
  • 定义和请求都可以替换其老版本的定义。

此表中列出的关系并不完整,但涵盖了那些作为模型组成部分的“标准关系”。 有关这些关系的进一步描述和指南可以在请求事件定义的逻辑模型中找到。

此处的请求是指发起某项活动时表示医疗方案、计划或医嘱的资源。 请求模型 为所有与请求相关资源定义了一些典型的公用元素。

为执行请求所需的大量信息在不同的场景下会有很大区别。 一些请求实例不会提供模型所需的所有信息 ——在授权发起活动以响应请求之前可能需要从医疗方案、患者偏好、决策支持处获取额外的信息。 比如:在药房(甚至护士站)有权提供用药的强度与途径的情况下, MedicationRequest 资源可以不提供这些参数信息。 又如,只有在选择了镜框并对患者面部进行了必要的测量,以使镜片能够在镜框中正确定位后, VisionPrescription资源才可以执行。

所有以“医嘱”为目的的请求都是在进行某种授权。 授权的内容是否足以让活动立即执行取决于由谁来执行和执行所需的条件了。 对某个“请求”是否可执行,是由所涉及的系统和被要求采取行动的人所决定的。

另外,存在“请求”实例并不就意味着就会立即执行以满足请求——甚至可能永远都不会执行。 请求履行的决定可以委托给患者或下游的参与者。此类参与者可能需要先获取到额外信息以执行请求。

事件是指那些表示正在进行或已经完成的某些活动或观测的资源。 例如:临床手术、财务交易、下诊断等。 事件模型为所有与事件相关资源定义了一些典型的公用元素。

定义是指那些代表活动的资源,这些活动可以在某个时间执行,它们和对象无关,比如医疗方案、医嘱组集、临床指南等。 定义模型为所有与定义相关的资源提供了一些典型的公用元素。

STU Notes:

  • It is possible to replace some portions of the MessageHeader with a reference to the Task resource. Doing so would mean consistency in how asynchronous requests are represented using REST and messaging. However, it introduces an additional layer of complexity and formality into the messaging paradigm that may be unwelcome, particularly for those systems that do not currently foresee a need to support both RESTful and messaging invocations of workflow
  • The OperationDefinition resource could be used to define types of tasks and the sets of parameters that can go with them. Is this an appropriate use of the OperationDefinition resource?
  • The SupplyRequest, DeviceRequest and VisionPrescription resources have a significant degree of overlap. Should they remain distinct resources?

Feedback is welcome here .