医院信息集成平台项目建设方案与实践 第4章 项目建设设计（五）

4.3.7 数据中心建设

4.3.7.1 临床数据中心

 

 

(一) 数据资源规划和管理  

数据资源规划

 数据源层 数据源是整个数据中心信息资源的基础，数据源内容主要来自于三大类业务数

据:临床服务数据、医疗管理数据以及运营管理数据。 A.临床服务数据

临床服务数据主要是以患者为中心的临床诊疗活动全过程数据。数据源主要来 自于门急诊挂号系统、门诊医生工作站、分诊管理系统、住院病人入出转系统、住 院医生工作站、住院护士工作站、电子病历系统、合理用药管理系统、临床检验系 统、医学影像系统、超声/内镜/病理管理系统、手术麻醉管理系统、临床路径管理 系统、输血管理系统、重症监护系统、心电管理系统、体检管理系统等临床业务系 统。

B.医疗管理数据

医疗管理数据主要是医院医疗活动和医疗费用全过程数据，保障医院医疗活动 的质量和安全，合理控制医疗费用。数据源主要来自于门急诊收费系统、住院收费 系统、护理管理系统、医务管理系统、院感/传染病管理系统、科研教学管理系统、 病案管理系统等医疗管理系统。

C.运营管理数据

运营管理数据主要是医院“物流、资金流、信息流、业务流”的统一运营管理 数据。数据源主要来自于人力资源管理系统、财务管理系统、药品管理系统、设备 材料管理系统、物资供应管理系统、预算管理系统。
 ODS层

ODS 数据来源于在线业务系统的实时映像。映像数据保存周期为数据集市的装 载周期，一般 ODS 的数据库结构和业务数据库是完全一致的，这样数据可以高效的 从业务数据库中抽取出来。

利用 ODS，我们即可以允许历史数据在保存周期中进行更新，又可以随时对现 有监测数据进行分析，满足应急性分析需求。数据从业务库抽取出来装载到 ODS 后， 从 ODS 中根据主题模型进行数据清洗和转换从而完成建立数据集市之前的数据准 备工作。
 主题聚合层

主题聚合层基于 ODS 层，主题数据从 ODS 中经过抽取、清洗、转换、加载，并 按照分析主题进行数据模型的建设和组织。根据业务分析的主题可以包括:医院经

济运行主题、医院财务主题、医院人力资源主题、医疗保障主题、质量指标主题、 医疗服务主题、医疗安全主题等。这些主题表是按照业务相关的 ODS 层数据表进行 聚合而成，是属于明细类的数据表。
 数据集市

数据集市层基于 ODS 层和主题聚合层，按照临床、医疗管理、运营管理相关主 题形成各类数据的存储、处理和集中管理。
 数据管理

数据管理功能对于整个数据中心非常重要，这涉及到数据质量、监管、维护、 数据安全等多方面内容。对于医疗数据中心的数据管理方面，需要建立一套统一的 技术标准体系和技术平台。数据管理的统一化、平台化，可以更好地完成数据管理 工作，更好的为数据应用提供支撑。

 统一的数据存储 关于数据的存储，从应用的角度进行设计，即数据存储的设计满足各类业务的

应用需求，支持存储结构与非结构性的数据，同时兼顾数据扩展和性能要求。
  通过对数据的分类管理，将数据存储到不同的区域内，以满足各项应用要求，

如下表所示:

 数据存储库说明

 

A.标准化存储 基于主数据管理，形成医学信息标准构成内容丰富的受控术语词汇域，词汇域

作为基础数据来源组成了临床数据中心的基础字典数据，词汇定义使用 ICD、 SNOMED、LONIC 等标准来定义临床术语，建设医院临床数据中心，使医院数据中心 数据按照国家、卫生部下发的各种字典表和电子病历等级评审的要求标准化存储， 满足医院临床诊疗分析及决策、科研分析等需要。

B.模型化存储

以患者 EMPI 为主线组织患者的临床数据，构建病人基本信息、就诊记录、门 诊处方、住院医嘱、电子病历、检查化验报告、手术麻醉等数据模型，将患者的所 有医疗信息，如就诊记录、门诊处方、住院医嘱、电子病历、检查化验报告等模型 化存储。以全面、标准、统一的方式实现患者临床结构化、非结构化数据的整合存 储，临床数据的共享提供了统一的平台支撑。最终实现辅助改善医疗服务质量、较 少医疗差错、提高临床诊疗水平，为决策提供支持信息和降低医疗成本。

 统一的数据处理引擎
