3. 医疗数据标准总览
跨机构医疗数据交换之所以困难，很大程度上不是因为网络不通，而是因为双方对“同一条数据”的理解不一致。同样是“血糖”，A 院可能叫 GLU，B 院叫 Glucose，C 院用本地代码 1023；同样是“患者”，有的系统存姓名和身份证号，有的只存就诊卡号。医疗数据标准就是用来消除这类歧义的共同约定。但标准并非一个，而是一组分工不同的规范，理解它们的定位与关系，是设计交换方案的第一步。
两类标准：交换格式标准与术语标准
本节涉及的六个标准可以分成两个层次。第一层是交换格式标准，规定数据“怎么装、怎么传”，包括 HL7 v2、HL7 CDA、FHIR 和 DICOM。第二层是术语与编码标准，规定数据“用什么词、什么码来表达含义”，包括 LOINC 和 SNOMED CT。交换格式负责结构，术语标准负责语义，二者缺一不可：只有结构没有术语，字段填进去的值仍然无法互认；只有术语没有结构，编码无处安放。
需要特别强调的是，术语标准不是“可选项”。在实际项目中，最常见的失败模式就是双方都用了 HL7 v2 消息，结构完全对得上，但 OBX 段里的观察项标识一个用 LOINC、一个用院内自定义码，结果数据能收到却无法自动解读，最终仍需人工对照。
HL7 v2：事件驱动的消息交换
HL7 v2 是医院内部集成最广泛的标准，典型场景是 HIS、LIS、RIS、PACS 之间的实时消息传递。它采用“触发事件 + 消息 + 段 + 字段”的结构，例如患者入院触发 ADT^A01，检验结果回报触发 ORU^R01。消息以竖线分隔字段、以段名开头，形如：
MSH|^~\&|HIS|HOSP_A|LIS|HOSP_A|20240512093000||ORU^R01|MSG00001|P|2.5
PID|1||P20240512001^^^HOSP_A^MR||张^三||19800101|M
OBR|1|ORD123|LAB456|CBC^血常规^L
OBX|1|NM|GLU^血糖^L||6.8|mmol/L|3.9-6.1|H|||FHL7 v2 的优点是成熟、轻量、被几乎所有医疗信息系统支持；缺点是版本众多（v2.3、v2.5、v2.7 等）、可选字段多、Z 段（自定义段）泛滥，导致“同一版本不同实现”的互操作问题。它适合院内或区域内的实时消息交换，但不太适合跨机构长期归档和复杂查询。
HL7 CDA：面向文档的临床归档
CDA（Clinical Document Architecture）是 HL7 v3 体系下的文档标准，用于表达一份完整的临床文档，如出院小结、检验报告、影像报告。它的核心特征是“文档性”：有固定的文档头（患者、作者、时间、机构、文档类型），有可选的文档体（结构化或非结构化）。CDA 的文档体通常用 XML 表达，可嵌入叙述性文本，也可用 entry 表达结构化条目。
CDA 适合跨机构交换“一份完整记录”，例如区域健康档案平台、医联体转诊摘要。它的局限是解析复杂、实现成本高，且不同厂商的 CDA 模板差异较大。在工程实践中，CDA 常与 LOINC、SNOMED CT 配合使用，用 LOINC 标识文档类型和检验项目，用 SNOMED CT 表达临床发现。
FHIR：面向资源的现代 API 交换
FHIR（Fast Healthcare Interoperability Resources）是 HL7 近年主推的标准，它把医疗数据拆成一个个“资源”（Resource），如 Patient、Observation、Encounter、MedicationRequest，每个资源有统一的 URL 标识和 JSON/XML 表示，并通过 RESTful API 进行增删改查。例如获取某患者的血糖观察结果，可以请求：
GET [base]/Observation?patient=Patient/123&code=http://loinc.org|2339-0FHIR 的优势是贴近现代 Web 开发习惯、资源粒度细、支持查询与订阅，适合移动医疗、互联网医院、跨机构按需调阅。它并不取代 v2 和 CDA，而是与它们共存：院内实时消息仍可用 v2，归档文档仍可用 CDA，对外 API 和新型应用则用 FHIR。三者之间可以通过映射实现转换，例如把 v2 ORU 消息映射为 FHIR Observation 资源。
DICOM：医学影像的专用标准
DICOM 与上述标准不同，它专门面向医学影像，既规定影像文件格式（像素数据、元数据），也规定网络传输协议（C-STORE、C-FIND、C-MOVE 等）。一张 CT 图像、一份超声报告、一个影像检查序列，都以 DICOM 对象存在。DICOM 的元数据中包含患者信息、检查信息、设备参数等，可与 HL7 消息配合：HL7 负责检查申请和报告状态，DICOM 负责影像本身。
在跨机构影像共享中，常见做法是 PACS 之间通过 DICOM 协议传输影像，同时用 HL7 或 FHIR 传递检查报告和患者索引。DICOM 的挑战在于数据量大、传输慢、隐私保护要求高，通常需要配合影像归档和通信系统（PACS）以及专门的影像共享平台。
LOINC 与 SNOMED CT：语义层的两大支柱
LOINC（Logical Observation Identifiers Names and Codes）主要用于标识“观察项”和“检验项目”，例如血糖、血常规、血压、体温。它的编码是数字加短横线，如 2339-0 表示 Glucose [Mass/volume] in Blood。LOINC 解决的是“这个检验项目到底是什么”的问题，是检验结果互认的基础。
SNOMED CT（Systematized Nomenclature of Medicine — Clinical Terms）是更广泛的临床术语体系，覆盖疾病、症状、操作、解剖部位、药物、微生物等，编码为数字，如 73211009 表示 Diabetes mellitus。SNOMED CT 解决的是“这个临床概念是什么”的问题，适合表达诊断、问题列表、过敏史等。
两者分工明确：LOINC 管“测什么”，SNOMED CT 管“是什么病、什么症状”。在 FHIR 中，Observation.code 通常用 LOINC，Condition.code 通常用 SNOMED CT；在 CDA 中，文档类型用 LOINC，问题条目用 SNOMED CT。实际项目中，医院内部往往还有自己的本地码表，需要建立“本地码—标准码”的映射表，这是术语标准落地的关键工作。
六个标准如何协同：一个检验结果交换的例子
假设 A 院要把一份血糖检验结果发给 B 院。合理的组合是：用 HL7 v2 ORU^R01 消息承载实时传输，OBX 段中观察项标识用 LOINC 2339-0，结果值 6.8 mmol/L，参考范围 3.9–6.1，异常标志 H；如果 B 院需要归档，则把该结果映射为 CDA 检验报告文档，文档类型用 LOINC 11502-2（Laboratory report），条目用 LOINC 2339-0；如果 B 院通过 FHIR API 调阅，则生成 Observation 资源，code 用 LOINC 2339-0，subject 指向 Patient 资源，valueQuantity 为 6.8 mmol/L。若该患者同时有糖尿病诊断，则诊断用 SNOMED CT 73211009 表达在 Condition 资源或 CDA 问题条目中。影像部分则由 DICOM 单独传输，HL7/FHIR 只传检查申请和报告状态。
这个例子说明：六个标准不是竞争关系，而是分层协作关系。交换格式决定“数据长什么样、怎么传”，术语标准决定“数据里的值代表什么含义”。设计跨机构交换方案时，先确定交换场景（实时消息、文档归档、API 调阅、影像传输），再选择对应的格式标准，最后为每个关键字段绑定术语标准，并建立本地码到标准码的映射表。三者缺一，互操作就会在某个环节断裂。