ARTICLE · 1233585
《电子病历版式文档技术要求》国家标准发布


《电子病历版式文档技术要求》国家标准发布医疗数据互通互认有了新方案
近日,市场监管总局(国家标准委)批准发布GB/T 48666—2026《电子病历版式文档技术要求》国家标准(OFD-H标准),该标准将自2027年4月29日起正式实施。该标准由国家密码管理局归口,国家卫生健康委统计信息中心、中国电子技术标准化研究院等单位起草。
电子病历是医疗机构智慧化建设的核心。2025年全国总诊疗人次达106.5亿,诊疗过程中产生了数量巨大、类型复杂的电子病历数据。医疗机构系统林立,电子病历格式各异,造成了信息系统集成难、数据整合共享难、病历归档利用难等问题。OFD-H标准正为破解这些难题而研制。
坚持自主自强,筑牢安全基础。OFD是我国自主研发的版式文档标准,被称为“中国的PDF”。OFD-H以此为基础,针对我国电子病历特点建立统一规范,并基于国产商用密码升级病历安全防护,为核实文件来源、防范内容篡改提供坚实技术支撑,有利于提升关键医疗数据和核心业务的自主保障能力,维护医患双方合法权益。
创新共享方式,让文档成为交换载体。针对病历资料分散、跨院系统对接难等问题,OFD-H探索“文档即接口”的共享方式。医疗机构完成统一适配后,既可查阅来自不同机构的病历,也能核验来源、提取数据,减少系统重复对接,为转诊、区域医疗协作及互联网医疗等提供便利。
强化多媒体融合,提升资源利用效率。OFD-H整合病历文书、医学影像、音视频和结构化数据等信息,同时支持可视化查看(人读)和计算机读取(机读),既便于医患双方查看,也为临床诊疗、科研和人工智能应用提供成体系的多模态数据。优化文件组织和资源存储,可有效降低病历存储和交换成本,并为归档利用提供有力支撑。
突出便民惠民,让群众成为健康档案“掌门人”。OFD-H可围绕健康中国和数字中国建设,依托现有居民健康服务体系,以患者为中心,逐步归集在不同地区、不同机构和不同时期的病历,形成贯穿全生命周期的“掌上健康档案”,让群众通过手机便可随时调取、规范使用和自主管理,更好提升健康服务的连续性与获得感。
下一步,市场监管总局将会同国家卫生健康委、国家电子文件管理部际联席会议办公室等有关部门扎实做好国家标准宣贯工作,推动OFD-H标准在智慧基层和智慧医院建设等场景中的应用,不断提升数智化便民、助医水平,助力健康中国建设。

