ARTICLE · 1270908
一文看懂《电子病历版式文档技术要求》正式版
标准观察 · 深度科普
一文看懂OFD-H 电子病历文档技术要求正式版
从“系统内可用”到“跨系统可读、可用、可验证”
核心问题一份电子病历离开原来的HIS、EMR或PACS后,能否仍被准确阅读、独立验证,并长期保存? |
医疗信息系统每天产生大量病历、检查检验报告、知情同意书和医学影像。然而,文件格式不统一、签名难以独立验证、医学影像关联缺失、结构化数据难以交换,仍是跨机构利用中的现实障碍。
2026年9月28日,GB/T 48666—2026《电子病历版式文档技术要求》正式发布。根据国家标准信息公共服务平台,其实施日期为2027年4月1日。标准以OFD为基础,面向医疗场景进一步规定文档格式、资源、机读信息、签名、安全及软件功能。
01OFD-H究竟是什么?
OFD是一种开放式版式文档格式,解决文件如何稳定呈现和保存的问题;OFD-H则在OFD技术基础上增加医疗行业要求,帮助病历文书同时获得稳定版式、医疗关联信息和可信验证能力。
重要的是,OFD-H不是一套新的HIS、EMR或PACS,也不要求医院将既有系统整体推倒重建。其主要对象是能够独立保存、交付和交换的电子病历版式文件。
02变化一:以文件为纽带,减少既有系统改造
正式版第5章强调,应用时应秉持不改变或较少改变现有业务系统的原则。医疗机构既可以由业务系统自行生成OFD-H,也可以通过机构内文件系统代理生成、处理和委托签署。

图1医院现有业务系统与统一文件处理能力的关系(作者绘制的概念示意)
例如,已运行多年的LIS继续输出既有报告格式,医院通过统一转换服务生成OFD-H,再进行适用的签署与归档。标准强调的是文件交付能力,而不是要求所有厂商采用同一种业务软件。
03变化二:一份报告同时服务人和机器
OFD-H不仅要求文件能够正确显示,也允许通过自定义标引和附件等机制关联结构化医疗数据。正式版第7.5条进一步明确,机读信息采用XML、JSON等半结构化文本形式,支持GB 18030规定的字符并使用UTF-8编码。

图2人读页面与机读数据应保持一致;示例字段不构成标准指定的JSON Schema
以检验报告为例,页面显示血红蛋白135 g/L,机读数据也应表达相同结果。否则,医生看到的报告与其他系统消费的数据可能产生矛盾。
需要澄清标准并没有规定每份OFD-H都必须携带JSON。即使存在JSON,不同医院的字段名称、编码和单位也不会自动统一;医疗数据语义仍需依赖相应的行业规范。 |
04变化三:医学影像和音视频关联更灵活
医疗病历不只有文字。CT、MRI、超声视频、内镜录像及三维模型等资料可能体积大、格式复杂,往往还依赖专业影像软件。正式版第7.2、7.4条明确了资源嵌入与外部附件两种组织方式。

图3医学影像资源与外部附件的推荐选择逻辑;512MB只是可参考的限定值
医疗机构可以根据存储策略设置数据对象容量界限。数据较小且符合适用组织规则时,可以考虑内嵌;较大或需要专业软件浏览时,可以通过外部附件关联。采用外部附件并不等于阅读器天然拥有PACS权限。
另外,将DICOM转换为普通图像时,应在符合隐私与脱敏要求的前提下,保留患者标识、检查时间、检查部位等必要的诊疗关联信息。关键不仅是“留下一张图片”,还有“知道它属于哪次检查”。
05变化四:历史扫描病历既要保留原貌,也要可检索
纸质历史病历经扫描后,仅保存影像往往只能看、难以准确搜索。OFD-H进一步明确双层版式文档:可见影像层呈现纸张原貌;不可见OCR文字层用于选择、检索和复制,并与影像文字位置保持一致。