统一的数据处理引擎是数据从数据源到数据中心整个 ETL 过程通过统一的数

据处理机制和流程对数据流转进行控制。包括 ETL 调度、错误处理、过程监控、数 据抽取、转换、加载等功能的统一化、流程化。

数据处理引擎可以通过专业的 ETL 工具实现，也可以自行编写代码实现。对数 据处理过程统一的主要目的是要规范数据 ETL 过程，易于数据管理和控制。同时可 保证数据出自一处，避免数据二义性，出现数据质量问题。
 统一的元数据管理

　　元数据管理可通过专业工具实现，也可以通过初始化数据表方式实现。通过管 理平台的元数据查询功能，实现对元数据管理，并通过统一管理方式对业务元数据 和技术元数据进行管理。
   统一的数据访问面向不同应用，数据中心提供了多种数据服务，包括基于标准的数据共享、 Webservice 等方式。对数据访问服务提供访问接口的规范化和统一化，并对外公 开数据服务接口，实现数据服务统一化。

 采集方式

A.数据发布和订阅

通过发布订阅的方式实现数据库之间的同步操作。发布订阅份为两个步骤:发 布和订阅。首先在数据源数据库服务器上对需要同步的数据进行发布，然后在目标 数据库服务器上对上述发布进行订阅。发布可以发布一张或多张表的全部数据，也 可以对部分表的部分数据进行发布。发布、订阅的过程如下:

数据的发布:发布需要用实际的服务器名称，发布的信息包括表中数据新增、 修改、删除信息，同时对业务系统数据结构的变化能及时通知数据仓库进行自动变 更操作。

数据的订阅:订阅是对数据库发布的快照进行同步，将发布的数据源数据同步 到目标数据库，实现数据库或者表数据源的自动同步。

B.ETL 方式数据自动抽取

对数据进行 ETL 的目的是保证数据的质量，进而根据不同业务分析需求将历史 数据按照不同的分析维度来进行汇总，以便为业务决策提供某个维度的信息支持。 ETL 的过程就是数据流动的过程，包括数据的抽取、清洗、转换和装载等过程。抽 取工作通过工具 KETTLE 开发抽取包完成。

ETL 过程存在主外键约束，对无依赖性的非法数据，可替换或导出到错误数据 文件中，保证主键唯一记录的加载。

1)数据抽取

数据抽取就是从数据源中获取数据(无论是何种格式)的过程。这个过程有两 种方式:全量抽取、增量抽取。

全量抽取:全量抽取类似于数据迁移或数据复制，它将数据源中的表或视图的 数据原封不动的从数据库中抽取出来，并转换成自己的 ETL 工具可以识别的格式。 全量抽取比较简单。

增量抽取:增量抽取指抽取自上次抽取以来数据库中要抽取的表中新增、修改、 删除的数据。如何捕获变化的数据是增量抽取的关键，目前增量数据抽取中用的捕

获变化数据的方法有: 2)数据清洗

清洗就是把“脏”的“洗掉”，指发现并纠正数据文件中可识别的错误的最后 一道程序，包括检查数据一致性，处理无效值和缺失值等。因为数据仓库中的数据 是面向某一主题的数据的集合，这些数据从多个业务系统中抽取而来而且包含历史 数据，这样就避免不了有的数据是错误数据、有的数据相互之间有冲突，这些错误 的或有冲突的数据显然是我们不想要的，称为“脏数据”。我们要按照一定的规则 把“脏数据”“洗掉”，这就是数据清洗。而数据清洗的任务是过滤那些不符合要求 的数据，将过滤的结果交给业务主管部门，确认是否过滤掉还是由业务单位修正之 后再进行抽取。不符合要求的数据主要是有不完整的数据、错误的数据、重复的数 据三大类。

3)数据转换

数据转化通常是指数据从非结构化的数据，按照设定的规则转换为结构化的过 程，转换通常不仅仅是数据格式的转换，业务系统数据可能包含不一致或者不正确 的信息，这些操作也包含在转换的步骤中.

4)数据抽取管理

数据抽取转换工具通过配置文件连接到各业务系统后，通过配置抽取数据任务 信息的各项属性，如任务名称、任务描述、起点时间等建立数据抽取作业，数据抽 取转换工具通过这些数据抽取作业的创建维护和管理来完成数据的抽取和转换。  

