8.4 中山市人民医院基于FHIR标准的CDS应用案例
8.4.1 背景
广东省中山市人民医院位于中山市中心城区，是集医疗、教学、科研、预防保健为一体的综合性“三级甲等医院”。2018年在广东省公立医院绩效考核中获全省第三、地级市第一。2021年3月，中山市人民医院成功入选为广东省高水平医院建设第二期重点建设单位。
中山市人民医院自1993年开始探索用计算机进行信息管理，1994年建立了DOS平台基础的门诊收费网络系统。1997年建成DOS平台基础上的住院处、病区管理网络系统。2000年到2003年，中山市人民医院研发新的大HIS系统，全方位覆盖医院所有业务流程。2020年，医院依托现有信息化资源和建设成果，改造现有系统、新增缺项系统、补充和完善医院信息平台，在保障医院运行的同时，实现临床医疗管理、日常运营管理、医学科研管理的智能化和深化应用。
中山市人民医院在过往的信息化建设过程中，采购了合理用药系统、VTE静脉血栓防治管系统、CDSS临床辅助决策支持系统、病历质控系统、病案质控系统等CDS类软件，然而这些软件涉及多个厂商，诊疗数据反复获取、与医生站或护士站交互频繁，影响业务系统的性能和医护的操作体验。
信息科与厂商共同探讨，采纳了HL7发布的CDS hooks标准，通过对数据交互接口进行重构，减少了实时交互接口的数量，降低了对临床业务系统性能的影响，整合交互界面，减少了医护端弹窗的数量。
8.4.2 业务需求与流程
本文将合理用药系统、VTE静脉血栓防治管系统、CDSS临床辅助决策支持系统、病历质控系统、病案质控系统统称为CDS类软件。
中山市人民医院的CDS类软件涉及到的应用场景主要有两大类，一类是临床知识的关联调阅，另一类是各类事中质控提示。
临床知识推荐包括药品说明书、疾病知识、检查知识、检验知识、手术操作知识、护理操作知识、临床指南规范和专家共识、医疗相关法律法规等。临床知识包括医院自行维护的知识库。
事中质控提示的应用场景主要有：
| 场景类别 | 应用场景 | 应用场景简述 | 涉及系统 |
|---|---|---|---|
| 辅助诊疗 | 检验项目推荐 | 根据权威指南、临床路径、共识等，结合患者临床数据，为医生推荐相关检验项目，供医生参考。 | CDSS系统 |
| 检查项目推荐 | 根据权威指南、临床路径、共识等，结合患者临床数据，为医生推荐相关检查项目，供医生参考。 | CDSS系统 | |
| 治疗方案推荐 | 根据权威指南、共识等文献知识，结合患者临床数据，为医生提供相关治疗方案、治疗建议。 | CDSS系统 | |
| 护理措施推荐 | 根据权威指南、共识等文献知识，结合患者临床数据，提供相关护理建议。 | CDSS系统 | |
| 药物医嘱核查 | 下达药物医嘱时，能够针对病人性别、年龄、诊断、检查检验结果、配伍禁忌等进行用药合理性自动审核并针对问题给出提示。 | 合理用药系统、CDSS系统 | |
| 检查申请核查 | 下达检查申请医嘱时，根据检验检查的特点，如人群、时效、药物对检验结果的干扰、性别等因素，对不合理的检验检查给予提醒，根据不同的检查类型，建议取消检查或在另择合适的时机检查。 | CDSS系统 | |
| 检验申请核查 | 下达检验申请医嘱时，能够针对病人性别、诊断、以往检验申请与结果等进行申请合理性自动审核并针对问题申请给出提示。 | CDSS系统 | |
| 治疗申请核查 | 在下达治疗医嘱或申请后，能够对于易在治疗中出现意外的高风险治疗项目或患者在治疗前给予核查警示。 | CDSS系统 | |
| 手术申请核查 | 在下达手术医嘱或申请后，能够对于易在治疗中出现意外的高风险手术项目或患者在手术前给予核查警示。 | CDSS系统 | |
| 输血申请核查 | 在下达输血医嘱或申请后，能够对于输血禁忌、血型不匹配等风险进行核查提示。 | CDSS系统 | |
| 检验结果解读 | 提供检验结果分析决策知识库，结合患者临床诊断、药物使用等数据进行检验结果的解读和分析。 | CDSS系统 | |
| 检查结果解读 | 提供检查结果分析决策知识库，结合患者临床诊断、药物使用等数据进行检查结果的解读和分析。 | CDSS系统 | |
| 监测预警 | 用药风险警示 | 在下达药物医嘱后，结合患者的主诉症状、诊断、用药、检验检查结果等基础信息进行用药合理性综合预警。 | 合理用药系统、CDSS系统 |
| 治疗风险警示 | 在下达治疗医嘱后，针对病人诊断、性别、检验检查结果、治疗评估结果等临床数据，对于易在治疗中出现意外的高风险治疗项目或患者在治疗前给予风险警示和建议提示。 | CDSS系统 | |
| 手术风险警示 | 在下达手术医嘱或申请后，根据病人症状、体征、临床表现、诊断、用药、检查检验结果、病人评估信息和知识库，对高风险手术术前术后给出警示。 | CDSS系统 | |
| 禁忌症预警 | 可根据患者临床数据，如：基本信息、诊断、症状、医嘱、检验检查结果等提示临床用药、检查检验、手术操作等相关的禁忌信息。 | CDSS系统 | |
| 传染病预警 | 支持根据诊断判断传染病情况，进行提示预警。 | CDSS系统、传染病监测系统 | |
| 不良事件预警 | 可根据患者临床数据，如：基本信息、诊断、症状、医嘱、检验检查结果等提示临床不良事件风险预警信息。 | CDSS系统、不良事件管理系统 | |
| 危急值监测提示 | 依据检验、检查结果，判定结果是否异常并给出提示。 | CDSS系统、危急值管理系统 | |
| 诊疗效果预警 | 可根据患者临床数据，如：基本信息、诊断、医嘱、检验检查结果等给出临床诊疗相关合理用药、治疗建议、治疗风险等提示。 | CDSS系统 | |
| 诊断推荐 | 疑似诊断推荐 | 支持基于患者的临床数据和文书内容，如体征、主诉、现病史、检查检验结果等，智能提示患者疑似诊断，实时引导医生全面考虑患者病情，避免漏诊、 误诊。 | CDSS系统 |
| 鉴别诊断推荐 | 支持根据权威指南、共识等文献知识，结合患者当前临床诊断和数据，智能提示相关鉴别诊断，并提供参考的文献内容。 | CDSS系统 | |
| 辅助评估 | 常见病电子评估量表 | 内置常用的医学评估表单，支持医生在线填写表单，根据表单规则自动计算评估分数和评估结果。 | CDS系统、VTE防治管系统 |
| 量表评分结果分析 | 自动计算分值，基于标准结果解读进行评估结果分析。 | CDS系统、VTE防治管系统 | |
| 常见病评估提示 | 支持根据患者病情为医护人员推荐所需评估的评估表。 | ||
| 评估量表管理 | 支持针对评估表评估历史，评估项明细、评估时刻进行查看和管理。 支持与评估相关的业务功能，如审核，归档等功能。 支持评估完成的评估表进行在线单份打印，批量打印。 | CDS系统、VTE防治管系统 | |
| 病历病案质控 | 医生端提醒 | 支持医生查看本科室患者质控列表； 支持医生书写病历时实时提醒质控缺陷； 支持医师对自动提醒的质控缺陷项进行问题反馈； | 病历质控系统、病案质控系统 |
| 医生端预警 | 支持在电子病历系统对临床住院医生提前告知待办书写事项功能； 支持医师打开患者病历时，预警该患者待书写病历、未完成病历； 支持医生对质控预警结果进行反馈，同时支持录入反馈原因。 | 病历质控系统、病案质控系统 |
这些系统在采集数据上存在重合，都需要在医生工作站或者护士工作站进行埋点，触发相应提醒事件，甚至需要实时获取临床数据；而在界面展示上，医生端、护士端存在多个样式各异的悬浮窗、侧边栏。一方面导致医生工作站系统数据接口负担重且数据不能复用，另一方面不同风格的展示也导致医生体验下降。
为解决这一问题，信息科与厂商共同讨论，最终确定采用基于HL7 FHIR的CDS hooks标准，统筹整合建设全院临床辅助决策支持平台，以便达到需埋点的实时数据只采集一次、展示界面只有一个的目标。
8.4.3 实现方法
本项目采用CDS hooks标准。CDS Hooks是HL7发布的用于临床决策支持的规范，描述了CDS客户端和CDS服务之间的接口标准。详细技术标准可参考HL7官网发布的cds-hooks介绍，目前为1.0版本：https://cds-hooks.hl7.org/1.0/#hooks
CDS hook的基本组成部分有：CDS服务、CDS客户端、hook触发事件、用户界面。
CDS 服务:决策支持服务，它接受包含患者信息的请求并提供响应。通过RESTful api，提供针对患者的诊疗建议等服务，它允许CDS开发人员发布所提供的CDS服务类型，以及CDS客户端用来请求决策支持的服务端点。
CDS 客户端: EHR电子健康记录或其他临床信息系统，客户端使用CDS的服务。CDS客户端通过调用应用程序工作流中hook触发事件的CDS服务来使用决策支持。每个触发事件都定义了上下文，即客户端中可用的、特定于工作流的上下文信息。每个服务都发布它所支持的触发事件和它所需要的预取数据(CDS服务需要这些信息来决定应该提供什么样的决策支持)。
Hook 触发事件: 客户端系统内部工作流中的定义的触发点，它具有作为请求的一部分的上下文信息。
用户界面 ：决策支持服务以卡片的形式返回，这些卡片代表离散的建议或建议，在CDS客户端中呈现给用户
每一个hook都有规定的符合FHIR标准的数据。比如在触发点保存药品医嘱时，所需的数据有：患者标识信息（patient）、药品医嘱信息（MedicationRequest，主要包括药品编码、药品用法、药品频次、用药天数、药品）。
8.4.3.1 规划触发事件
我们首先规划了CDS类软件与临床业务系统交互所需的触发事件和触发点，如患者切换、医嘱浏览、医嘱录入、报告调阅等。
患者切换触发点： 医生系统、护理系统在切换患者时，需将切换的病人信息传给CDS。切换患者包括患者列表切换、床位卡切换、打开某患者的信息界面、打开某患者诊疗界面。
诊断触发点： 医生保存诊断、提交诊断、修改诊断、删除诊断时，讲当前诊断发送给CDS。
医嘱校验触发点： 医生开立医嘱、删除医嘱、保存医嘱、发送医嘱、停止长期医嘱时，将当前医嘱内容发送给CDS。
医嘱包含门诊、急诊、住院医嘱，包含药品医嘱、检查医嘱（检查申请单）、检验医嘱（检验申请单）、治疗医嘱、手术医嘱（手术申请单）、膳食医嘱、护理医嘱等。
知识库查阅： 点击“知识库查阅”。
| 涉及系统 | 应用场景 | 主要交互触发接口 |
|---|---|---|
| 医生系统 | 医嘱合理检查及提醒 | 医生开立医嘱、删除医嘱、保存医嘱、发送医嘱、停止长期医嘱时，将当前医嘱内容发送给CDS。 医嘱包含门诊、急诊、住院医嘱，包含药品医嘱、检查医嘱（检查申请单）、检验医嘱（检验申请单）、治疗医嘱、手术医嘱（手术申请单）、膳食医嘱、护理医嘱等。 |
| 医生系统 | 诊断校验 | 医生保存诊断、提交诊断、修改诊断、删除诊断时，讲当前诊断发送给CDS |
| 医生系统 | 诊疗方案推荐 | 借助大量的补充数据进行逻辑推理，无需单独的实时数据接口 |
| 医生系统 | 医学知识库查阅 | 单击按钮 |
| 护理系统（护士工作站、护理病历） | 护理知识库查阅 | 单击按钮 |
| 医技系统 | 医技知识库调阅 | 单击按钮 |
| 药房系统 | 药品知识库调阅 | 单击按钮 |
对于检验检查报告，CDS系统采取后台监测的方式，自动检查报告的新增、发布、撤销状态，并根据当前患者，从资源中关联获取对应患者的本次或历次报告结果数据，暂不设置实时交互。
8.4.3.2 服务发现与调用
规划了统一的CDS服务，给合理用药系统、VTE静脉血栓防治管系统、CDSS临床辅助决策支持系统、病历质控系统、病案质控系统调用。
CDS服务提供一个固定的端点（endpoint），以允许CDS客户端发现可用的CDS服务，包括服务描述、何时应该被调用、被请求预取的数据等信息。CDS服务提供者确保其服务能被发现，并返回提供所有服务列表。客户端获取服务列表的请求，返回结果是一组包括特定属性的CDS服务。
每个CDS服务都应该具有以下属性：
| 字段 | 是否必选 | 字段类型 | 描述 |
|---|---|---|---|
| Hook | 必须 | String | 本服务作用于哪个触发事件 |
| Title | 建议 | String | 服务的名称 |
| Description | 必须 | String | 服务的描述 |
| Id | 必须 | String | 在{baseUrl}/cds-services/{id}中的服务编码 |
| Prefetch | 可选 | Object | 一个包含FHIR查询的键/值的对象，该服务请求CDS客户端在每次服务调用中预取并提供这些查询。键是描述被请求数据类型的字符串，值是表示FHIR查询的字符串。 |
CDS客户端应该通过服务发布的JSON文档来调用CDS服务。CDS服务端点可以由CDS服务基础URL和一个单独的服务id组成，例如{baseUrl}/ CDS -services/{Service .id})。服务请求应包含以下字段：
| 字段 | 是否必选 | 字段类型 | 描述 |
|---|---|---|---|
| Hook | 必须 | String | 哪个触发事件能触发本服务 |
| hookInstance | 必须 | String | 该特定触发事件的UUID |
| fhirServer | 可选 | URL | CDS客户端所属的FHIR服务器URL。如果提供了fhirAuthorization，则该字段为必选 |
| fhirAuthorization | 可选 | object | 持有OAuth 2.0承载访问令牌的结构，该令牌授予CDS服务对FHIR资源的访问权，以及与令牌相关的补充信息 |
| context | 可选 | Object | 触发事件关联的CDS服务所需的特定数据信息。例如，在病人视图触发事件中，context包括正在被查看的病人的FHIR标识符 |
| Prefetch | 可选 | Object | CDS客户端需预取的FHIR资源数据 |
hookInstance应该是全局唯一的，并且在CDS客户端运行时，用户可以串联或并行执行多个操作。例如，临床医生可能会连续开两个处方，每个处方操作将被分配一个唯一的hookInstance，这样CDS服务就能唯一标识每个触发事件的调用。
示例：
{
"services": [
{
"hook": "patient-view",
"title": "CDS Service Example",
"description": "An example CDS service",
"id": "static-patient-greeter",
"prefetch": {
"patientToGreet": "Patient/{{context.patientId}}"
}
},
{...}
}
8.4.3.3 FHIR资源规划
CDS服务需要特定的FHIR资源来进行计算、推理。CDS客户端可以调用CDS服务传递上下文数据（如当前用户和患者id），可以向CDS服务发起请求，要求CDS服务从FHIR服务器中提取所需且授权的FHIR资源。
为了能够让CDS服务快速响应（大约500毫秒），FHIR提供了两个可选的方法。
首先，FHIR资源可以在服务调用中将从CDS客户端"预取"的数据传递给CDS服务。在CDS服务描述中请求的FHIR资源作为键值对传递，每个键值匹配CDS服务描述中的一个键值，每个值就是一个FHIR资源。如果需要预取数据，则CDS服务向CDS客户端注册一组"预取模板"。
第二种方法是让CDS服务能自己检索FHIR资源。如果CDS客户端决定的CDS服务获取自己的FHIR资源，CDS客户直接获得并传递到CDS的发行无记名令牌服务使用在执行对CDS FHIR API调用客户端的FHIR服务器来获取所需的资源。如果需要额外的资源，一些CDS客户端可能会传递预取的数据，以及CDS服务使用的不记名令牌。每个CDS客户应根据性能考虑和对随之而来的安全和安全风险的评估，决定首选哪种方式或组合。
FHIR的资源比较多，而CDS并不需要用到所有的资源。因此，结合医院自身的实际情况和CDSS实际所需，我们对FHIR资源进行了裁剪。
CDS用到的资源主要是第二层基本资源、第三层临床资源。临床类资源，诊疗过程涉及到的过敏史、体格检查、家族史、既往史、疾病诊断、医嘱、治疗、护理、评估单等。
临床推理类资源也对临床决策的文档结构也给出了相关定义。
为了提高响应速度，CDS客户端需要借助CDS服务预取一些FHIR资源，在CDS服务描述中请求的FHIR资源作为键值对传递，每个值就是一个FHIR资源。CDS服务也可以检索FHIR资源。
8.4.3.4 服务响应
CDS服务应使用200 HTTP响应。由于CDS客户端可能从同一个触发触发事件调用多个服务，因此可能存在与同一信息相关的多个响应。
HTTP状态示例：
| 编码 | 描述 |
|---|---|
| 200 ok | 一个成功的响应 |
| 412先决条件失败 | CDS服务无法通过预取请求或直接调用FHIR服务器来检索必要的FHIR数据来执行其决策支持 |
用户展示界面响应信息，应包含以下属性：
| 字段 | 是否必须 | 字段类型 | 描述 |
|---|---|---|---|
| 摘要 | 必须 | string | 摘要消息，以显示给此卡内的用户 |
| 细节 | 可选 | string | 可选详细信息；如果提供，必须在GitHub标记中表示。对于非紧急卡，CDS客户端可以隐藏这些详细信息，直到用户点击一个像"查看更多细节……"这样的链接 |
| 指示器 | 必须 | string | 这张卡片所传达的重要性和重要性。允许的值，按照优先级由低到高排序：信息、警告、关键。CDS客户端可以使用此字段来帮助做出UI显示决策，如展示顺序或显示颜色 |
| 来源 | 可选 | object | 该条决策支持的主要指导来源，包含可读的简短标签、URL链接等 |
| 建议 | 可选 | 数组 | 允许服务在当前活动中提出一系列变化（例如，改变当前处方活动的处方药物的剂量）。如果有建议，也必须提供选择行为 |
| 选择行为 | 可选 | string | 描述了在卡片中提出的建议的预期选择行为，例如创建、更新、删除 |
| 链接 | 可选 | 数组 | 允许服务建议一个到用户可能希望运行的应用程序的链接，以获得其他信息，或帮助指导决策 |
服务响应示例：
{
"cards": [
{
"summary": "Example Card",
"indicator": "info",
"detail": "This is an example card.",
"source": {
"label": "Static CDS Service Example",
"url": "https://example.com",
"icon": "https://example.com/img/icon-100px.png"
},
"links": [
{
"label": "Google",
"url": "https://google.com",
"type": "absolute"
},
{
"label": "Github",
"url": "https://github.com",
"type": "absolute"
},
{
"label": "SMART Example App",
"url": "https://smart.example.com/launch",
"type": "smart",
"appContext": "{\"session\":3456356,\"settings\":{\"module\":4235}}"
}
]
},
{
"summary": "Another card",
"indicator": "warning",
"source": {
"label": "Static CDS Service Example"
}
}
]}
8.4.3.5 安全保障
与CDS hooks的API相关的安全风险包括：
1.在CDS客户端和CDS服务之间传输的机密信息和特权授权可能被攻击者秘密拦截的风险；
2.伪装成合法CDS服务的攻击者可能从CDS客户端接收机密信息或特权授权，或可能向CDS客户端提供可能对患者有害的决策支持建议的风险；
3.攻击者伪装成合法服务订阅的CDS客户端（即中间人）可能会拦截并可能改变双方之间交换的数据的风险。
4.CDS服务可能会在返回到CDS客户端的卡中嵌入危险的建议或与危险的应用程序的链接的风险。
5.基于CDSHooks浏览器的部署可能成为跨源资源共享(CORS)攻击的受害者的风险。
CDS服务可能基于过时的患者数据返回决定，从而对患者造成安全风险。
信息传输安全
CDSHooks定义了一种安全模型，通过确保CDS服务和CDS客户端的身份被相互验证；通过保护CDS客户端和CDS服务之间共享的机密信息和特权授权；通过推荐确保数据最新的方法；以及通过合并在CDS客户端和CDS服务之间建立和维护信任的业务机制。
授权和令牌
CDS客户端供应商/提供商应维护一份经过审查的CDS服务"白名单"或"黑名单"，以及可用于客户端展示的安全链接。
CDS客户端和CDS服务之间的每次交互都由CDS客户端发起，它向使用传输层安全协议保护的CDS服务端点发送服务请求。通过TLS协议，对CDS服务的身份进行认证，并在CDS客户端和CDS服务之间建立一个加密的传输信道。
每次CDS客户端向CDS服务发送一个请求时，该请求必须包括一个授权头，将JWT作为"持有人"令牌。
资源访问需要授权，CDS Hooks要求客户端通过API调用向FHIR服务器提供一个有效的访问令牌。如果CDS客户端希望提供对FHIR资源的直接访问，则CDS客户端会在调用CDS服务之前创建一个访问令牌，并将此令牌作为服务调用的一部分传递给CDS服务。这种方法仍然与OAuth2.0的承载令牌协议兼容，同时最小化HTTPS的往返次数和服务调用延迟。
请注意，这是用于每个CDS服务调用，无论是发现调用、单个CDS服务调用，还是与单个服务相关的多个交换机。还要注意，相互TLS可以与JSONweb令牌一起使用，以建立CDS服务对CDS客户端的信任。CDS客户端必须使用其私钥，使用JSON Web签名(rfc7515)标准对JWT进行数字签名。
JWT 签名算法
JSON Web算法(rfc7518)定义了几种用于签名jwt的加密算法，由CDSHooks进行引用，在alg报头字段中表示。在选择签署jwt算法时，CDS客户端不仅应该考虑安全行业中推荐的算法，还应该考虑这些算法在CDS服务中使用的编程语言对其的支持程度。
8.4.3.6 扩展
为了支持扩展，该规范保留了名称扩展，从而允许自定义行为和信息。扩展元素的值必须是一个预先协调的JSON对象。
例如，请求的扩展可能是这样的：
{
"hookInstance" : "d1577c69-dfbe-44ad-ba6d-3e05e953b2ea",
"fhirServer" : "http://fhir.example.org:9080",
"hook" : "patient-view",
"context" : {
"userId" : "Practitioner/example"
},
"extension" : {
"com.example.timestamp": "2017-11-27T22:13:25Z",
"myextension-practitionerspecialty" : "gastroenterology"
}}
8.4.3.7 触发事件（钩子）的成熟度及版本管理
作为一种规范，CDS hooks并没有为实现者规定一个默认的或必需的钩子集。相反，这里定义的一组触发事件只是用于帮助CDS hooks创建的一组常用用例。这里定义的触发事件集不是一个封闭的集；任何人都能够定义新的触发事件来适应它们的用例。
触发事件成熟度
| 成熟度水平编码 | 成熟度水平 | 描述 |
|---|---|---|
| 0 | 草稿级 | 符合触发事件的定义格式 |
| 1 | 已提交 | 在0的基础上，使用模板编写的github拉取请求，并在zulip CDS钩流上请求了社区反馈 |
| 2 | 测试 | 在1的基础上，该触发事件已经过测过，能支持模拟数据和场景上的至少一个CDS客户端和至少两个CDS服务之间的互操作性。定义该触发事件的GitHub拉取请求已由CDS hooks项目管理委员会批准、发布。 |
| 3 | 考虑 | 在2的基础上，至少有3个不同的组织记录了10个不同的实现者注释，涵盖至少两个CDS客户端和三个独立的CDS服务。触发事件在两个连接器上进行了测试。 |
| 4 | 已记录 | 在3的基础上，创造者认为触发事件已经比较稳定，已在多个原型项目中实现。触发事件已确定一组广泛的上下文示例，能将该触发事件与其它标准区分开来，以帮助实施者确定该触发事件是否适合他们想要的场景。文档中明确指出不应该使用该触发事件的示例场景。 |
| 5 | 成熟 | 在4的基础上，该触发事件已经在至少两个CDS客户端和三个独立的CDS服务中实现。HL7工作组投票通过，HL7 STU投票通过。 |
| 6 | 规范级 | 在5的基础上，HL7工作组和CDS工作组同意相关材料已可锁定，触发事件通过HL7规范投票。 |
触发事件（钩子）版本管理
每个触发事件必须在触发事件的开头包含一个元数据表，其中包含规范版本和触发事件版本。
因为触发事件是CDS hooks规范的一个组成部分，所以触发事件定义与规范的特定版本相关联。触发事件定义必须包括其定义为要使用的CDS hooks规范的版本。
specificationVersion | 1.0
要启用对触发事件定义更改的跟踪，每个触发事件必须包含一个以字符串表示的版本指示符
hookVersion | 1.0
| 变更 | 版本影响 |
|---|---|
| 对不影响功能的文档的澄清和更正 | 补丁 |
| 更改现有上下文字段的预取令牌状态 | 主要的 |
| 向上下文中添加一个新的必需字段 | 主要的 |
| 向上下文中添加一个新的可选字段 | 小版本 |
| 更改现有上下文字段的可选择性 | 主要的 |
| 更改现有上下文字段的类型或基数 | 主要的 |
| 删除一个现有的上下文字段 | 主要的 |
| 更改现有上下文字段的语义 | 主要的 |
| 触发事件的语义上的变化 | 主要的 |
当发生重大更改时，挂钩定义必须以一个新的名称发布。当进行了轻微更改或补丁更改时，必须更新触发事件版本。
8.4.4 实际应用情况
中山市人民医院在尝试落地CDS Hooks标准时，实际改造涵盖了VTE静脉血栓防治管系统、CDSS临床辅助决策支持系统、病历质控系统、病案质控系统。
中山市人民医院的医院借鉴CDS hooks规范，首先解决数据交换标准问题。各系统均改用CDS hooks和FHIR资源，解决服务发现与调用、数据资源访问的互操作性。其次解决医生端提醒展示界面统一的问题。
方案框架如下图：
当CDS需要其他交互时，启动面向用户的SMART应用。
以CDS医嘱选择为例。
本交易由CDS客户端和CDS服务端使用。 调用地址：
POST {baseUrl}/cds-services/{service.id}
请求消息
CDS客户端触发调用医嘱选择服务时context属性如下：
| 字段 | 可选性 | 预取令牌 | 类型 | 描述 |
|---|---|---|---|---|
| userId | 必须 | 是 | string | 当前用户的id。对于这个触发事件，用户应该是 Practitioner 类型。例如 Practitioner/123。 |
| patientId | 必须 | 是 | string | 上下文中当前患者的 FHIR Patient.id。 |
| encounterId | 可选 | 是 | string | 上下文中当前就诊的 FHIR Encounter.id |
| selections | 必须 | 否 | array | 新选择的医嘱的 FHIR id。 selections 字段引用了 DraftOrders Bundle 中的 FHIR 资源。 例如，MedicationRequest/103。 |
| draftOrders | 必须 | 否 | object | 资源MedicationRequest, NutritionOrder, ServiceRequest, VisionPrescription组成的Bundle |
响应消息
返回一组cards对象组成的数组。 每一个Card应该包含下列属性。
| 字段 | 可选性 | 类型 | 描述 |
|---|---|---|---|
| uuid | O | string | 卡的唯一标识符。可用于审核和记录卡，并应包含在对 CDS 服务的反馈端点的任何后续调用中。 |
| summary | R | string | 一个句子，少于140个字符的摘要消息，用于在此卡片内向用户显示。 |
| detail | O | string | 可选的详细信息显示；如果提供，则必须以（GitHub 风格）简化表示。（对于非紧急卡片，CDS 客户端可以隐藏这些详细信息，直到用户单击"查看更多详细信息…"等链接）。 |
| indicator | R | string | 这张卡片传达的内容的紧迫性/重要性。 允许的值按紧急程度的增加顺序为：info、warning、critical。 CDS 客户端可以使用此字段来帮助做出 UI 显示决策，例如排序顺序或着色。 |
| source | R | object | 此卡片上显示的信息来源的分组结构。 来源应该是卡片所代表的决策支持的主要指导来源。 |
| … |
…
响应消息返回恰当的HTTP状态代码。
如果执行成功，返回200 OK状态码。
如果执行失败，则应返回4xx和5xx HTTP错误代码。
返回412，先决条件失败，原因是"CDS 服务无法通过预取请求或直接调用 FHIR 服务器检索必要的 FHIR 数据来执行其决策支持"。
交互的通信协议采用JSON，调用方式为HTTP，消息编码UTF-8。
| 元素路径 | 属性 | 约束 | 字段说明与描述 | 元素路径 | 提示 |
| Patient.id | value | 1..1 | id | 患者标识 | guid |
| Patient.implicitRules | url | 1..1 | uri | 事件标识 | HZXXXZ|HZXXXG |
| Patient.identifier | 0..* | Identifier | 患者标识定义 | ||
| Patient.identifier.use | value | 0..1 | code | 标识符的使用类型 | usual | official | temp | secondary | old |
| Patient.identifier.type | 0..1 | CodeableConcept | 患者标识符描述 | ||
| Patient.identifier.type.coding | 0..* | Coding | 患者标识符编码 | ||
| Patient.identifier.type.coding.system | url | 0..1 | uri | 标识的编码系统 | http://hl7.org/fhir/v2/0203 |
| Patient.identifier.type.coding.code | value | 0..1 | code | 标识的代码 | MZH|ZYH |
| Patient.identifier.system | value | 0..1 | uri | 标识的系统 | id/patientno |
| Patient.identifier.value | value | 0..1 | string | 标识的值 | 编号值,source_patient_no |
| Patient.active | value | 1..1 | boolean | 患者信息是否有效 | true|false 是|否 启用|停用 |
| Patient.name | 0..* | HumanName | 患者姓名 | ||
| Patient.name.use | value | 0..1 | code | 患者姓名的使用类型 | usual | official | temp | nickname | anonymous | old | maiden |
| Patient.name.text | value | 0..1 | string | 患者姓名的文本 | patient_name |
成功应答样例：
{
"resourceType": "OperationOutcome",
"id": "355c0c6c-94dd-419c-946a-152576c3741e",
"identifier": {
"system": "http://www.synyi.com/",
"value": "10acde0e-8b22-43fd-ba68-20760cc8024e"
},
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "成功！"
}
]
}
失败应答样例
{
"resourceType": "OperationOutcome",
"id": "c39f7a0f-50d0-4042-b5bf-323923e46dc7",
"identifier": {
"system": "http://www.synyi.com/",
"value": "10acde0e-8b22-43fd-ba68-20760cc8024e"
},
"issue": [
{
"severity": "error",
"code": "not-found",
"diagnostics": "失败详细原因"
}
]
}
临床知识调阅和事中质控类规则均会用到大量术语，字典和术语的统一映射管理使用MDM主数据管理工具实现，该工具支持自动映射，也支持手工映射调整。多个系统的主数据存在不一致的情况，为此，我们采用了人工智能匹配的技术（Map-Concept），将概念意义相同的术语表示形式（Designation），归一到同一个概念Concept上。这项工作并不是在一个项目上完成的，而是得益于多年的代码系统、概念归一的积累。
交互界面由外挂式改为嵌入一体式，并规定提醒、阻断、警告等消息样式，以及引用等跳转链接样式。
原有的多个外挂式：
现在的嵌入一体式：
用户界面最上半部分展示警告消息、提醒消息，消息多时可以折叠，支持查阅历史消息。用户界面下半部分展示各类推荐，跳转链接用文字+下划线标识，点击则可跳转至引用界面。
CDS服务、CDS客户端接口调用均各自改造完成后，进行整体联调，以验证CDS服务是否可同时支持多个CDS客户端正确调用、正确展示。先在试点科室的几台电脑上进行灰度升级，试点过程中，关注一线用户的反馈。根据试点科室需求进行产品优化升级后，逐步开始全院升级、推广。CDS改造实施过程，需要信息科协同CDS、VTE、合理用药、集成平台与数据中心等项目组通力配合，信息科负责管理协调，统筹方案，各项目按讨论评审通过的方案制定细化方案，明确改造计划和对口负责人员。对于改造过程中出现的需求、问题，信息科统一记录，明确每条问题的责任人、跟踪人，保障按时解决。
通过采用FHIR资源、CDS hooks，本院的CDS临床辅助决策类插件做到了用户展示界面统一、CDS服务统一，CDS客户端可增可减。实际使用中，CDS用户展示界面有效集成了辅助决策相关的预警、提示、跳转类的消息，临床医护体验大大提升。
不过，在实践过程中，我们也发现了一些新的有待思考的问题，例如临床医生、护士接收的消息远不止辅助决策类，而且消息推送也不能止步于PC端，还需要考虑手机端、PAD端等多终端推送。而CDS是否能够成为临床PC端的消息集中展示，也有待进一步探讨。
此外，不同承建商推送的CDS预警、辅助提示等，依然会存在相互重复的个例。例如临床辅助决策支持系统已提示“ ** 患者肾功能不全，推荐进行水化治疗”，而合理用药系统也会出现相同的提示。对于临床医护来讲，重复的信息并不能有效过滤。处理重复提示的问题，可能涉及到来自不同知识库的知识规则的统一编码。
总而言之，CDS hooks标准的应用让我们受益匪浅，非常期待未来数据交换标准的逐步规范和有效推广使用，在院间、院外甚至省外得到更广泛的认同和应用，共同推动医疗信息的安全、高效交互与共享。