4. CDSS数据架构与临床数据模型
临床决策支持系统（CDSS）的推理质量，首先取决于它能否把散落在不同业务系统中的临床事实，还原成一条可追溯、可计算、可解释的患者时间线。数据架构要解决的核心问题不是“把数据集中起来”，而是“让同一临床事实在不同粒度上保持一致语义”。本节从电子病历、医嘱、检验、影像、护理记录五类数据出发，说明其结构差异，再讨论 HL7/FHIR 资源模型、OMOP CDM、数据分层与主数据管理，最终落到患者纵向视图的构建方法。
一、五类临床数据的结构差异
电子病历（EMR）文档以“病历文书”为单位，结构最弱，通常由入院记录、病程记录、手术记录、出院小结等组成，正文是自由文本，只有标题、作者、时间、科室等少量结构化字段。医嘱（CPOE）是典型的“事件—明细”结构：一条医嘱包含患者、开立时间、开立医生、医嘱类型（长期/临时）、药品或项目名称、剂量、频次、途径、起止时间，以及执行状态（开立、审核、执行、停止、作废）。检验数据是“申请—标本—结果”三层结构：检验申请单对应一组项目，标本有采集时间与类型，结果项包含项目代码、结果值、单位、参考区间、异常标志（高/低/危急）。影像数据由检查申请、检查报告、影像序列三部分组成，报告含所见与结论，序列则以 DICOM 标签描述层厚、序列号、设备等。护理记录是高频、结构化的“评估—措施—观察”记录，如生命体征、出入量、跌倒评分、压疮评分，时间粒度常为小时级。
这五类数据的差异决定了 CDSS 不能只建一张宽表。医嘱和检验是强结构化事件，适合直接映射为事实表；病历文书需要先做实体抽取；影像报告需要结构化结论字段；护理记录则要按时间序列建模。
二、HL7/FHIR 资源模型：以资源为中心的表达
FHIR 把临床数据拆成可独立寻址的资源，每个资源有唯一 id、版本、引用关系。与 CDSS 最相关的资源包括：Patient（患者）、Encounter（就诊）、Condition（诊断/问题）、Observation（观察，含检验结果与生命体征）、MedicationRequest（用药医嘱）、MedicationAdministration（用药执行）、Procedure（操作）、DiagnosticReport（诊断报告）、ImagingStudy（影像检查）、DocumentReference（文书引用）、CarePlan（照护计划）。资源之间通过 reference 连接，例如 Observation.subject 指向 Patient，Observation.encounter 指向 Encounter，DiagnosticReport.result 指向一组 Observation。
FHIR 的价值在于“按需组装”：CDSS 不必一次性拉取全部病历，而是按患者 id 和时间范围查询所需资源。例如查询某患者近 7 天血钾：GET /Observation?patient=123&code=2823-3&date=ge2024-06-01。返回的每个 Observation 含 valueQuantity、interpretation、referenceRange，可直接参与规则判断。需要注意的是，FHIR 是交换与接口标准，不是分析型存储模型；高频查询仍需落到本地库或分析库。
三、OMOP CDM：面向分析与研究的公共数据模型
OMOP CDM 把临床数据规范为以 person 为中心、以标准概念（Concept）为语义锚点的关系模型。核心表包括：PERSON（患者）、VISIT_OCCURRENCE（就诊）、CONDITION_OCCURRENCE（诊断）、DRUG_EXPOSURE（用药暴露）、MEASUREMENT（检验/测量）、OBSERVATION（观察）、PROCEDURE_OCCURRENCE（操作）、NOTE（文本记录）。所有临床事件通过 concept_id 关联到标准词表，源系统的本地编码先映射到标准概念，再进入 CDM。
OMOP 的优势是跨机构可比、便于队列筛选与统计建模。例如筛选“年龄≥65 岁、有 2 型糖尿病、近 1 年使用二甲双胍、eGFR<45”的患者队列，可直接在 MEASUREMENT 与 DRUG_EXPOSURE 上做连接查询。其代价是映射工作量大，且对实时性要求高的 CDSS 场景需要额外同步机制。
四、数据分层与主数据管理
推荐采用四层数据架构：贴源层保留各业务系统原始结构与增量日志；整合层完成患者主索引（EMPI）匹配、术语映射、时间对齐，形成以患者为中心的标准化事件；服务层按 FHIR 资源或宽表形式对外提供查询；应用层承载规则引擎、风险评分与纵向视图。主数据管理重点解决三类问题：患者主索引（跨系统同一患者合并）、术语主数据（检验项目、药品、诊断编码的统一）、机构与人员主数据（科室、医生、病区）。
五、构建患者纵向视图
患者纵向视图的本质，是把同一患者在不同系统中的事件，按临床时间轴对齐后形成统一序列。构建过程分四步。第一步，以 EMPI 确定患者唯一标识，把各系统患者 id 映射到同一主索引。第二步，统一时间语义：检验用采集时间，医嘱用开立时间与执行时间，护理记录用观察时间，影像用检查时间，文书用书写时间。第三步，把事件规范为统一结构，至少包含：事件类型、事件编码、事件名称、发生时间、数值/文本、单位、异常标志、来源系统。第四步，按时间排序并分层展示，例如把“用药—检验—生命体征”放在同一时间轴上，便于识别因果与趋势。
一个可用的纵向视图示例：患者 65 岁，因“发热、咳嗽 3 天”入院。时间轴上依次出现：入院记录（文书）、血常规 WBC 12.3×10⁹/L（检验，高）、胸部 CT 提示右下肺感染（影像）、莫西沙星 0.4g qd 静滴（医嘱）、体温 38.9℃（护理）。当规则引擎检测到“eGFR 42 mL/min/1.73m² + 莫西沙星”时，可提示调整剂量。若没有纵向视图，这些事实分散在四个系统中，规则很难在正确时间点触发。
六、架构落地要点
第一，FHIR 与 OMOP 不是二选一。FHIR 适合实时接口与资源查询，OMOP 适合离线分析与队列研究，两者可通过 ETL 互为补充。第二，术语映射要建立版本管理，检验项目、药品、诊断编码的映射表需记录生效时间与来源，避免历史数据被新映射覆盖。第三，纵向视图的查询性能依赖时间分区与患者分区，建议按 patient_id 哈希分桶、按事件时间分区。第四，所有进入 CDSS 的数据必须保留来源系统与原始记录 id，保证告警可回溯、可解释。第五，主数据变更要有审批与回滚机制，尤其是患者合并操作，一旦误合并会导致两个患者的临床事实混在一起，后果严重。
综上，CDSS 数据架构的关键在于：用 FHIR 解决“怎么取”，用 OMOP 解决“怎么算”，用分层架构解决“怎么管”，用纵向视图解决“怎么用”。四者配合，才能让决策支持建立在完整、一致、可追溯的患者事实上。