• 数据采集流程

A.数据由业务系统到数据仓库(ODS)

1.检验检查数据:针对检验、检查、危机值数据，对实时性要求高的，采用订 阅发布机制，实现数据由业务系统到数据仓库(ODS)中。此机制中针对历史数据， 通过订阅发布机制一次性获取全部数据。对新增数据，将通过订阅发布机制并结合 使用时间戳和 CDC 技术，依据标志字段值来识别新增数据，准实时的实现数据获取 到数据仓库中。

2.患者基本信息、就诊情况、处方、医嘱、病历、体检、手术、麻醉等信息: 对实时性要求不高的数据，采用 ETL 数据抽取方式实现数据抽取到 ODS 中。此机制 中针对历史数据，将通过 ETL 方式全量一次性抽取到 ODS 中。对新增数据，结合使

用时间戳和 CDC 技术，依据标志字段值来识别新增数据。 3.门诊住院费用、绩效、成本、固定资产、人力资源等运营管理信息:对实时

性要求不高的数据，采用 ETL 数据抽取方式实现数据抽取到 ODS 中。此机制中针对 历史数据，将通过 ETL 方式全量一次性抽取到 ODS 中。对新增数据，结合使用时间 戳和 CDC 技术，依据标志字段值来识别新增数据。

B.数据仓库(ODS)到数据中心

此过程中由于要对数据进行数据聚合，合并，清洗操作，无法采用订阅发布方 式，采用 ETL 数据抽取方式实现数据的抽取到数据中心数据库中。此机制中针对历 史数据，将通过 ETL 方式全量一次性抽取由 ODS 抽取到数据中心。对新增数据，将 通过增量抽取的机制，结合使用时间戳和 CDC 技术，依据标志字段值来识别新增数 据。

 增量数据采集策略 A.时间戳

时间戳是数据库中自动生成的唯一二进制数字，与时间和日期无关的，通常用 作给表行加版本戳的机制。存储大小为 8 个字节。 每个数据库都有一个计数器， 当对数据库中包含 timestamp 列的表执行插入或更新操作时，该计数器值就会增 加。时间戳的优点有:

时间戳是天然的主索引，可以确定数据的唯一性，避免并发 时间戳是微软数据库内部机制，稳定高效，不影响性能 时间戳是一列只读字段，写入由数据库内部完成，对业务系统的改造升级影响

最小
可控性强，续传能力好
B.CDC
CDC 是变化数据捕获(Change Data Capture) ,CDC 一般通过读取事务日志

(Archive log)，然后通过 解析日志信息来捕获变化数据，CDC 组件有一下特点: 通过读取日志而不是直接读取业务事务数据库来避免对业务系统的资源争用。 通过解析日志“拿出”必须的信息而不是搬出整个日志，避免过多的 I/O 的

消耗。
日志的解析和后续的变化数据的处理都是在 CDC 专用服务器上来进 行，对业务系统影响达到最小秒级日志读取以及变化数据捕获。灵活的数据变化机制，有利于后期的数据管理和维护。

• 数据质量控制设计  
• 控制流程

　　数据仓库的源数据来自于各个业务源系统，因此数据进入数据仓库环境的第一 种方式是通过源系统。所以为获得“干净”的源数据，首先应规范生产系统中的数 据录入，对于新录入到系统中的数据需要进行严格审查，从源头上保障数据质量。 其次就是进行监控，时刻保证数据的一致性，时刻从不同纬度保证数据的完整性和 准确性。数据质量监控流程如下图所示:

 

 

•  数据质量控制流程示意

　　

(l)定义数据质量标准

对于不同的源系统，不同的移植环节,数据的要求是不同的,因此,数据质量标 准也是不同的需要结合实际情况,合理制定各阶段数据质量标准。

(2)评价源数据质量

通过编写程序如 SQL 语句等方法统计源数据的质量指标结果得分,可以编写 SQL 语句统计不满足完整性条件的所有账户信息数量,把完整的账户数除以所有的 账户,得到账户的数据质量指标结果

(3)如果源数据评价得到的数据质量指标结果高于数据质量指标目标,则进行 数据移植，否则分析数据质量产生原因，根据需要进行分析和改进。

(4)分析数据质量产生原因

