FHIR CDS Hooks

CDS Hooks是FHIR生态下一个决策支持架构，是SMART(Substitutable Medical Applications and Reusable Technologies, 可替代的医学应用和可复用技术)下的一个项目。

FHIR标准下也有一个决策支持相关的模块 - FHIR的Clinical Reasoning模块。它和CDS Hooks是有区别的：

FHIR的Clinical Reasoning模块提供一系列资源模型和工件，用于构建决策支持相关的规则、医嘱集、临床协议和质量指标，并基于此对特定患者和人群进行评估，进而产生决策行为。它构建的是本地决策支持体系。

而CDS Hooks提供一个决策支持架构，打通外部决策支持系统和本地的决策数据源、业务流程。

 

CDS Hooks是开源的，基于知识共享 CC BY 4.0，因此也获得了广泛采纳。

 

 

CDS Hooks的架构

CDS Hooks是打通外部决策支持系统和客户端应用的决策支持架构，完整的架构包括：

CDS客户端：通常是用户的业务系统，如HIS或电子病历

CDS服务：这是CDS Hooks提供的核心组件，向客户端发布的决策支持服务

FHIR服务器：这是用户侧的FHIR服务器，保存的是用户侧的FHIR资源数据。CDS服务通过访问FHIR服务器获得用户侧的决策依据的完整数据

外部决策支持系统：是CDS Hooks内部集成和访问的决策支持系统或决策支持逻辑

CDS客户端和FHIR服务器都是部署在用户侧的。

可见CDS Hooks也是知识库厂商发布他们的决策服务的绝佳架构，无需再考虑如何集成、如何获得标准化数据与术语、如何返回决策，只需要专注在知识上。

 

CDS Hooks目标是将外部决策能力加入到临床工作流程中。它规范了4个决策支持构件：

决策支持的触发点：为了方便将决策集成到业务流程，它定义了一系列触发点(Hooks) - 钩子

决策上下文：使用FHIR资源模型构建决策需要的上下文，并可以直接到本地的FHIR服务器获取数据，从而解决决策依据标准化和仅传递必要信息的需求

决策支持服务：通过封装外部决策支持系统提供标准的决策服务，包括标准的入参和出参，并向外发布

决策建议：将决策建议封装为卡片(Card)，由决策服务返回不同类型的卡片作为决策建议

 

CDS Hooks的流程工作

业务系统，如电子病历在触发点调用决策支持服务，决策支持服务连接到医院本地的FHIR服务器获取决策上下文，CDS服务将决策建议通过卡片形式返回给业务系统。

下图描述的决策场景是：

1. 触发点是电子病历下医嘱流程中的药嘱选择时，医生选择的是阿斯利康的Toprol XL（美托洛尔）。

2. CDS决策服务根据上下文数据需求，到电子病历的FHIR服务器上获取需要的FHIR资源数据。

3. CDS决策服务返回了3张决策建议卡片：

• 信息卡（information card），告诉医生这个药需要没有支付45美金，患者个人需要支付7美金
• 建议卡（suggestion card），根据患者年龄，建议医生替换氢氯噻嗪 （HCTZ）作为一线用药
• smart应用卡（smart app link card），打开高血压管理应用JNC 8 Rx Pro，进行更多的互动

 

 

 

 

CDS Hooks 规范

1. 触发器/触发点 - 钩子(Hooks)

CDS Hooks中的Hooks代表触发点 - 和特定业务流程节点相关联的“钩子”。

目前已经发布的钩子（Hooks）包括：

• appointment-book：预约申请时
• encounter-start ：就诊开始时
• encounter-discharge：就诊结束时
• medication-refill：收到药嘱再配请求时
• order-select：选择一个或多个医嘱准备下达时
• order-sign：在医嘱确认前
• order-dispatch：选择医嘱执行者时，例如选择影像医嘱的执行科室、选择转诊目标的心血管医生
• patient-view: 打开一个患者记录时