目 次
前言
引言
1范围
2规范性引用文件
3术语和定义
4缩略语
5总体要求
5.1适用场景
5.2应用框架
5.3总体应用要求
6基础格式要求
6.1基础格式
6.2文件命名要求
6.3签名或签章要求
7医疗应用要求
7.1基本结构要求
7.2资源文件要求
7.3数据内容要求
7.4附件要求
7.5机读信息要求
7.6版本要求
8安全要求
9软件要求
9.1生成软件
9.2阅读软件
参考文献
前 言
本文件按照GB/T 1.1—2020《标准化工作导则第1 部分:标准化文件的结构和起草规则》的规定起草。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
本文件由国家密码管理局提出并归口。
本文件起草单位:国家卫生健康委统计信息中心、中国电子技术标准化研究院、中国医学科学院阜外医院、上海交通大学医学院附属瑞金医院、南京鼓楼医院。
本文件主要起草人:舒婷、赵韡、刘贤刚、董建、夏霁、李红霞、陈亚军、袁靖、林劼、张静、王凯、褚丹奇、胡伟国、杨郁青、赵艳、苏逸飞、鲍瀛、白松涛、韩志国、王雷、郑艳方、张鹏、林佳乔、申建刚。
引 言
电子病历是电子文件在医疗卫生行业应用的主要形态。该行业亟需将分散存储于各业务系统中的高价值电子病历数据,转换为符合国家档案管理要求、具备技术中立性且便于交换的电子病历,以实现其长期保存和利用。这些文件在脱离操作系统、数据库和业务信息系统等运行环境后,仍能保持其真实性、完整性,并具备长期可读、可理解和可用的特性。
电子文件作为信息载体,可支撑电子病历数据在异构信息系统之间的流通交换。通过以电子文件形式交付、流转和再加载数据,能够实现分散医疗数据的有效共享与融合利用,同时为系统间的数据交换与应用提供信任凭证。本文件提出了一种以文件为纽带连接医疗卫生行业异构信息系统的新框架,一方面借助版式文档提升阅读便利性,另一方面通过文件中的结构化数据更好地对接计算机处理。倡导医疗机构各类业务信息系统在业务流程中生成可携带、可交付的电子文件,更好地支持医疗数据跨机构流转,保障患者和相关用户的数据权利。各类需求方通过归集和整合这些电子病历,实现医疗机构内部、机构之间乃至区域医疗联合体的数据整合和利用。
电子病历版式文档技术要求
1 范围
本文件提出了电子病历的应用参考框架,并规定了电子病历版式文档的总体要求,以及基础格式、医疗应用、安全和软件等要求。
本文件适用于指导医疗信息系统生成、存储和处理电子病历版式文档,也适用于电子病历的归档和共享应用。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中,注日期的引用文件,仅该日期对应的版本适用于本文件;不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB 18030信息技术中文编码字符集
GB/T 33190电子文件存储与交换格式版式文档
GB/T 33560网络安全技术密码应用标识
GB/T 35275网络安全技术SM2 密码算法加密签名消息格式
GB/T 38540信息安全技术安全电子签章密码技术规范
GB/T 42133信息技术OFD 档案应用指南
3 术语和定义
下列术语和定义适用于本文件。
3.1
文件records
组织或个人在履行法定义务或办理业务过程中生成、接收并作为凭证保存的信息。
3.2
电子文件electronic records
通过计算机等电子设备生成或办理的文件。
3.3
版式文档fixed⁃layout document
呈现效果固定、独立于软硬件环境的文档形态。
注1:版式文档在各类屏幕、打印机等设备呈现效果一致。
注2:开放版式文档(OFD)是一种版式文档格式标准。
3.4
病历medical record
医疗机构的医务人员在门诊、住院患者临床诊疗和指导干预等医疗活动过程中形成的,记录服务对象的基本信息、病情、病史、检查检验、诊断、处方、治疗、护理等过程或结果信息的文件。
注:病历归档后称为病案。
3.5
电子病历electronic medical record
通过计算机等电子设备生成或接收、办理的病历。
3.6
业务系统business system
泛指医院信息系统(HIS)、实验室信息系统(LIS)、护理信息系统(NIS)以及电子病历(EMR)系统等支撑医疗机构开展各种业务的信息系统。
3.7
病历管理系统medical record system
一类利用信息技术手段对医疗机构的病历文件及其数据进行收集、整理、存储、查询、分析和服务利用的软件系统。
注:医疗机构的病案管理部门及相关人员是该系统的主要用户。
3.8
数字签名digital signature
为使数据单元的接收方确认该数据单元的来源和完整性,并防止数据单元被人伪造,而附加到数据单元上的或是对数据单元作密码变换后的数据。
3.9
资源resource
一组绘制图元所使用的参数或其他数据(如字体、图像等)的集合。
注:资源在版式文档中按照不同层级分为文档资源和页资源。
3.10
文档组合document combination
将多个文档按指定顺序合并成一个文档的过程。
注:文档组合将导致原文档中的数字签名无法验证,因此需要在文档组合时去除原文档中的数字签名,组合后再重新进行签名。
3.11
双层版式文档double⁃layer fixed⁃layout document
页面由扫描或拍摄获取的影像以及对影像进行光学字符识别(OCR)形成的文本两部分内容分图层(Layer)组成的版式文档。
注1:双层版式文档中的文本对象的位置与影像字符切分的结果保持一致,页面的视觉呈现效果由影像层提供,文字内容选中及提取复制效果由文本层提供。
注2:双层版式文档中影像层图元可见,文本层图元不可见(Stroke=false,Fill=false)。
3.12
加注记录annotation records
在电子文件生成并签署生效后,由授权人员为补充说明、澄清信息或更正内容,以注释(Annota⁃tion)方式添加的,与原文对应内容或位置绑定的文本或多媒体信息。
3.13
文档线性化document linearization
一种为实现高效网络访问而进行的文件优化。
注:优化通常包含两部分:
a)在文件头部安排内容索引;
b)将首先需要显示的内容和资源数据安排在文件开头位置。
4 缩略语
下列缩略语适用于本文件。
BMP:位图(Bitmap)
DICOM:医学数字成像和通信(Digital Imaging and Communications in Medicine)
EMR:电子病历(Electronic Medical Record)
HIS:医院信息系统(Hospital Information System)
JBIG2:联合二值图像专家组第二版(Joint Bi⁃level Image Experts Group 2)
JPEG:联合图像专家组(Joint Photographic Experts Group)
JSON:JavaScript 对象表示法(JavaScript Object Notation)
LIS:实验室信息系统(Laboratory Information System)
NIS:护理信息系统(Nursing Information System)
OCR:光学字符识别(Optical Character Recognition)
OFD:开放版式文档(Open Fixed⁃layout Document)
PACS:影像归档和通信系统(Picture Archiving and Communication System)
PNG:便携式网络图形(Portable Network Graphics)
TIFF:标记图像文件格式(Tagged Image File Format)
XML:可扩展置标语言(Extensible Markup Language)
5 总体要求
5.1适用场景
以下场景的电子病历应符合本文件要求或转换为符合本文件要求的版式文档:
a)医疗活动中形成的各类电子文件,包括患者线上线下、院内院外诊疗活动中产生的全部医疗相关记录,如病历、医嘱、处方、检查报告、知情同意书、检验记录、手术记录、护理记录、过程记录、检查图像及处理后图像等;
b)医疗活动中形成的非电子化的病历材料,如医疗设备直接输出的纸质报告、纸质或胶片载体的历史病历、患者身份证明材料等;
c)医疗活动中形成的音视频类资料,如医疗影像、诊疗过程的音视频记录等;
d)医疗活动中接收的外部医疗机构产生的病历文件,包括诊疗活动中外部机构、患者或家属提供的各类病历资料。
5.2应用框架
医疗机构内应用电子病历版式文档应秉持不改变或较少改变现有业务系统的原则,建立电子文件归集机制,通过机构内文件系统集中收纳处理或代理生成电子文件,并支持向病历管理系统或区域内医疗联合体共享相关文件,其应用参考框架见图1。