数据质量产生的原因有多种多样,可能是数据本身的问题,也可能是数据移植 程序产生的问题,需要进行详细分析

(5)采取改进措施,再次评价源数据的质量,直到数据质量高于数据质量标准为 止

(6)进行数据移植,将源数据移植到目标文件或系统中,流程结束。

 监控指标 我们这里所说的抽取结果质量监控主要是针对抽取到的数据与数据源的数据

之间一个量的比较。在对数据源抽取过程中 ,由于无法避免的突发事件、某些不确 定因素和各种系统异常的出现,很有可能导致抽取的结果与源数据不一致,比如进 程的异常终止、读写数据库的操作失败、网络的阻塞抖动导致数据包的丢失等,这 些都将导致抽取数据的失败或错误,很有可能产生诸如抽取的记录数目不匹配、 记 录重复抽取、字段缺漏、字段内容出错等错误,因此对抽取结果的监控是不可或缺 的。对抽取结果质量的监控总体来说不是很复杂,也不会牵涉到源数据等内容,主要 对以下几个大的方面进行监控即可:

表及文件结构监控,结构监控是指对数据表的结构或文件结构监控。

记录数监控,是监控中最重要的判断依据,源与目标的记录数相等是抽取的最 终结果,否则就算其它方面的检验都通过,该次抽取也是毫无意义的。

关键字段汇总监控,这是一种抽样检验,通常是对重要或敏感类的字段进行汇 总监控,源与目标在记录数目或总和上都要保持一致才算抽取成功。

数据字段计算监控,即所有记录中该字段的计算总和是否一致。如果表中有数 据类型字段,并且数据对业务非常重要和敏感的话,对这类字段的监控是不能省略 的,监控的目标是验证抽取结果中该字段的计算和是否与源字段的记录和一致。

以上的抽取流程并非每一步都需要按步就班执行,取舍与否关键是看业务需求 及其性质 ,比如有的只关心字段的计算总和、有的只关心记录总条数是否相同等, 如果能获得这种正确的信息对用户来说已经足够的话,就无需其它方面的验证了。  后台监控

综合我们对数据采集过程遇到的数据质量问题以及数据质量管理理论，我们开 发了一套数据仓库后台管理系统，专门用于监控数据采集过程，发掘数据质量问题， 定位数据异常，改善数据仓库数据质量。数据仓库后台管理系统主要包括三个方面， 即查询系统设置、ETL 数据逻辑维护和验证功能。系统运行操作流程是首先进行设 置查询系统，再进行 ETL 设置维护，进而查看 ETL 校验验证结果。

我们可以查看系统的验证结果在差异列表中，根据不同的异常我们进行相应的 处理。其他异常汇总表如下:

 

在异常汇总表中点击下钻，科研查询到具体的验证方法: 1)行数验证，从源系统抽取数据的条数与数据仓库中条目数进行比较，看其

是否相等。 2)字段验证，管理的目标是验证抽取结果中该字段的计算和是否与源字段的

记录和一致。 3)指标验证，源系统中指标与抽取到数据仓库中的指标进行比对，验证其指

标是否一致。

 电子病历存储库 电子病历是由医疗机构以电子化方式创建、保存和使用的，重点针对门诊、住

院患者(或保健对象)临床诊疗和指导干预信息的数据集成系统。是居民个人 在 医疗机构历次就诊过程中产生和被记录的完整、详细的临床信息资源。

与某一具体临床活动相关的临床活动的信息与数据记录形成了相对独立的 电 子病历(EMR)文档。而在临床活动过程中产生的对医疗活动的文字、图像、 或多 媒体的电子格式记录文档均称之为 EMR 文档。

EMR 文档集:由多个 EMR 文档组成的一组与某个临床业务活动相关的文档 集 合称为 EMR 文档集。

电子病历存储服务具体由临床数据存储库 CDR(Clinical Data Repository) 来 实现。

 EMR 文档标准
2009 年 12 月 31 日卫生部颁布了《电子病历基本架构与数据标准(试行)》。

它是我国卫生领域制定、发布的首部国家级具有中西医结合特点的电子病历业务 架构基本规范和数据标准。主要包括两部分内容，第一部分是“电子病历基本架 构”，包括(1)电子病历的基本概念和系统架构，(2)电子病历的基本内容和 信 息来源;第二部分是“电子病历数据标准”，包括(3)电子病历数据结构，(4)电 子病历临床文档信息模型，(5)电子病历临床文档数据组与数据元标准，(6)电子 病历临床文档基础模板与数据集标准。EMR 文档应当从内容与架构上 遵循《电子 病历基本架构与数据标准》的要求。

