数据源层数据源是整个数据中心信息资源的基础，数据源内容主要来自于三大类业务数
据:临床服务数据、医疗管理数据以及运营管理数据。A.临床服务数据
临床服务数据主要是以患者为中心的临床诊疗活动全过程数据。数据源主要来自于门急诊挂号系统、门诊医生工作站、分诊管理系统、住院病人入出转系统、住院医生工作站、住院护士工作站、电子病历系统、合理用药管理系统、临床检验系统、医学影像系统、超声/内镜/病理管理系统、手术麻醉管理系统、临床路径管理系统、输血管理系统、重症监护系统、心电管理系统、体检管理系统等临床业务系统。
B.医疗管理数据
医疗管理数据主要是医院医疗活动和医疗费用全过程数据，保障医院医疗活动的质量和安全，合理控制医疗费用。数据源主要来自于门急诊收费系统、住院收费系统、护理管理系统、医务管理系统、院感/传染病管理系统、科研教学管理系统、病案管理系统等医疗管理系统。
C.运营管理数据
运营管理数据主要是医院“物流、资金流、信息流、业务流”的统一运营管理数据。数据源主要来自于人力资源管理系统、财务管理系统、药品管理系统、设备材料管理系统、物资供应管理系统、预算管理系统。ODS层
利用ODS，我们即可以允许历史数据在保存周期中进行更新，又可以随时对现有监测数据进行分析，满足应急性分析需求。数据从业务库抽取出来装载到ODS后，从ODS中根据主题模型进行数据清洗和转换从而完成建立数据集市之前的数据准备工作。主题聚合层
主题聚合层基于ODS层，主题数据从ODS中经过抽取、清洗、转换、加载，并按照分析主题进行数据模型的建设和组织。根据业务分析的主题可以包括:医院经
数据管理功能对于整个数据中心非常重要，这涉及到数据质量、监管、维护、数据安全等多方面内容。对于医疗数据中心的数据管理方面，需要建立一套统一的技术标准体系和技术平台。数据管理的统一化、平台化，可以更好地完成数据管理工作，更好的为数据应用提供支撑。
统一的数据存储关于数据的存储，从应用的角度进行设计，即数据存储的设计满足各类业务的
应用需求，支持存储结构与非结构性的数据，同时兼顾数据扩展和性能要求。通过对数据的分类管理，将数据存储到不同的区域内，以满足各项应用要求，如下表所示:
数据存储库说明
A.标准化存储基于主数据管理，形成医学信息标准构成内容丰富的受控术语词汇域，词汇域
B.模型化存储
以患者EMPI为主线组织患者的临床数据，构建病人基本信息、就诊记录、门诊处方、住院医嘱、电子病历、检查化验报告、手术麻醉等数据模型，将患者的所有医疗信息，如就诊记录、门诊处方、住院医嘱、电子病历、检查化验报告等模型化存储。以全面、标准、统一的方式实现患者临床结构化、非结构化数据的整合存储，临床数据的共享提供了统一的平台支撑。最终实现辅助改善医疗服务质量、较少医疗差错、提高临床诊疗水平，为决策提供支持信息和降低医疗成本。
统一的数据处理引擎统一的数据处理引擎是数据从数据源到数据中心整个ETL过程通过统一的数
据处理机制和流程对数据流转进行控制。包括ETL调度、错误处理、过程监控、数据抽取、转换、加载等功能的统一化、流程化。
数据处理引擎可以通过专业的ETL工具实现，也可以自行编写代码实现。对数据处理过程统一的主要目的是要规范数据ETL过程，易于数据管理和控制。同时可保证数据出自一处，避免数据二义性，出现数据质量问题。统一的元数据管理
元数据管理可通过专业工具实现，也可以通过初始化数据表方式实现。通过管理平台的元数据查询功能，实现对元数据管理，并通过统一管理方式对业务元数据和技术元数据进行管理。统一的数据访问面向不同应用，数据中心提供了多种数据服务，包括基于标准的数据共享、Webservice等方式。对数据访问服务提供访问接口的规范化和统一化，并对外公开数据服务接口，实现数据服务统一化。
采集方式
A.数据发布和订阅
通过发布订阅的方式实现数据库之间的同步操作。发布订阅份为两个步骤:发布和订阅。首先在数据源数据库服务器上对需要同步的数据进行发布，然后在目标数据库服务器上对上述发布进行订阅。发布可以发布一张或多张表的全部数据，也可以对部分表的部分数据进行发布。发布、订阅的过程如下:
数据的发布:发布需要用实际的服务器名称，发布的信息包括表中数据新增、修改、删除信息，同时对业务系统数据结构的变化能及时通知数据仓库进行自动变更操作。
数据的订阅:订阅是对数据库发布的快照进行同步，将发布的数据源数据同步到目标数据库，实现数据库或者表数据源的自动同步。
B.ETL方式数据自动抽取
对数据进行ETL的目的是保证数据的质量，进而根据不同业务分析需求将历史数据按照不同的分析维度来进行汇总，以便为业务决策提供某个维度的信息支持。ETL的过程就是数据流动的过程，包括数据的抽取、清洗、转换和装载等过程。抽取工作通过工具KETTLE开发抽取包完成。
ETL过程存在主外键约束，对无依赖性的非法数据，可替换或导出到错误数据文件中，保证主键唯一记录的加载。
1)数据抽取
数据抽取就是从数据源中获取数据(无论是何种格式)的过程。这个过程有两种方式:全量抽取、增量抽取。
全量抽取:全量抽取类似于数据迁移或数据复制，它将数据源中的表或视图的数据原封不动的从数据库中抽取出来，并转换成自己的ETL工具可以识别的格式。全量抽取比较简单。
增量抽取:增量抽取指抽取自上次抽取以来数据库中要抽取的表中新增、修改、删除的数据。如何捕获变化的数据是增量抽取的关键，目前增量数据抽取中用的捕
获变化数据的方法有:2)数据清洗
清洗就是把“脏”的“洗掉”，指发现并纠正数据文件中可识别的错误的最后一道程序，包括检查数据一致性，处理无效值和缺失值等。因为数据仓库中的数据是面向某一主题的数据的集合，这些数据从多个业务系统中抽取而来而且包含历史数据，这样就避免不了有的数据是错误数据、有的数据相互之间有冲突，这些错误的或有冲突的数据显然是我们不想要的，称为“脏数据”。我们要按照一定的规则把“脏数据”“洗掉”，这就是数据清洗。而数据清洗的任务是过滤那些不符合要求的数据，将过滤的结果交给业务主管部门，确认是否过滤掉还是由业务单位修正之后再进行抽取。不符合要求的数据主要是有不完整的数据、错误的数据、重复的数据三大类。
3)数据转换
数据转化通常是指数据从非结构化的数据，按照设定的规则转换为结构化的过程，转换通常不仅仅是数据格式的转换，业务系统数据可能包含不一致或者不正确的信息，这些操作也包含在转换的步骤中.
4)数据抽取管理
A.数据由业务系统到数据仓库(ODS)
2.患者基本信息、就诊情况、处方、医嘱、病历、体检、手术、麻醉等信息:对实时性要求不高的数据，采用ETL数据抽取方式实现数据抽取到ODS中。此机制中针对历史数据，将通过ETL方式全量一次性抽取到ODS中。对新增数据，结合使
B.数据仓库(ODS)到数据中心
最小可控性强，续传能力好B.CDCCDC是变化数据捕获(ChangeDataCapture),CDC一般通过读取事务日志
(Archivelog)，然后通过解析日志信息来捕获变化数据，CDC组件有一下特点:通过读取日志而不是直接读取业务事务数据库来避免对业务系统的资源争用。通过解析日志“拿出”必须的信息而不是搬出整个日志，避免过多的I/O的
消耗。日志的解析和后续的变化数据的处理都是在CDC专用服务器上来进行，对业务系统影响达到最小秒级日志读取以及变化数据捕获。灵活的数据变化机制，有利于后期的数据管理和维护。
数据仓库的源数据来自于各个业务源系统，因此数据进入数据仓库环境的第一种方式是通过源系统。所以为获得“干净”的源数据，首先应规范生产系统中的数据录入，对于新录入到系统中的数据需要进行严格审查，从源头上保障数据质量。其次就是进行监控，时刻保证数据的一致性，时刻从不同纬度保证数据的完整性和准确性。数据质量监控流程如下图所示:
(l)定义数据质量标准
对于不同的源系统，不同的移植环节,数据的要求是不同的,因此,数据质量标准也是不同的需要结合实际情况,合理制定各阶段数据质量标准。
(2)评价源数据质量
通过编写程序如SQL语句等方法统计源数据的质量指标结果得分,可以编写SQL语句统计不满足完整性条件的所有账户信息数量,把完整的账户数除以所有的账户,得到账户的数据质量指标结果
(3)如果源数据评价得到的数据质量指标结果高于数据质量指标目标,则进行数据移植，否则分析数据质量产生原因，根据需要进行分析和改进。
(4)分析数据质量产生原因
数据质量产生的原因有多种多样,可能是数据本身的问题,也可能是数据移植程序产生的问题,需要进行详细分析
(5)采取改进措施,再次评价源数据的质量,直到数据质量高于数据质量标准为止
(6)进行数据移植,将源数据移植到目标文件或系统中,流程结束。
监控指标我们这里所说的抽取结果质量监控主要是针对抽取到的数据与数据源的数据
之间一个量的比较。在对数据源抽取过程中,由于无法避免的突发事件、某些不确定因素和各种系统异常的出现,很有可能导致抽取的结果与源数据不一致,比如进程的异常终止、读写数据库的操作失败、网络的阻塞抖动导致数据包的丢失等,这些都将导致抽取数据的失败或错误,很有可能产生诸如抽取的记录数目不匹配、记录重复抽取、字段缺漏、字段内容出错等错误,因此对抽取结果的监控是不可或缺的。对抽取结果质量的监控总体来说不是很复杂,也不会牵涉到源数据等内容,主要对以下几个大的方面进行监控即可:
表及文件结构监控,结构监控是指对数据表的结构或文件结构监控。
记录数监控,是监控中最重要的判断依据,源与目标的记录数相等是抽取的最终结果,否则就算其它方面的检验都通过,该次抽取也是毫无意义的。
关键字段汇总监控,这是一种抽样检验,通常是对重要或敏感类的字段进行汇总监控,源与目标在记录数目或总和上都要保持一致才算抽取成功。
数据字段计算监控,即所有记录中该字段的计算总和是否一致。如果表中有数据类型字段,并且数据对业务非常重要和敏感的话,对这类字段的监控是不能省略的,监控的目标是验证抽取结果中该字段的计算和是否与源字段的记录和一致。
以上的抽取流程并非每一步都需要按步就班执行,取舍与否关键是看业务需求及其性质,比如有的只关心字段的计算总和、有的只关心记录总条数是否相同等,如果能获得这种正确的信息对用户来说已经足够的话,就无需其它方面的验证了。后台监控
综合我们对数据采集过程遇到的数据质量问题以及数据质量管理理论，我们开发了一套数据仓库后台管理系统，专门用于监控数据采集过程，发掘数据质量问题，定位数据异常，改善数据仓库数据质量。数据仓库后台管理系统主要包括三个方面，即查询系统设置、ETL数据逻辑维护和验证功能。系统运行操作流程是首先进行设置查询系统，再进行ETL设置维护，进而查看ETL校验验证结果。
我们可以查看系统的验证结果在差异列表中，根据不同的异常我们进行相应的处理。其他异常汇总表如下:
在异常汇总表中点击下钻，科研查询到具体的验证方法:1)行数验证，从源系统抽取数据的条数与数据仓库中条目数进行比较，看其
是否相等。2)字段验证，管理的目标是验证抽取结果中该字段的计算和是否与源字段的
记录和一致。3)指标验证，源系统中指标与抽取到数据仓库中的指标进行比对，验证其指
标是否一致。
电子病历存储库电子病历是由医疗机构以电子化方式创建、保存和使用的，重点针对门诊、住
院患者(或保健对象)临床诊疗和指导干预信息的数据集成系统。是居民个人在医疗机构历次就诊过程中产生和被记录的完整、详细的临床信息资源。
电子病历存储服务具体由临床数据存储库CDR(ClinicalDataRepository)来实现。
EMR文档标准2009年12月31日卫生部颁布了《电子病历基本架构与数据标准(试行)》。
EMR文档本身采用何种存储结构本身取决于各个供应商自行定义，但作为电子病历我们需要将EMR文档实现CDR(ClinicalDataRepository)存储服务模式。在基于电子病历的医院信息平台建设时我们建议EMR文档格式应当建议遵循HL7CDA标准。HL7临床文档架构(ClinicalDocumentArchitecture，CDA)是一项基于XML的标记标准，旨在规定用于交换的临床文档的编码、结构和语义。CDA基于HL7参考信息模型(ReferenceInformationModel，RIM)以及第3版HL7数据类型(DataTypes)。CDA文档在本质上具有持久性。CDA标准规定，CDA文档内容由强制性的文本部分和可选性的结构化部分构成;其中，前者保证的是对于文档内容的人工解释，而后者则旨在用于软件处理。结构化部分依赖于各种编码系统(codingsystems)来表示概念，如医学术语系统命名法(SystematizedNomenclatureofMedicine,SNOMED)和LOINC(LogicalObservationIdentifiers
NamesandCodes)。
EMR文档的基本内容根据2010年3月颁布的《电子病历基本规范(试行)》规定，电子病历包括
门(急)诊电子病历、住院电子病历及其他电子医疗记录。电子病历内容应当按照卫生部《病历书写基本规范》执行。电子病历的基本内容由门(急)诊病历与住院病历两部分组成。
门(急)诊病历内容包括门(急)诊病历首页(门(急)诊手册封面)、病历记录、化验单(检验报告)、医学影像检查资料等。
住院病历内容包括住院病案首页、入院记录、病程记录、手术同意书、麻醉同意书、输血治疗知情同意书、特殊检查(特殊治疗)同意书、病危(重)通知书、医嘱单、辅助检查报告单、体温单、医学影像检查资料、病理资料等。
各项书写内容的详细规定详见2010年3月1日开始实施的《病历书写基本规范》。
EMR文档类型EMR文档包含的各类临床活动描述的信息与数据，其信息与内容的描述形式
总的来说可以分为结构化、非结构化、多媒体(含扫描病历)或这三种形式的混合体。
结构化EMR文档是指在对临床信息进行记录时，所包含的临床信息包含各种可识别的临床知识内容，每一个元素节点都有对应的清楚临床知识定义，能够被临床知识分析或科研作为一个临床信息进行分析。
非结构化EMR文档指临床信息由自然语言或字符串组成，未进行临床知识标识，只能进行全文检索或者自然语言处理引擎进行分析和利用的EMR文档。
多媒体EMR文档指文档内包含图像、动画、视频、声音等多媒体文件。通常在EMR文档中可能是这三种形式的混合体。
EMR文档结构电子病历主要由临床文档组成，临床文档是电子病历中各类业务活动记录的
基本形式。临床文档中的数据存在着一定的层级结构关系，其中有包含与被包含的关系，也有按同类属性相互嵌套的关系。临床文档的结构化和标准化，是电子病历实现语义层数据交换与共享的基本要求。
电子病历数据结构用于规范描述电子病历中数据的层次结构关系，即电子病历从临床文档到数据元的逐步分解、或从数据元到临床文档的逐步聚合关系。
电子病历数据结构分为四层:(1)临床文档:位于电子病历数据结构的最顶层，是由特定医疗服务活动(卫生事件)产生和记录的患者(或保健对象)临床诊疗和指导干预信息的
数据集合。如:门(急)诊病历、住院病案首页、会诊记录等。(2)文档段:结构化的临床文档一般可拆分为若干逻辑上的段，即文档段。
文档段为构成该文档段的数据提供临床语境，即为其中的数据元通用定义增加特定的约束。结构化的文档段一般由数据组组成，并通过数据组获得特定的定义。本标准中未明确定义文档段，但隐含了文档段概念。
(3)数据组:由若干数据元构成，作为一个数据元集合体构成临床文档的基本单元，具有临床语义完整性和可重用性特点。数据组可以存在嵌套结构，即较大的数据组中可包含较小的子数据组。如:文档标识、主诉、用药等。
(4)数据元:位于电子病历数据结构的最底层，是可以通过定义、标识、表示和允许值等一系列属性进行赋值的最小、不可再细分的数据单元。数据元的允许值由值域定义。
电子病历数据结构
EMR文档作为重要的患者临床信息的重要载体，应当遵从《电子病历基本架构与数据标准》数据内容框架及数据元定义。并以符合HL7CDA标准作为组织EMR文档的结构机构实现文档存储或者以符合HL7CDA标准实现EMR文档的组织。
临床数据中心(CDR)是EMR文档存储中心，它将一个患者在某一医疗机构内发生的所有临床活动所产生的临床文档集中存储在一个物理或虚拟的存储内，方便各种临床业务角色在使用该患者某一或某些临床活动的EMR文档时进行调阅。
A.以患者为中心的EMR文档存储
患者在某一医疗机构内发生的各类临床活动形成的EMR文档集应当在患者主索引(MPI)的指引下进行汇总归集，并通过MPI完成EMR浏览器及非电子病历编辑器环境下的患者EMR文档浏览。
C.EMR文档注册每一类需要在临床文档仓库中进行存储的EMR文档都需要在CDR中进行注
册。并且还需要在CDR中注册其文档的模板信息与数据。而在实际临床业务活动发生过程中所产生的EMR文档都能够通过注册系统对应其使用的文档模板信息与数据。
EMR文档产生并完成注册后，随着临床业务活动的发生逐个生成EMR文档并通过CDR进行存储。
D.临床数据存储库与临床文档存储库
EMR文档以符合HL7CDA的文档结构的方式产生后按照以患者为中心的索引方式进行存储，形成临床数据存储库。由于患者的临床数据是以EMR文档的方式进行存储并以HL7CDA的方式进行组织，这样组织的存储方式也称之为临床文档存储库。临床文档存储库(ClinicalDocumentRepository，CDR)是临床数据存储库(CDRClinicalDataRepository)的表现形式之一，并非唯一表现形式。
E.EMR文档版本管理
患者的临床业务活动的发生时一个持续并且连续的过程，并且主观描述部分，或者非数据接口内的数据内容会因为某些特定条件下发生修订或者修改，这是EMR文档作为临床活动发生情景的真实记录数据应当能够客观的反应出各种主客观数据或者描述的变化与修改过程，这时就对EMR文档提出了文档版本的管理要求。