电子病历版式文档技术要求
正式版 · 22 页在线阅读
从系统内可用，到跨系统可读、可用、可验证。
本页文字提要
MEDICAL RECORD / 2026 STANDARD BRIEFING
一文看懂
OFD-H
电子病历文档技术要求正式版
从“系统内可用”走向“跨系统可读、可用、可验证”
GB/T 48666—2026
标准解读 · 图文版
人读 + 机读 + 可信
2026.10
本页文字提要
WHY IT MATTERS
02 / 22
电子病历很多，为什么跨系统使用仍然困难？
真正的问题，往往发生在文件离开原来的业务系统之后。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
01
读不准
不同软件中的版式、字体与图像可能不一致
02
用不了
页面能看，字段却未必能被机器理解
03
验不清
签名只能在原业务系统里验证
04
存不久
附件失联、资源缺失，长期可读性不足
OFD-H关注的不是“再造一套EMR”，而是医疗文件离开原系统后的可信利用。
本页文字提要
CONCEPT
03 / 22
OFD-H是什么？是一种医疗版式文档技术规范
不是新的医院信息系统，而是面向医疗场景的标准化文件载体。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
03
医疗应用要求
影像、多媒体、机读信息、版本和归档
02
可信保护机制
电子签名、证据、独立验签
01
OFD 版式基础
页面、文字、字体、图像、资源和容器
不等于
×
HIS / EMR 的替代品
×
独立的PACS影像平台
×
统一的医疗数据语义标准
核心定位：把医疗信息组织成稳定、可交付、可独立使用的电子文件。
本页文字提要
STANDARD AT A GLANCE
04 / 22
第5—9章，一张图看懂六大能力域
正式版在OFD底座之上，覆盖文件、医疗数据、可信保护与软件验收。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
基础格式
第6章
医疗资源
第7.2/7.4条
机读数据
第7.5条
签名安全
第6.3/8章
长期保存
第7.6/9.1条
软件验证
第9章
OFD-H
统一医疗文件载体
本页文字提要
WHAT CHANGED
05 / 22
正式版最值得关注的六项调整
并不是全部条款都重写，许多基础约束从征求意见版延续而来。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
01
业务系统
减少改造，允许代理生成
02
人读＋机读
明确XML、JSON等组织
03
医学影像
内嵌与外部附件更灵活
04
扫描病历
明确双层OCR与位置关系
05
签署证据
强调保护范围和留痕
06
软件验收
明确第三方验证
判断是否合规，必须看正式条款及“应／宜／可”的适用条件。
本页文字提要
ARCHITECTURE
06 / 22
减少对既有系统的改造：以文件为连接纽带
第5.2条强调机构内文件系统，业务系统可直接生成，也可委托生成。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
HIS
诊疗
EMR
病历
LIS
检验
PACS
影像
机构内文件处理能力
文档归集 · 生成与转换 · 受托签署
病案归档
长期保存与版本
跨机构共享
独立阅读与验证
本页文字提要
GENERATION
07 / 22
两条生成路径：数据生成与文件转换都需要
正式版9.1将两类能力单列，适配新系统和存量系统。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
路径 A
结构化业务数据
模板与排版模型
直接生成OFD-H
路径 B
PDF / DOCX / 既有格式
解析、保真转换
转换为OFD-H
能输出OFD ≠ 符合OFD-H：还需验证资源、元数据、机读信息及适用签名规则。
本页文字提要
MACHINE READABLE
08 / 22
同一份检验报告：人能读，机器也能读
第7.3和7.5条强调页面与机读信息一致，但不要求每份文件都内置JSON。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
人读 · 固定版式
血常规检验报告
血红蛋白
135 g/L
白细胞
6.2 ×10⁹/L
检查时间
2026-10-28
机读 · XML / JSON
{
"hemoglobin": 135,
"unit": "g/L",
"examDate": "2026-10-28"
}
文字可检索、字段能提取、医学语义能互通——这是三个不同层次。
本页文字提要
DATA SEMANTICS
09 / 22
“文字可检索”不等于“医疗数据可计算”
OFD-H提供文件容器与机读组织基础，语义一致性还需要医疗行业规范。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
01
可检索文字
找到“高血压”这几个字
OCR / 文本提取
02
结构化字段
识别诊断名称、数值、单位
XML / JSON / 标引
03
医疗语义
对齐诊断编码、术语与数据含义
行业数据标准
不是“做了OCR”就完成结构化，更不是“存了JSON”就完成医疗语义互操作。
本页文字提要
HISTORICAL RECORDS
10 / 22
双层版式文档：看得像原件，找得到原文
第3.11条明确扫描影像层与不可见OCR文字层的分工和位置关系。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
视觉层 · 可见
入院记录
患者主诉：胸闷三日
初步诊断：待进一步检查
医师签名：________
OCR层 · 不可见
入院记录
患者主诉：胸闷三日
初步诊断：待进一步检查
文字层不重复绘制；但文本区域应与扫描影像位置对应，支持检索、选中与复制。
本页文字提要
IMAGING
11 / 22
医学影像：内部资源与外部附件怎么选？
正式版允许按医院存储策略决定组织方式，512MB仅为参考限定值。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
OFD-H 医学检查报告
内部资源
资源嵌入 + 内部跳转
外部附件
外部关联 + 授权访问 / 专业查看器
512MB不是文件大小强制上限；影像是否内嵌，还要考虑格式、性能与专业阅览需求。
本页文字提要
CLINICAL CONTEXT
12 / 22
医学影像转换，不能只剩下一张图片
DICOM转换为普通图像时，应保留必要诊疗关联信息，并满足个人信息保护要求。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
影像像素
只保留图片，不够
诊疗关联信息
患者标识
用于匹配就诊对象
检查时间
用于定位检查事件
检查部位
用于区分不同影像
受控访问
符合隐私和脱敏要求
这里强调的是“影像属于谁、何时、何部位”，不是让OFD阅读器替代PACS。
本页文字提要
TRUST
13 / 22
数字签名保护的，不只是页面上的印章图片
第6.3和8章共同约束签名保护范围、数据完整性与独立验证。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
病历文件的受保护内容（示意）
版面描述
Content.xml等
资源与字体
图像、字型等
医疗数据
适用的机读内容
文档结构
适用的元数据/引用
签名覆盖审计
保护什么？
排除什么？
注释列表、签名列表存在适用例外，不等于可以任意修改已签署内容。
本页文字提要
EVIDENCE
14 / 22
签署后需要补充说明：不能直接覆盖原文
正式版强调受控加注，并在需要留痕追溯时重新签名或追加签名。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
01
完成病历
保留原始内容
02
原始签名
明确签署范围
03
授权加注
记录新增说明
04
追加签名
分别验证新旧签名
受控加注 ≠ 无条件修改；具体是否可保留旧签名有效，取决于保护范围与合法文件结构。
本页文字提要
EXCHANGE
15 / 22
文档组合和文档集，不能混为一谈
两种方式都可用于交换，但对原始签名的处理不同。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
文档组合
D1
D2
D3
将多个文档内容合成新文档
需要处理原签名，并重新签署组合结果
文档集
D1
D2
D3
保留若干独立OFD文档
更便于保留各文件原有签署关系
本页文字提要
ARCHIVE
16 / 22
长期保存：今天能打开，不等于十年后仍能使用
资源完整、签名可验证、版本可追溯与归档处理，需要一体考虑。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
01
生成时
资源嵌入与结构正确
02
交换时
独立阅读与签名验证
03
归档时
版本保留及按规加工
04
长期后
仍可读取、定位和解释
若临时OFD采用了文件加密选项，标准要求归档、迁移前按规定进行解密。
本页文字提要
SOFTWARE
17 / 22
医疗OFD阅读器，必须不止“能打开文件”
第9.2条要求阅读、验证、控制与格式检查，并明确第三方验证。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
1
版式还原
准确显示页面
2
签章验证
验证密码证据
3
权限控制
禁止越权编辑
4
注释定位
快速找到补充说明
5
元数据展示
识别文档属性
6
格式检查
报告未处理事项
OFD-H打开时应自动禁用文档编辑；外部附件打开为推荐能力，第三方验证需单列证据。
本页文字提要
VALUE
18 / 22
对医院而言，改变的不是扩展名，而是文件治理方式
从临床使用到病案管理，价值各不相同。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
临床医生
阅读与签署更统一
保持诊疗流程连续性
医院信息科
减少格式与系统绑定
降低重复集成成本
病案管理
文件可归档、可追溯
长期利用与审计
患者
更便于获取和管理
跨机构利用的技术基础
标准解决的是文件层面的基础能力；身份授权、医疗语义和临床互认仍需配套制度与系统。
本页文字提要
ROADMAP
19 / 22
医院推进OFD-H：四步走，比整体替换更稳妥
建议从既有文件、签署证据与典型业务场景出发。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
01
盘点现状
清查PDF/OFD/扫描件
02
核查可信
签名、验签、归档
03
选择试点
出院记录/同意书/报告
04
符合性验证
独立阅读、第三方证据
GB/T为推荐性国家标准，并不意味着所有医院必须立即停用PDF或替换既有EMR。
本页文字提要
PRODUCT THINKING
20 / 22
MediQ的合理定位：围绕可信文档提供可复用组件
产品建议：Signer聚焦商业化，Generator与Viewer作为配套能力。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
MediQ Generator
可信生成
生成、转换、资源与机读信息
MediQ Signer
可信签署
签名保护、证据与独立验签
MediQ Viewer SDK
可信阅览
页面还原、注释、附件与验证
内部 Validator：结构、机读数据、签名保护范围、兼容性与第三方验收证据
不要因为OFD-H适配重新建设完整EMR、PACS或病案管理系统。
本页文字提要
CLARIFICATIONS
21 / 22
关于OFD-H，有四个常见误区
标准正式发布后，仍需严格区分规范性要求、推荐能力与实施政策。
GB/T 48666—2026 · OFD-H 电子病历版式文档技术要求
误区 01
所有医院都要马上停用PDF
推荐性国标并不直接等于强制整体替换
误区 02
每份OFD-H都必须内置JSON
结构化数据是条件性与场景化能力
误区 03
512MB是全国统一的硬上限
只是可参考的容量阈值
误区 04
自家生成自家打开就是合规
阅读软件还涉及第三方验证要求
截至2026-10-28，标准信息平台/正式文本标注实施日为2027-04-01；部分新闻稿写为04-29。
本页文字提要
OFD-H / GB/T 48666—2026
让电子病历离开原系统后，
依然可读、可用、可验证。
以标准文件连接异构系统 · 以密码保护建立可信证据 · 以独立验证支持长期利用
信息依据：国家标准信息公共服务平台 GB/T 48666—2026；市场监管总局发布信息；正式标准文本。
发布：2026-09-28 · 标准目录实施日期：2027-04-01 · 推荐性国家标准