EMR 文档本身采用何种存储结构本身取决于各个供应商自行定义，但作为电子 病历我们需要将 EMR 文档实现 CDR(Clinical Data Repository)存储服务模式。在 基于电子病历的医院信息平台建设时我们建议 EMR 文档格式应当建议遵循 HL7 CDA 标准。HL7 临床文档架构(Clinical Document Architecture，CDA)是一项 基于 XML 的标记标准，旨在规定用于交换的临床文档的编码、结构和语义。CDA 基 于 HL7 参考信息模型(Reference Information Model，RIM)以及第 3 版 HL7 数据 类型(Data Types)。CDA 文档在本质上具有持久性。CDA 标准规定，CDA 文档内 容由强制性的文本部分和可选性的结构化部分构成;其中，前者 保证的是对于文 档内容的人工解释，而后者则旨在用于软件处理。结构化部分依 赖于各种编码系 统(coding systems)来表示概念，如医学术语系统命名法( Systematized Nomenclature of Medicine,SNOMED)和 LOINC(Logical Observation Identifiers

Names and Codes)。

 EMR 文档的基本内容
根据 2010 年 3 月颁布的《电子病历基本规范(试行)》规定，电子病历包括

门(急)诊电子病历、住院电子病历及其他电子医疗记录。电子病历内容应当按 照 卫生部《病历书写基本规范》执行。电子病历的基本内容由门(急)诊病历与 住 院病历两部分组成。

门(急)诊病历内容包括门(急)诊病历首页(门(急)诊手册封面)、病 历 记录、化验单(检验报告)、医学影像检查资料等。

住院病历内容包括住院病案首页、入院记录、病程记录、手术同意书、麻醉 同 意书、输血治疗知情同意书、特殊检查(特殊治疗)同意书、病危(重)通知 书、 医嘱单、辅助检查报告单、体温单、医学影像检查资料、病理资料等。

各项书写内容的详细规定详见 2010 年 3 月 1 日开始实施的《病历书写基本 规范》。

 EMR 文档类型
EMR 文档包含的各类临床活动描述的信息与数据，其信息与内容的描述形 式

总的来说可以分为结构化、非结构化、多媒体(含扫描病历)或这三种形式的 混 合体。

结构化 EMR 文档是指在对临床信息进行记录时，所包含的临床信息包含各 种 可识别的临床知识内容，每一个元素节点都有对应的清楚临床知识定义，能够 被 临床知识分析或科研作为一个临床信息进行分析。

非结构化 EMR 文档指临床信息由自然语言或字符串组成，未进行临床知识 标 识，只能进行全文检索或者自然语言处理引擎进行分析和利用的 EMR 文档。

多媒体 EMR 文档指文档内包含图像、动画、视频、声音等多媒体文件。 通常 在 EMR 文档中可能是这三种形式的混合体。

 EMR 文档结构 电子病历主要由临床文档组成，临床文档是电子病历中各类业务活动记录的

基本形式。临床文档中的数据存在着一定的层级结构关系，其中有包含与被包含 的关系，也有按同类属性相互嵌套的关系。临床文档的结构化和标准化，是电子 病历实现语义层数据交换与共享的基本要求。

电子病历数据结构用于规范描述电子病历中数据的层次结构关系，即电子病 历从临床文档到数据元的逐步分解、或从数据元到临床文档的逐步聚合关系。

电子病历数据结构分为四层: (1)临床文档:位于电子病历数据结构的最顶层，是由特定医疗服务活动 (卫生事件)产生和记录的患者(或保健对象)临床诊疗和指导干预信息的

数据 集合。如:门(急)诊病历、住院病案首页、会诊记录等。 (2)文档段:结构化的临床文档一般可拆分为若干逻辑上的段，即文档段。

文档段为构成该文档段的数据提供临床语境，即为其中的数据元通用定义增加特 定的约束。结构化的文档段一般由数据组组成，并通过数据组获得特定的定义。 本标准中未明确定义文档段，但隐含了文档段概念。

