电子健康档案共享:互操作性指南

国家卫生健康委员会与国家网信办（CAC）发布的《互联网诊疗监管细则》要求医疗机构建立患者数据共享机制，同时须符合《个人信息保护法》（PIPL）对敏感个人信息处理的规定。跨系统共享电子健康档案，意味着协调至少四项标准：用于API式交换的HL7 FHIR R4、用于文档式传输的C-CDA R2.1、用于遗留消息传递的HL7 v2.x，以及用于影像的DICOM。USCDI v3定义了美国医疗提供者须开放共享的最低数据集，TEFCA通过合格健康信息网络（QHIN）建立治理层。当记录在Epic与Cerner/Oracle Health之间流动时，通常经由Carequality框架将C-CDA文档封装在IHE XCA规范中传输；当记录流向患者的手机应用时，则通过SMART on FHIR加OAuth 2.0实现。

你实际使用的标准技术栈

健康档案互操作性看起来像标准大杂烩，因为它确实如此。各层功能划分：

HL7 v2.x：1990年代的管道分隔符消息格式，仍是医院内部检验单、ADT（入院/出院/转院）推送和医嘱管理的主力军，不适合跨机构共享
C-CDA R2.1：代表患者摘要、出院小结或转诊记录的结构化XML文档，是Direct消息传递和大多数HIE交换的骨干
HL7 FHIR R4：以JSON或XML通过HTTPS交换的RESTful资源（Patient、Observation、Condition、MedicationRequest），是ONC《治愈法案》规则要求认证电子健康档案必须支持的现代层
DICOM：影像标准，通过自有管道（DIMSE、DICOMweb）传输
USCDI v3：每个认证电子健康档案必须开放的数据类别和元素要求，包括临床笔记、社会决定因素及性别认同

当你"共享电子健康档案"时，实际上是从每一层提取片段，拼接成接收方所需的正确格式。

FHIR API与信息封锁规则

ONC的《21世纪治愈法案》最终规则（45 CFR Part 171）将信息封锁列为自2020年5月起禁止的行为，2023年HHS最终规则规定对特定主体每次违规最高处以100万美元罚款。技术要求：认证电子健康档案技术必须公开支持USCDI数据集的FHIR R4 API。

开发者接入Epic、Cerner、athenahealth或eClinicalWorks的步骤：

在供应商开发者门户注册应用（Epic on FHIR、Cerner Code、athenahealth开发者门户）
使用带PKCE的SMART on FHIR启动序列和OAuth 2.0
申请patient/*.read或特定资源权限范围
通过HTTPS接收JSON包

实际陷阱：API权限范围、速率限制和生产访问要求在供应商之间差异极大。Epic的生产访问需要签署付款方-提供者或专项应用协议；Cerner的沙盒访问更快，但认证流程不同。

C-CDA：跨机构摘要的默认格式

尽管FHIR持续崛起，大多数跨机构记录交换仍以C-CDA文档形式传输。C-CDA R2.1下的连续护理文档（CCD）通常为200 KB至2 MB的XML文件，内嵌供人阅读的HTML。核心模板：

CCD（连续护理文档）
出院小结
转诊记录
会诊记录
进展记录

这些文件通过Direct消息传递（S/MIME over SMTP）或查询式HIE交换传输。接收方电子健康档案解析XML并将结构化元素导入本地记录。解析质量参差不齐——部分系统能正确导入问题列表，但丢失社会史。数据对账在大多数诊所仍是手动步骤。

TEFCA、QHIN与全国网络策略

可信交换框架与通用协议（TEFCA）于2022年1月由ONC定稿，2023年起运营，构建了网络之网络。eHealth Exchange、Epic的Carequality桥接、Health Gorilla等QHIN通过通用协议相互连接。

从发送方临床医生的角度，TEFCA意味着：查询一次，触达所有QHIN参与者，适用于治疗、账单、医疗卫生运营、公共卫生、政府福利认定、个人访问服务和保障使用场景。

从IT主管的角度，TEFCA意味着叠加在现有IHE规范之上的治理层，而非需要重新实施的新协议。

API失效时需要文件传输的场景

尽管标准完备，临床医生仍频繁遇到不符合任何API的文件传输需求。例如：

诊所电子化前扫描的纸质记录，打包为300 MB的PDF
SAS或Stata格式的回顾性科研数据集
不需要占用影像服务器的家庭医疗伤口照片
待决医疗事故案件的法律证据保全记录

这些场景需要回归加密文件传输。要求：合规（签署BAA）、静态 AES-256-GCM 加密、TLS 1.3 传输、审计日志记录、链接到期功能。具体工具是Epic内置功能、医院批准的企业服务，还是临时浏览器传输，取决于你的治理框架。

HexaTransfer提供上传前客户端加密的临时传输方案。立即访问 https://hexatransfer.com 免费体验——无需注册，最大支持10 GB。将传输记录在标准审计记录中，以便日后追溯。

患者匹配与身份问题

共享记录的前提是确认记录属于正确的患者。美国没有全国患者标识符（1998年拨款附加条款每年续期），身份核实依赖姓名、出生日期、性别、地址、电话的概率匹配。Sequoia项目患者匹配框架推荐跨机构匹配至少使用7个人口统计属性。

生产网络的匹配率在70%至95%之间，取决于数据质量。未匹配意味着临床护理时记录缺失，以及重复记录污染下游病历。许多QHIN现已加入第三方数据库的参照匹配以提升准确率。

文件层面传输时，始终在文件名或封面页中包含患者标识符——病历号、出生日期和至少一个附加标识符。不要依赖临床医生凭经验判断"Jane-S-MRI.dcm"属于哪位患者。

同意、数据分割与42 CFR Part 2

并非所有记录共享规则相同。42 CFR Part 2限制来自联邦资助项目的物质滥用障碍记录的共享，其同意要求高于一般HIPAA授权。在2024年SAMHSA规则将Part 2与HIPAA更紧密对齐后，单一患者同意可启用更广泛的共享，但记录仍须携带禁止再披露声明。

行为健康、HIV、基因信息及生育健康记录通常适用特定的州级共享规定。若你的传输工具不能处理数据分割——无法标记文档中哪些部分需要额外同意——不要用它传输心理健康记录，用它传输骨科随访资料包即可。

披露审计与披露会计

HIPAA的披露会计（45 CFR 164.528）赋予患者获取过去6年内披露清单的权利。治疗目的的披露有豁免，但账单、运营和经许可目的的披露仍须追踪。

传输系统的审计日志为这一会计提供依据。需记录：

UTC时间戳
发送和接收机构
目的代码（TREATMENT、PAYMENT、OPERATIONS、AUTHORIZATION等）
传输的数据类别
患者ID

若依赖仅记录"用户X上传了文件Y"的通用文件共享工具，当患者要求披露会计时你将陷入混乱。

小型诊所与资源差距

一个3名医生的基层医疗诊所没有CIO，只有一名兼做IT和账单的诊所管理员。他们仍须按需提供符合USCDI标准的记录、与每个供应商签署BAA、处理信息封锁投诉。实用做法：

使用开箱即支持Direct、FHIR和患者API的电子健康档案（athenahealth、Elation、DrChrono）
为电子健康档案无法发送的内容选择一个具备BAA的临时加密传输工具
在一页SOP中记录工作流
对每位员工培训他们每周会使用的两个工具

电子健康档案共享不是单供应商能解决的问题，而是需要持续维护的分层工作流。在能用标准的地方用好标准，并为标准无法覆盖的场景准备一套干净的加密备选方案。