这些钩子也是有成熟度的，从0到6共7级。例如patient-view的成熟度目前是5，是成熟度最高的一个。

CDS Hooks是一套架构，允许自定义Hooks，为此CDS Hooks定义了hooks命名规范、上下文规范。而其发布的那些Hooks是一些常见的触发点用例，可以帮助用户创建自己的Hooks。

 

一个Hooks代表一个特定事件，它可以调用多个决策服务。

 

2. 上下文 (context)

CDS Hooks使用FHIR资源作为决策上下文，从而保证决策依据的一致性和准确性。

不同的Hooks需要不同的决策依据，因此上下文是Hooks定义的一部分。用户可以使用CDS Hooks推荐的模版自定义上下文。

由于可以通过访问FHIR服务器可以获得完整的决策信息，因此上下文并不需要明文给出所有的决策信息，例如order-select的上下文是这样的：

示例如下：

CDS服务收到上下文后，可以从医院本地的FHIR服务器获取完整的FHIR资源数据，例如通过patientId获取完整的患者信息。既然要访问本地的FHIR服务器，就需要有本地FHIR服务器的地址和授权。因此，调用CDS服务时，需要CDS客户端在请求参数中传递fhirServer 和 fhirAuthorization，从而使用客户端的FHIR认证和授权。

这里fhirServer是本地FHIR服务器的服务端点；fhirAuthorization是访问FHIR服务器的OAuth2.0授权协议令牌和其它控制数据访问范围的信息：

例如：

{
  "fhirAuthorization": {
    "access_token": "some-opaque-fhir-access-token",
    "token_type": "Bearer",
    "expires_in": 300,
    "scope": "user/Patient.read user/Observation.read",
    "subject": "cds-service4"
  }
}

让CDS服务自己去FHIR服务器获取数据，需要保证网络延迟很低，同时也有授予FHIR服务器访问权限的要求。可以由CDS客户端获取所需的所有FHIR数据，并传给CDS服务，这称之为预获取模式 (Prefetch)，这种模式下CDS服务无需访问客户本地的FHIR服务器，从而

• 避免传递FHIR认证信息，提高安全性
• 提前准备好数据，提高效率和性能

 

3. 决策建议 - 卡片（Card）

决策支持服务将决策结果以卡片(Card)形式返回，同时可以返回任意数量的卡片。

卡片有3种重要性级别(indicator)：

• 信息(info)
• 警告(warning)
• 严重(critical)

而卡片有多种决策结果提示类型：

• 信息类型（information card）：返回信息，以供决策者参考
• 建议类型（suggestion card）：返回建议，以供决策者选择
• smart应用链接类型（smart app link card）：返回超链接（包括启动SMART应用的超链接）,以提供决策者更多的交互可能

对于建议类型的卡片，其中可以包含决策的一个或多个建议。每个建议可以有多个行为(Action)，这些Action用于在客户端本地的FHIR服务器上执行对FHIR资源的创建、更新、删除操作。

通过理解卡片规范，客户端可以将返回的决策建议集成到业务流程并实施干预。

 

4. 决策支持服务

决策支持服务是RESTful API，提供多种安全访问机制，和多种服务。

 

决策服务：客户端根据决策触发点调用相应的决策服务，并传递上下文信息。决策服务定义了标准的请求规范和响应规范，用于接收上下文信息、FHIR服务访问授权信息，并返回建议卡片。

发现服务：客户端怎么知道一个决策支持服务提供哪些触发点（Hooks）呢？除了用于决策本身的服务（RESTful API），它还需要提供一个发现服务，让客户端知道提供哪些Hooks，需要什么样的上下文。

反馈服务：CDS服务可以额外提供一个反馈服务，用于被客户端调用以记录决策者的决策操作和决策反馈：

• 决策者选择了什么建议
  • 不选择
  • 选择其一
  • 全部选择
• 如果拒绝建议，决策者拒绝的原因

反馈服务是可选的，不是所有的决策支持服务都提供。

 

CDS Hooks 测试

