《电子病历版式文档技术要求》正式版对比征求意见稿:6个实施关注点

康小乔｜2026年10月24日

如果你的团队已经按征求意见稿做过 OFD-H 适配，正式版发布后最值得做的事，是重新核对差异，而不是直接沿用“已支持”的结论。

GB/T 48666—2026《电子病历版式文档技术要求》已于2026年9月28日发布，实施日期为2027年4月1日。本文对照公开征求意见稿与正式版，梳理对 HIS、EMR、PACS 集成和文档开发有影响的六个关注点。它是一份工程阅读笔记，不是官方标准解释，也不是产品符合性报告。

先给出判断：OFD-H 的基本路线延续了下来，正式版对资源组织、签名留痕和验证要求作了细化。尤其需要区分“新增要求”和“原有要求变得更明确”。

一、影像放在里面还是外面？新增容量策略，但512 MB不是硬上限

征求意见稿第7.2条对 DICOM 影像倾向采用外部附件或文件链接，并独立于 OFD 存储。正式版第7.2条改为结合关联数据对象的体积，以及医疗机构的存储策略，选择资源嵌入或外部附件方式；512 MB 是设定限定值时可参考的数值。

因此，不能把它解读成“所有影像都必须塞进文档”，也不能做成“超过512 MB一律不合规”的校验规则。正式版第7.4条还涉及需要特殊工具浏览的非文书类资料，应结合这些条件一起设计。

工程上，我们建议分别验证：对象存在哪里、引用是否有效、访问授权是否正确、网络断开时如何提示。可显示的页面图像与原始 DICOM 数据对象也应区分，嵌入数据并不意味着普通阅读器就能完成医学影像显示。

正式版还增加了 JPEG2000、JBIG2 图像格式，并要求医学影像转换时，在满足个人信息保护和脱敏要求的前提下保留必要的诊疗关联信息。这对转换工具提出的不只是“能出图”，还有信息关联是否完整的问题。

二、签名之后能不能加注？原来就能，正式版细化了留痕方式

征求意见稿第6.3条已经允许签后添加注释，同时禁止修改已有签名保护的内容。因此，“从签完不能改到允许加注”不是准确的版本差异。

正式版明确将版面描述内容纳入签名保护，并对需要留痕追溯的修改、注释操作提出重新签名或增加签名的要求，同时推荐包含符合相关标准要求的时间戳。实现时还应结合第8章的完整性保护范围核对，不能只检查页面上有没有印章图案。

另一个容易忽略的点是文档组合。正式版第3.10条的注说明了组合对原签名验证的影响，以及组合后重新签名的处理。我们的工程建议是保留原始已签文档及验证记录，将组合结果作为派生文件管理；不要把“组合时处理签名”理解成可以丢弃原始证据。

对签署组件，测试用例应覆盖：签名保护范围、受保护内容被改动、追加签名、组合后重新签署，以及独立验签。上述用例是实施建议，不是标准原文的测试清单。

三、明确XML、JSON，不等于每份病历必须附带完整JSON

征求意见稿第7.5条主要规定机读信息的识别、编码和组织。正式版进一步要求文件中包含的机读信息采用 XML、JSON 等半结构化文本文件，结构清晰、准确、可识别；支持 GB 18030 规定的字符，并采用 UTF-8 编码。

这里有两个边界：支持 GB 18030 中的字符，不是把存储编码改成 GB 18030；XML、JSON 是形式举例，不是要求所有文件同时具备两套数据。

还应结合第7.3条关于结构化数据的推荐性规定，以及第5.3.2条对不同交换形式的说明阅读，不能简单推出“每份 OFD-H 必须内置完整 JSON”。

这与 AI 有什么关系？文字能提取、字段能解析、医疗语义能对齐，是三层不同能力。OFD-H 可以为文档与数据一同交付提供基础，但不能自动完成术语映射、数据质量治理或模型答案校验。希望对接 AI 的团队，更应该先建立页面内容与机读数据的一致性检查。

四、双层文档不是新发明，但定义更清楚了

征求意见稿已涉及纸质材料的双层版式转换和 OCR 分层。正式版第3.11条进一步明确了影像层、文本层，以及文字位置与影像字符位置的关系。

实际验收时，我们建议不仅看扫描页是否清晰，还检查选中文字的位置、复制顺序、漏字错字，以及文字层是否影响视觉呈现。一张扫描图加一个位置不对应的文本附件，不能仅凭“有图也有字”就认定满足双层文档要求。

五、交换组织更灵活；线性化并非正式版首次提出

征求意见稿第5.3.2条以按患者封装为一个文档为主要表述。正式版明确了文档组合、按需线性化或封装为文档集的交换组织方式。

需要纠正一个常见误读：征求意见稿第6.1.3条已经要求支持线性化。正式版增加了术语说明，并在交换要求中明确它的使用，不能把这项能力整体说成新增。

另外，交换层面的文档集与 OFD-H 文件内部的单文档要求属于不同层次。打包交换方案不能随意改变文件内部结构。技术团队应分别设计文件组织与交换组织，并用真实的目标阅读环境验证按需访问效果。

六、阅读软件增加第三方验证表述，不能用内部自测替代

两版第9.2条均涉及版式还原、验签、权限、注释、元数据和格式检查，也都要求打开 OFD-H 时禁用文档编辑功能。正式版在可信阅览与合规审计需求之外，明确了第三方验证。

这值得进入项目验收计划，但不能据此自行编造“指定认证机构”或宣称某个 SDK 已获认证。对供应方而言，应将条款、实现范围、样例、测试结果和第三方验证材料逐项对应，而不是只给出一句“支持国标”。

MediQ准备怎样围绕这些问题做产品？

我们关注的是把生成、签署、阅读之间的接口和验证证据衔接起来。MediQ 系列的产品方向包括：Signer 关注文档签署与验证；Generator 关注文档生成与资源、数据组织；Viewer SDK 关注阅读集成与交互。

正式版对比给出的实际任务，是为这些组件建立条款映射和验证样例，逐项区分已实现、待完善、待验证。以上是研发关注方向，不代表相关产品已完成标准符合性验证或第三方认证。

如果你负责医院信息系统、电子病历、病案管理或文档组件，欢迎交流一个具体问题：你目前最难处理的是影像附件、签后加注、机读数据，还是跨系统阅读与验签？无需提供真实患者资料。

获取资料与持续交流

点击本文底部“阅读原文”，查看正式版资料领取说明。当前通过企业微信人工发放独立下载码。若微信内页面打不开，可在手机浏览器输入 OFD.chat，或向本公众号发送“48666”获取联系说明。

欢迎关注“康小乔”，继续交流标准适配、签署和阅读集成的实际问题。

核对依据

1. GB/T 48666—2026《电子病历版式文档技术要求》正式文本：重点核对第3、5.3、6.1、6.3、7.2—7.5、8和9.2条。标准状态与日期可在全国标准信息公共服务平台核对：

2. 本文所对照的公开征求意见稿PDF（封面标注“征求意见稿”，编号为GB/T XXXXX—202X）：

本文由康小乔整理。实施时请以正式标准全文为准；文中的工程建议与产品方向不构成官方解释。