图4双层病历的两层数据分工;文字层不可见,但应正确对应影像位置
OCR不是把识别结果随便附在图片后面,更不是让页面上重复出现两套文字。对于历史病案数字化,视觉保真和文字位置准确性需要分别验证。
06变化五:数字签名要保护内容,还要支持独立验证
电子病历可能承担医疗质量管理与司法举证等作用。OFD-H要求采用适用的密码规范,在使用数字签名或电子签章时保护规定范围内的病历内容。验证不能依赖特定医疗业务软件或系统。
这意味着不能仅在页面上放一张印章图片,也不能只看SM2接口是否返回成功。还要确认版面描述、相关资源和应受保护的机读内容是否被签名引用,独立工具能否完成验证。

图5签名后的合法加注与追加签署逻辑;具体保护范围应按OFD签名结构验证
文件签署后,不得直接修改已有签名保护的内容。需要留痕的加注或修改应按适用规则重新签名或追加签名;标准同时推荐符合相关规范的时间戳。这并不等于要求每次阅读操作都重新签署。
07变化六:从单份文件转向组合、文档集和长期追溯
正式版对文档组合和文档集的应用更为清晰。文档组合是将多个文档内容合并成一个新文档,原签名可能无法继续验证,需要处理原签名并重新签署组合结果。文档集则可保留多个独立文件及其签署关系。

图6文档组合与文档集是不同层次的交换组织方式,不可混淆
当需要以版本方式记录内容或注释变化时,应保留历史版本完整内容,或按规定保存历史修改内容。长期档案保存还应关注资源完整性、加密文件归档前处理和后续可读性。
08正式版对软件提出了什么要求?
生成软件(第9.1条) | 阅读软件(第9.2条) |
从数据生成OFD、将多种格式文件转换为OFD | 版式还原、签章验证、权限控制 |
具备按GB/T 42133处理OFD的文件加工能力 | 注释定位、元数据展示、格式检查及未处理项提示 |
生成、转换、加工均须遵循适用标准要求 | OFD-H打开后自动禁用文档编辑;外部附件打开为推荐能力 |
需要以真实OFD-H样本验证质量 | 面向可信阅览和合规审计,并满足第三方验证要求 |
第三方验证的意义,是避免“自家生成、自家阅读器能打开”就直接等同于标准合规。独立实现的格式检查、验签和测试证据,对跨医院交换尤其重要。
09医院该如何推进?
GB/T 48666—2026为推荐性国家标准,不能仅凭其发布就推断所有医院必须立即停用PDF、整体替换EMR或把全部历史病历转换为OFD-H。更现实的方式是分场景建设与验证。

图7建议的医院OFD-H实施步骤(方法建议,不是标准规定的统一实施计划)
优先选择出院记录、患者知情同意、检验报告、影像报告和历史病历等代表性文件,分别验证视觉保真、机读信息、附件链接、签名保护和第三方兼容性。
10真正值得关注的,不只是另一种文件格式
医疗信息化已经积累了丰富数据,但这些数据往往只能在原系统内部顺畅使用。OFD-H的价值,在于为跨系统文件交付建立更稳定的技术契约:一份病历即使离开原EMR,仍可以被正确阅读,按规定提取数据,并在具备必要信任资料的情况下独立验证。
核心结论医疗数字化的下一步,不只是把病历变成电子文件,而是让电子病历离开原系统后,依然可读、可用、可验证。 |
标准来源与使用说明
标准依据:国家标准信息公共服务平台GB/T 48666—2026;市场监管总局2026年9月30日发布信息;GB/T 48666—2026正式文本。
日期说明:标准信息平台与正式文本标注2027年4月1日实施,部分新闻稿写为4月29日,本文采用标准目录日期。所有图示均为原创技术示意、并非标准原图;具体合规判断以正式文本为准。
配套资料与交流
本文配套的 22 页 PPT 已整理为在线阅读资料。点击文章底部「阅读原文」,即可逐页查看并下载原版演示文稿;页面同时提供正式版标准资料领取及配套标准官方获取入口。
欢迎关注「康小乔」,继续交流电子病历生成、签署、阅读与归档场景。也可在 OFD.chat 提交需求或订阅 RSS 产品动态。















































