CDS Hooks提供了官方沙箱，用户可以通过这个沙箱进行CDS Hooks的测试。

这个沙箱提供了三个用例，背景是美国联邦医疗保险和医疗补助服务中心（CMS）对药嘱、高值影像学医嘱的控制，通过CMS提供的决策支持服务，医院可以得到对药嘱、高值影像学医嘱的CMS建议，遵从建议将不影响从CMS获得医保报销。这类似于国内的三医联动的业务。

沙箱模拟的是医院的电子病历系统，已经集成了CDS Hooks的决策支持服务。用户可以在这个电子病历系统里查看患者信息、下达药嘱和下达影像医嘱，并查看CDS服务收到的请求和返回的响应，以及得到CDS服务反馈的建议后，电子病历可以如何采纳或拒绝建议。

点击进入沙箱网页，默认已经选择了患者，可以忽略“查看患者信息”用例，进入下面二个测试用例。

1. 药嘱决策管理

当医生在电子病历中准备给患者下达药嘱时，选择RxView标签页，进入该用例。
左侧模拟的是电子病历医嘱下达页面，右边是CDS开发者面板，保证"Select a Service"选择的是"cms-price-check - https://sandbox-services.cds-hooks.org/cds-services/cms-price-check"，这是CMS的药嘱价格检查的CDS服务。

选择Treating(治疗目的）为Hypertension（高血压），并在Medication(药嘱)里输入Toprol，并在弹出的药品中双击选择一个，如下图。这时电子病历的order-select 钩子会调用CDS服务。

Toprol XL成分是美托洛尔，一种可用于治疗高血压的β -肾上腺受体阻滞剂，因为是阿斯利康的专利药，价格比仿制药贵很多。

右边可以看到CDS的请求(Request)和响应(Response)消息：

对请求消息，注意里面的hook、fhirServer和context数据；对响应消息，注意里面的cards和下面的suggestions、actions。

同时，在左侧的电子病历页面，可以看到返回的建议卡信息被显示在上面，包括：

• 小结(summary)里说明的仿制药可以节省51.72美金。
• 建议将药品直接换为仿制药 - 这是一个action，在电子病历页面上显示为“Change to generic”按钮。
• 不予理会(overrideReasons)里给出的用户不予理会建议的原因，显示在“Dismiss”下拉列表框里。

 

如果用户选择接受建议，可以点击“Change to generic”按钮，它会直接在FHIR服务器里生成仿制药医嘱；

如果用户不理会建议，可以选择“Dismiss”列出的原因，例如仿制药无库存。这时电子病历会通过反馈服务将不予理会的原因返回CDS服务，用于统计、分析、改进决策支持。

 

2. 高值影像医嘱决策管理

美国的保护获得医疗保险法案(Protecting Access to Medicare Act - PAMA)目的是降低美国医保压力、防止医保滥用。这个用例就是其中的对高值影像检查的控制决策服务。如果对PAMA法案背景感兴趣，资料在这里。

当医生在电子病历中准备给患者下达影像医嘱时，选择PAMA Imaging标签页，进入该用例。

在右边的CDS开发者面板中"Select a Service"选择是"pama-imaging- https://sandbox-services.cds-hooks.org/cds-services/pama-imaging"，这是CMS的PAMA项目合规性检查的CDS服务。

在左侧search reasons中输入“Congenital heart disease” （先天性心脏病）后，就可以观察右侧电子病历发起的CDS服务请求和决策支持服务返回的响应。响应中有2张卡片，分别是smart应用链接卡和建议卡。

在左侧的电子病历系统中也可以看到2个按钮，分别是建议下达MRI的检查按钮和打开SMART PAMA Demo App应用的链接。

 

 

已经有很多将CDS Hooks应用于药物、药物基因组学临床、甚至是科研的决策支持服务的研究和应用。而上面这几个用例不仅向我们展现了CDS Hooks的工作方式和能力，还展示了这个临床决策支持架构也很适合于三医联动相关的政策合规性决策，展示了它广泛的适用性。