1. 面向临床决策中台的统一信息模型构建
国内外专家对CDSS类型及应用场景进行了分析，曾指出“用户目的不同、场景不同，CDSS的驱动方式也会不一样，没有必要也不可能规范和统一”。CDSS各交互环节可能匹配多种驱动方式，本方案通过建立通用CDSS交互模型，划分各环节节点，以配置各环节执行标准。
为建立临床系统人机交互数据模型，以某三级综合医院医生站系统工作流为基础，整理出了146项系统交互点。通过对以上交互点工作流的分析，划分出过程模型中的4项主体数据模块：①知识触发，描述应用系统操作如项目、动作、报告等是否有相关知识注册，将应用动作转换为知识库类型；②知识目录，知识的总目录记录知识通用标识；③规则条件，知识返回结果的判断逻辑；④结果交互，通过规则条件得到结果后，取出返回数据，进行交互处理。面向临床决策中台的统一信息模型见图1。
以上过程模型适用于HIS交互通用场景，其中知识触发、规则条件、结果交互环节均可有多种标准适配，知识目录中可配置当前知识应用的对应形式。配置示例（知识触发、知识目录、规则条件、结果交互）如下。
（1）限制性别项目：
项目性别管控－启用－医嘱开立－表达式－消息交互－维护人；项目限制性别=患者信息.性别；False- 当前项目性别条件不符，无法开立－样式0－管控。
（2）医保药品：
提前开药管控－启用－医嘱开立－表达式－消息交互－维护人；项目医保等级!= '丙' and !是皮试项目 and !是模糊剂量项目 and !是中药 and 提前开药天数> 药品设定天数；True- 提前开药天数不符合医保规定。上次（或前两次，累积开药检核）开立时间为*，共开具*天。该药品最早开具日期为*-样式2-管控"。
本方案将临床决策中台划分为5个层级，从下至上依次为平台层、知识层、规则层、策略层和应用层，见图2。平台层负责处理中台内部管理，如权限管理、知识维护逻辑、数据监测等；知识层包括基础知识的收集存储；规则层为知识的组织规则以及知识的返回结果；策略层处理应用中的具体业务规则对照；应用层支持具体的应用服务。
图2 临床决策中台架构
本方案所述中台与HIS的医生工作站、护理工作站、检查、检验、病历编辑等系统交互密切，设计上要考虑方便与第三方系统整合，所以本系统数据交互层面采用面向服务的架构（SOA），处理决策支持临床数据集和医疗信息管理知识数据集等底层数据集；应用层面采用C# 编程语言开发临床辅助决策服务、知识管理服务、临床指南信息辅助服务，实现临床决策触发、规则引擎、结果交互及决策支持管理。
（1）知识触发。
知识触发模块的入口为某种操作，如医嘱项目的开立、提交等，出口为相关联的知识标识集合。本模块设立知识群组，具体的操作项目通过群组与知识对应。
（2）知识目录。
知识目录模块的入口为相关联的知识标识集合，出口为包含具体知识属性的知识集合。知识属性包括启用时机、规则类型、返回类型、建议方式、优先级分数、附加信息等。
（3）规则条件。
规则条件模块的入口为单项知识属性及规则判断依赖数据，出口为规则引擎运算结果。本模块运用运算层级和运算符组织知识规则元素，从而表达知识的应用规则，其中定义了规则的运算层级、层级间的规则关系、层级内序号、层级内规则关系、规则元素、规则元素参数以及操作符和操作值。
（4）结果交互。
结果交互模块的入口为单项知识属性和规则引擎运算结果，出口为相应返回类型的返回结果。每个知识 ID 对应多个可能的规则引擎运算结果，每个运算结果对应一种返回消息，每种返回消息可定义消息主题、提示内容、提示框样式、提示框大小、提示框位置、管控级别、提示类别等。
（5）元素维护。
中台逻辑元素支持规则条件模块的逻辑判断和结果交互模块的提示信息配置。知识元素属性包括所属分类、元素名称、元素组别、是否依赖数据、是否依赖参数、状态等。本模块支持配置元素依赖数据，定义每个知识元素调用依赖的数据类型和数据细项，用于外部系统调用知识时，获取需要传入的参数。逻辑元素的来源不限于系统内部或唯一标准，可灵活扩充，在当前CDSS知识分散的现状下，可以是一种变通的方式。本研究所述临床决策中台即应用逻辑元素来构建。充分利用其聚集性和复用性，可提高临床需求完成效率，降低需求修改复杂度，通过逻辑元素的积累，后期可做到一般需求通过简单的系统配置即可实现且功能灵活。
（6）元素入参维护。
患者数据的通用接口是提高系统开发效率，降低应用成本，提升知识库质量的重要内容之一。知识元素是本研究所述CDSS逻辑实现的基础，通过知识目录可获取当前知识逻辑判断所需知识元素，进一步通过配置知识元素的依赖数据，可以建立起电子病历系统与知识库之间数据的桥梁。
临床决策中台的服务对象为医院管理者、医生、药师、护士、技师、患者等。以最常见的医生开医嘱过程为例，临床决策中台根据患者基本信息，调阅患者历史病案、健康档案信息，对过往诊断、过敏史、药品、检验、检查等医嘱进行主动式检查，针对用药频率、给药途径、用法、用量、禁忌证、适应证、相互作用等给出预警提示，用户通过点击处理意见，显示是否符合临床决策要求，符合要求的继续进行操作，不符合要求的则终止操作或按照建议改变操作。其应用流程见图3，流程说明如下：
②通过知识触发模块判断是否存在知识。情况分为两种：如果存在，通过知识目录获取相关知识数据；如果不存在则直接调用结束，系统不会提示任何知识提醒。
③知识目录信息中配置了当前知识的判断参数、规则类型以及结果类型。通过参数类型获取知识判断依赖数据，指向知识依赖数据模块；通过规则类型来判断当前知识所应用的规则种类，指向规则条件模块；通过结果类型判定当前知识的结果返回方式，指向结果交互模块。
④通过知识依赖数据模块获取参数，通过决策规则表获取决策规则以后就开始调用决策支持引擎，根据引擎返回值返回决策结果。
⑤最后，通过检测管理模块将用户选择的结果记录成详细的反馈信息，整个医嘱调用的流程结束。
图3 临床决策中台应用流程
本系统已在院内55个临床科室部署应用，中台应用示例见图4，累计为医生、患者提供相关服务100万余次，效果较好。目前系统实施重点在提醒警告方向，相关逻辑判断主要为表达式逻辑，要使本系统满足全面的应用场景，还需要整合各种形式的逻辑判断、数据返回模式。
以知识的逻辑判断环节为例，本研究整理了院内近6年医生站系统的532项逻辑判断需求进行分析，以上需求包括各类型患者数据的合理性校验及警示，治疗方案建议等。通过对以上需求的规则条件进行梳理归纳，得出了知识元素复用率高，临床70%的需求可通过对高频知识元素的重新组合来实现的结论，高频知识元素如“是某类型特殊项目”元素复用次数高达188次，“获取某检验指标的值”元素复用次数达60次。
图4 临床决策中台应用示例