图1电子病历版式文档的应用参考框架
图1 对应说明和要求如下:
a)电子病历版式文档来源于HIS、EMR、NIS、LIS、PACS、体检系统等业务系统或其他数据来源;
b)电子病历版式文档以业务系统向其服务对象(如患者)交付的文件为基础;
c)业务系统可在本系统内生成版式文档,也可将生成版式文档所需的数据提交至本机构内文件系统,由其代理生成版式文档并委托签署;
d)医疗机构内文件系统除收集、保存电子病历版式文档外,还应具备生成、转换和受托签署版式文档的功能;
e)医疗机构装备有病历管理系统的,应与机构内文件系统集成;
f)与其他医疗机构或医疗联合体之间进行数据交换时,应以相应电子病历版式文档或脱敏处理后的版式文档为单元。
5.3总体应用要求
5.3.1 生成转换
生成或转换后电子病历应内容完整、格式规范(OFD⁃H)、签名有效、结构可机读、版本可追溯、安全可控,并符合国家相关标准与法规要求,具体要求如下:
a)医疗机构内各类业务系统在医疗活动中形成的电子病历版式文档,无论是系统内生成还是委托电子文件系统代理生成,可采取电子签章、数字签名等技术手段进行安全防护;
b)医疗活动中形成的非电子化病历材料,应在诊疗活动完成前,或在医疗机构病历管理、归档管理相关规定明确的时限内,按照档案数字化加工有关要求处理为双层版式文档;
c)医疗活动中接收的外部医疗机构产生的病历文件,应审核其内容真实性、完整性和合理性,审核通过后,按照下列情况分别处理:
1)纸质文件的,应按照b)处理;
2)不符合本文件要求又需转成纸质使用的,打印后应按照b)处理;
3)符合本文件要求的电子文件,应在采信前检测其安全防护措施是否有效;
4)其他情况的,应通过机构内文件系统转换OFD 格式。
5.3.2 传输交换
电子病历版式文档用于数据交换满足如下要求:
a)根据交换场景,一般在交换前应以“患者”为单位将一次或多次的诊疗活动形成的电子病历进行文档组合并按需进行文档线性化,或者封装为一个文档集;
b)根据交换场景,交换时可提供不同形式的版式文档,包括不含结构化数据的版式文档、双层版式文档等;
c)用于交换的电子病历版式文档应引入权限控制机制,对于不同的权限应有不同的控制要求;
d)涉及服务对象(如患者)个人信息的电子病历版式文档交换应符合个人信息保护法相关要求;
e)文档交换的过程信息可用加注记录的方式记录于文件中。
5.3.3 检索查询
电子病历版式文档应支持针对电子病历中关键内容、版本记录、加注记录等的检索及定位。
6 基础格式要求
6.1基础格式
6.1.1 格式框架要求
OFD 采用“容器+文档”的格式框架描述和存储数据,电子病历版式文档应沿用这一框架。其中容器是一个虚拟存储系统,作用是将各类数据和描述文档的各类文件聚合起来,并提供相应的访问接口和数据压缩方法。OFD 的格式框架见图2。