(3)数据组:由若干数据元构成，作为一个数据元集合体构成临床文档的 基 本单元，具有临床语义完整性和可重用性特点。数据组可以存在嵌套结构，即 较 大的数据组中可包含较小的子数据组。如:文档标识、主诉、用药等。

(4)数据元:位于电子病历数据结构的最底层，是可以通过定义、标识、 表 示和允许值等一系列属性进行赋值的最小、不可再细分的数据单元。数据元的 允 许值由值域定义。

电子病历数据结构

 

EMR 文档作为重要的患者临床信息的重要载体，应当遵从《电子病历基本 架 构与数据标准》数据内容框架及数据元定义。并以符合 HL7 CDA 标准作为组织 EMR 文档的结构机构实现文档存储或者以符合 HL7 CDA 标准实现 EMR 文档的组 织。

EMR 文档存储应当以患者为中心，围绕患者的所发生的实际临床业务活动 组织文档，基于已注册的 EMR 文档分类进行文档的分类、标识。平台业务用户 可 根据实际授权情况进行 EMR 文档的全部、部分、单个文档的调阅与应用。

•  临床数据存储库

临床数据中心(CDR)是 EMR 文档存储中心，它 将一个患者在某一医疗机 构内发生的所有临床活动所产生的临床文档集中存储 在一个物理或虚拟的存储 内，方便各种临床业务角色在使用该患者某一或某些临 床活动的 EMR 文档时进 行调阅。

CDR 是所有的病人医疗结果和其他临床数据的一个中心存储仓库，而且是在电子病历的中心。单个病人信息随着时间的增加信息量也随之增长，为了可长 期获得该病人的信息，需要对其信息进行长期存储。这时，就出现异构下的数据 的长期管理问题。而医疗文档库，就是把医院信息系统中各个业务系统的数据库 的信息抽取出去，通过归档的形式形成一个静态的文档，把它放在中间的文档库。 来自多个系统、由不同厂家建立的，全部收集起来归入文档库。CDR 对于电子 病 历来讲是一个非常核心的部件。CDR 是一个面向主题的、集成的、可变的、 当 前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的 需求。

A.以患者为中心的 EMR 文档存储

患者在某一医疗机构内发生的各类临床活动形成的 EMR 文档集应当在患者 主索引(MPI)的指引下进行汇总归集，并通过 MPI 完成 EMR 浏览器及非电子病 历编辑器环境下的患者 EMR 文档浏览。

B.EMR 文档数据来源

所有的临床活动所产生的信息记录均为 EMR 文档的数据来源，基于电子病历 的医院信息平台将各个系统中产生的临床活动数据与信息进行集成与共享后，通 过生成规定格式的 EMR 文档进行归档与储存。与临床业务活动相关的各部分数据 分别来源于基于平台上的各个分子系统，把反映临床业务活动的最终状态的数据 进行集中、集成后统一合并到 EMR 文档中。

 

 

 

C.EMR 文档注册
每一类需要在临床文档仓库中进行存储的 EMR 文档都需要在 CDR 中进行注

册。并且还需要在 CDR 中注册其文档的模板信息与数据。而在实际临床业务 活 动发生过程中所产生的 EMR 文档都能够通过注册系统对应其使用的文档模板信 息与数据。

EMR 文档产生并完成注册后，随着临床业务活动的发生逐个生成 EMR 文档 并通过 CDR 进行存储。

D.临床数据存储库与临床文档存储库

EMR 文档以符合 HL7 CDA 的文档结构的方式产生后按照以患者为中心的 索引方式进行存储，形成临床数据存储库。由于患者的临床数据是以 EMR 文档 的方式进行存储并以 HL7 CDA 的方式进行组织，这样组织的存储方式也称之为 临床文档存储库。临床文档存储库(Clinical Document Repository，CDR)是 临床数据存储库(CDR Clinical Data Repository)的表现形式之一，并非唯一 表现 形式。

E.EMR 文档版本管理

患者的临床业务活动的发生时一个持续并且连续的过程，并且主观描述部 分，或者非数据接口内的数据内容会因为某些特定条件下发生修订或者修改，这 是 EMR 文档作为临床活动发生情景的真实记录数据应当能够客观的反应出各种 主客观数据或者描述的变化与修改过程，这时就对 EMR 文档提出了文档版本的 管理要求。

EMR 文档版本管理应当支持文档变化的痕迹跟踪，以及痕迹审计。反应出 EMR 文档在不同提交时间戳时的文档实际状态。