OFD 格式框架分为以下4 层:
a)虚拟存储系统:包括组织结构及虚拟存储系统内目录组织结构,提供数据和文件容器;
b)文档模型:包括文档、页面、大纲、文件资源等逻辑结构内容;
c)页面描述:包括图形、图像、文字及其组合等结构内容,以及结构内容使用的资源;
d)扩展特性:包括文档的交互性、安全性和可扩展性等描述内容。
6.1.2 一般要求
电子病历版式文档的承载格式固定为OFD,且应使用单文档。
电子病历版式文档的数据内容及其组织应符合GB/T 33190、GB/T 42133 的相关要求。
6.1.3 文件组织要求
电子病历版式文档应支持文档线性化,其OFD 文件的线性化等功能使用ZIP 文件执行。
电子病历版式文档中的多文件数据组织方式应符合ZIP 6.2.0 及以上规范。虚拟存储系统内的可压缩内容应使用Deflate 压缩方法。
6.2文件命名要求
电子病历版式文档包内文件应使用规范的名称和目录结构,见图3。

图3 中的典型文件说明见表1。
表1 OFD 包内的典型文件说明


电子病历版式文档对应的虚拟容器内,XML 文件使用的命名空间应与所使用的GB/T 33190 标准版本一致,其标识符宜为ofd;容器内各XML 文件的根节点中应声明defaults:ofd;XML 文件中的元素节点宜使用命名空间标识,元素属性不使用命名空间标识。
示例:当电子病历版式文档使用GB/T 33190—2016版本及其修改单时,虚拟存储容器内OFD.xml中的Version属性应标记为“1.X”,XML文件使用的命名空间为“http://www.ofdspec.org/2016”。当电子病历版式文档使用 GB/T 33190的后续版本时,使用对应版本规定的版本号和命名空间。
6.3签名或签章要求
电子病历版式文档使用数字签名或电子印章的要求如下:
a)应符合国家相关法律法规;
b)应用的密码标识应符合GB/T 33560 的要求;
c)应用的数字签名应符合GB/T 35275 的有关要求;
d)应用的电子印章和电子签章数据应符合GB/T 38540 的有关要求;
e)数字签名或电子签章数据应将文件的版面描述内容纳入保护范围;
f)电子文件签名或签章后应支持添加注释等修改,但不应修改签名或签章已经保护的内容;
g)需对电子文件内容的修改、注释等操作进行留痕追溯时,应重新签名或增加签名。
除以上要求外,电子签名或电子签章数据宜包含符合相关标准要求的时间戳。
7 医疗应用要求
7.1基本结构要求
电子病历版式文档对OFD 基本结构的使用要求如下:
a)主入口(OFD.xml)文件中根节点的文档类型(DocType)属性取值设置为“OFD⁃H”;
b)文档使用的字型、图像、音频、视频、模型等资源应包含在虚拟存储系统内,按照GB/T 33190和 6.2 的要求存储在资源文件(PublicRes.xml、DocumentRes.xml 和Page_N/PageRes.xml)、资源文件夹(Res、Page_N/Res)等处;
c)对文档有著录、加工操作的,其元数据应存储在主入口文件(OFD.xml)中的文档信息(DocInfo)部分或其引出文件(DocInfo_N.xml);
d)根据需要自动或人工标注生成的病历内容自定义标引应存储在标引文件夹(Tags);
e)文档附件的信息和内容主体应存储在附件文件夹(Attachs);
f)被注释的电子病历版式文档,其注释内容存储在注释文件夹(Annots)等处。
7.2资源文件要求
电子病历版式文档中的资源文件要求如下。
a)被文档页面内容使用的字型、绘制参数和在多个页面中共同使用的资源应在文档资源列表(DocumentRes.xml)文件中注册,仅在一个页面内使用的资源一般在页面资源列表(Page_N/PageRes.xml)文件中注册。
b)显示和打印所需的全部字型数据应包含在文件中,除非同时满足以下条件:
1)字符编码在文件格式标准规定的豁免嵌入的字符集范围内;
2)使用的字型在文件格式标准规定的豁免嵌入的字型列表内。
c)显示和打印所需的图像资源应包含在文件中。
d)版式文档内使用的图像格式应采用BMP、JPEG、JPEG2000、TIFF、PNG 或JBIG2,其他格式的图像应进行格式转化;DICOM 等医学影像转换为上述图像格式时,应在符合个人信息保护和脱敏要求的前提下,同步保留患者标识、检查时间、检查部位等必要的诊疗关联信息。
e)文档内容关联DICOM 影像、图像、音频、视频或三维模型等数据对象的,被关联的数据对象体积不超过医疗机构根据存储等策略设定的限定值时,宜作为资源嵌入使用;超过限定值时,宜作为外部附件记录,限定值可参考512 MB 设置。
f)如需嵌入音频,其内容应采用MP3 等通用音频格式,或转换为上述格式。
g)如需嵌入视频,其内容应采用MP4 等通用视频格式,或转换为上述格式。
h)如需嵌入影像、音视频、三维模型等,其内容清晰度应满足医疗记录的准确性要求。
7.3数据内容要求
电子病历版式文档的呈现效果应与传统载体的同类文件相同或相近,同时符合以下要求:
a)应明确标识医疗服务对象(患者)、责任者、生成时间和内容关键词等信息的元数据;
b)应包含文件标识信息,用以明确文件类型、秘密等级及文档标识;
c)电子病历中不同类型的结构化数据,宜以自定义标引或附件方式存储于虚拟存储系统中,并与文件页面内容保持一致;
d)文档宜包含生效信息,一般为责任者或其所在医疗机构的数字签名或电子签章数据;
e)通过扫描加工形成的版式文档,在转换时宜将扫描产生的图像安排在背景层,若进行光学字符识别,宜将识别后的文字内容安排在正文层;
f)文档内容关联DICOM 影像、图像、视频或三维模型的,当采用资源方式嵌入时,文档内应包含内部跳转动作,当采用外部附件方式记录的,文档内应包含外部跳转链接;
g)不应禁止元数据著录、注释、文档组合和签名操作,需要时,可将多个文档组装为符合归档要求的OFD 文件。
7.4附件要求
电子病历版式文档中应用附件机制的要求如下:
a)OFD 文件中,应支持以附件方式存储与医疗活动相关的非文书类资料,如DICOM 影像、音频、视频等;
b)附件的使用应支持文件内部或外部附件方式;
c)对于体积大于医疗机构根据存储策略设定的限定值或需要特殊工具浏览的非文书类医疗资料,宜使用外部附件方式。
7.5机读信息要求
电子病历版式文档中包含的机读信息的要求如下。
a)机读信息应以半结构化文本文件(如XML、JSON 等)形式存储,文件结构应清晰、准确、可识别。
b)机读信息文件应支持GB 18030 中规定的字符,并采用UTF⁃8 编码。
c)机读信息文件包含多项组成内容的,应在其信息组织中列出以下必要信息:
1)文件头信息,至少包括版本号、创建时间、修改时间;
2)元数据信息,至少包括文档属性、创作者、关键字;
3)标识信息,至少包括文件类型、秘密等级及唯一识别码。
d)机读信息文件的组织应有利于计算机快速区分、检索、获取各组成中的细节内容,并符合医疗卫生行业现行的有关标准规范。
7.6版本要求
电子病历版式文档需以版本方式记录内容或注释变动的,应保留历史版本的全部内容,或将历史版本修改内容以内部附件方式存储。
8 安全要求
电子病历版式文档的安全要求如下:
a)在需要采用密码技术保护电子病历真实性、完整性、有效性的场景中,所使用的密码技术和产品应符合国家密码主管部门的相关要求;
b)应用的临时OFD 病历文件,可在需要时使用加密选项,包含加密选项的临时OFD 病历文件,在用于长期保存时,应在归档、迁移前进行解密;
c)如需使用数字签名或电子签章数据,其保护的范围应涵盖不包含注释列表、签名列表等文件的电子病历全部内容;
d)如需使用数字签名或电子签章数据,应使用国家商用密码算法;
e)如需使用数字签名或电子签章数据,其验证应不依赖特定的医疗业务软件或系统。
9 软件要求
9.1生成软件
应用于医疗卫生行业的OFD 生成软件应符合以下要求:
a)具备将数据、文件等生成OFD 文件的功能;
b)具备将多种格式文件转换为OFD 文件的功能;
c)具备文件加工功能,能按照GB/T 42133 的要求处理OFD 文件;
d)生成、转换和加工OFD 文件时,按照本文件给出的原则和方式进行。
9.2阅读软件
应用于医疗卫生行业的OFD 阅读软件要求如下:
a)应具备版式还原、签章验证、权限控制、注释定位、元数据展示等功能;
b)应具备对插入页面、调整页面等文档编辑操作进行授权控制的功能,在打开文档类型属性取值为“OFD⁃H”的 OFD 文件时,自动禁用文档编辑功能;
c)文件格式检查应按照长期保存处理规则和本文件的要求进行,格式检查后,应对其中的未处理项以对话框、日志等方式加以提示;
d)宜具有打开外部附件的功能;
e)经验证应满足病历调阅、跨机构共享等场景的可信阅览与合规审计需求,且经第三方验证。
参考文献
[1] GM/T 0099—2020开放式版式文档密码应用技术规范















































































