具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本申请公开的内容相关的本领域的普通技术人员而言，在本申请揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本申请公开的内容不充分。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显式地和隐式地理解的是，本申请所描述的实施例在不冲突的情况下，可以与其它实施例相结合。

除非另作定义，本申请所涉及的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本申请所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块(单元)的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本申请所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本申请所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。

本实施例提供了一种移动终端。图1是根据本申请实施例的移动终端的结构框图。如图1所示，该移动终端包括：射频(Radio Frequency，简称为RF)电路110、存储器120、输入单元130、显示单元140、传感器150、音频电路160、无线保真(wireless fidelity，简称为WiFi)模块170、处理器180、以及电源190等部件。本领域技术人员可以理解，图1中示出的移动终端结构并不构成对移动终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图1对移动终端的各个构成部件进行具体的介绍：

RF电路110可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器180处理；另外，将设计上行的数据发送给基站。通常，RF电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low NoiseAmplifier，简称为LNA)、双工器等。此外，RF电路110还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(Global System of Mobile communication，简称为GSM)、通用分组无线服务(GeneralPacket Radio Service，简称为GPRS)、码分多址(Code Division Multiple Access，简称为CDMA)、宽带码分多址(Wideband Code Division Multiple Access，简称为WCDMA)、长期演进(Long Term Evolution，简称为LTE)、电子邮件、短消息服务(Short MessagingService，简称为SMS)等。

存储器120可用于存储软件程序以及模块，处理器180通过运行存储在存储器120的软件程序以及模块，从而执行移动终端的各种功能应用以及数据处理。存储器120可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据移动终端的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元130可用于接收输入的数字或字符信息，以及产生与移动终端的用户设置以及功能控制有关的键信号输入。具体地，输入单元130可包括触控面板131以及其他输入设备132。触控面板131，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板131上或在触控面板131附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板131可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器180，并能接收处理器180发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板131。除了触控面板131，输入单元130还可以包括其他输入设备132。具体地，其他输入设备132可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元140可用于显示由用户输入的信息或提供给用户的信息以及移动终端的各种菜单。显示单元140可包括显示面板141，可选的，可以采用液晶显示器(LiquidCrystal Display，简称为LCD)、有机发光二极管(Organic Light-Emitting Diode，简称为OLED)等形式来配置显示面板141。进一步的，触控面板131可覆盖显示面板141，当触控面板131检测到在其上或附近的触摸操作后，传送给处理器180以确定触摸事件的类型，随后处理器180根据触摸事件的类型在显示面板141上提供相应的视觉输出。虽然在图1中，触控面板131与显示面板141是作为两个独立的部件来实现移动终端的输入和输入功能，但是在某些实施例中，可以将触控面板131与显示面板141集成而实现移动终端的输入和输出功能。

移动终端还可包括至少一种传感器150，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板141的亮度，接近传感器可在移动终端移动到耳边时，关闭显示面板141和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别移动终端姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于移动终端还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路160中的扬声器161，传声器162可提供用户与移动终端之间的音频接口。音频电路160可将接收到的音频数据转换后的电信号，传输到扬声器161，由扬声器161转换为声音信号输出；另一方面，传声器162将收集的声音信号转换为电信号，由音频电路160接收后转换为音频数据，再将音频数据输出处理器180处理后，经RF电路110以发送给比如另一移动终端，或者将音频数据输出至存储器120以便进一步处理。

WiFi属于短距离无线传输技术，移动终端通过WiFi模块170可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图1示出了WiFi模块170，但是可以理解的是，其并不属于移动终端的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略，或者替换为其他的短距离无线传输模块，例如Zigbee模块、或者WAPI模块等。

处理器180是移动终端的控制中心，利用各种接口和线路连接整个移动终端的各个部分，通过运行或执行存储在存储器120内的软件程序和/或模块，以及调用存储在存储器120内的数据，执行移动终端的各种功能和处理数据，从而对移动终端进行整体监控。可选的，处理器180可包括一个或多个处理单元；优选的，处理器180可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器180中。

移动终端还包括给各个部件供电的电源190(比如电池)，优选的，电源可以通过电源管理系统与处理器180逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，移动终端还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本实施例中，处理器180被配置为：确定数据采集方式，所述数据采集方式包括：利用数据接口采集、利用复制订阅的方式采集以及利用SSIS的方式采集；利用数据采集管理系统，按照所述采集方式从数据中心采集各医院信息系统的各个应用子系统的原始数据，并将采集到的原始数据进行数据清洗和数据转换，将得到的目标数据进行分类存储，所述数据采集管理系统具有如下功能：数据采集、采集脚本配置、采集调度与监控、消息持久化、主被动群集模式、数据验证服务、数据错误处理机制、消息跟踪机制、连接重建机制、消息重发机制、重复消息检测机制、错误消息验证机制、错误应答处理机制、基于数据中心的数据访问服务、运维监控、通知机制以及监测列表，所述数据清洗表示过滤不符合要求的数据，所述数据转换包括不一致数据的转换、数据粒度的转换以及商务规则的转换。

本实施例提供了一种数据处理方法。图2是根据本申请实施例的数据处理方法的流程图，如图2所示，该流程包括如下步骤：

步骤S201，确定数据采集方式，数据采集方式包括：利用数据接口采集、利用复制订阅的方式采集以及利用SSIS的方式采集。

步骤S202，利用数据采集管理系统，按照所述采集方式从数据中心采集各医院信息系统的各个应用子系统的原始数据，并将采集到的原始数据进行数据清洗和数据转换，将得到的目标数据进行分类存储，所述数据采集管理系统具有如下功能：数据采集、采集脚本配置、采集调度与监控、消息持久化、主被动群集模式、数据验证服务、数据错误处理机制、消息跟踪机制、连接重建机制、消息重发机制、重复消息检测机制、错误消息验证机制、错误应答处理机制、基于数据中心的数据访问服务、运维监控、通知机制以及监测列表，所述数据清洗表示过滤不符合要求的数据，所述数据转换包括不一致数据的转换、数据粒度的转换以及商务规则的转换。

通过上述步骤，可按照所述采集方式从数据中心采集各医院信息系统的各个应用子系统的原始数据，并将采集到的原始数据进行数据清洗和数据转换，将得到的目标数据进行分类存储，通过对数据进行处理，解决了相关技术中不能对异常数据进行处理的问题。

图3是根据本申请实施例的数据处理方案的示意图，结合图3，下面通过优选实施例对本申请实施例进行描述和说明。

1，数据接口开发。

数据接口来自CDR(临床数据中心)与HRP平台内系统，目的是由“人、财、物”的投入有机体，在时间轴上的变化，形成一组产出。通过产出在经济效益和社会效益上的分析，来整合“人、财、物”的投入，进而改进运营体系。

本案使用的管理系统建设的特殊性之一在于，其建设标准和要求不仅取决于自身的业务需要和战略发展目标，同时必须采用大量的卫生部信息化建设要求、卫生部医政管理、临床质量控制规范等行业要求，也必须符合区域信息化建设的专业技术要求；同时，临床医学的循证医学的特征，医学技术一直处于不断融合与发展的状态，医院流程信息化改造和医学信息化持续发展是医院信息化建设的又一特殊之处。因此，医院的信息化建设的目标应该长期和短期目标结合与兼顾，结合医院各层面对信息化建设需求，概括为：

1)基于原有IT投入建立的数据集，利用商业智能(BI)技术，在数据中心平台基础上，成本核算系统与财务系统数据，建立以分析为目标的专科经营数据仓库(SpecialOperational Data Repository，SODR)；数据源数据按需推送到SODR，对接统一授权使用，保障数据安全性。

2)按照现代医院科学化、规范化和精细化的管理理念，依据管理制度，构建管理系统，实现管理层、职能部门与临床科室的数据利用，加强院内自下而上的信息沟通与反馈。

3)助力使用者高效处理岗位职责范围数据分析，进行运营分析、预算管理、资源配置、绩效管理和其它事项动态监测，便于及时发现异常情况，持续改进运营管理。

4)临床科室人员查阅本科室核心KPI指标数据，依照参考标准值给出警示灯提示，协助临床科室建设管理优化。

由于数据中心平台已经完成数据的采集、离散化和梳理，只需按要求提供给SODR，由SODR分主题集成、加载到相应的数据仓库中，构建各类管理运营、资源配置等统计分析报表体系，支持数据的深挖钻取，数据中心平台作为医院信息化的核心，将现有系统的数据离散化之后，重新组织成可以再利用的数据结构，同时整合成本核算系统与财务系统数据形成行政中心的数据平台，基于行政中心的数据平台实现集成应用。生成各类报表，然后再根据专科经营管理的指标内容进行统计分析。

数据接口管理模块主要包括数据接口编辑、数据接口管理、数据接口展示、数据接口测试以及数据接口维护等功能，同时提供数据接口生成服务，数据接口通用生成器服务以及数据接口部署服务：

1)接口编辑：获取模板代表的领域知识，依据领域知识来编辑数据接口信息。

2)数据接口管理：主要是进行数据接口基本信息进行查询，数据接口生命周期状态的管理以及版本管理，数据接口的生命周期状态有创建、发布、锁定以及弃用等。模板部署后基本数据接口初始状态为创建，对新部署的模板进行判断，如果没有部署过，将创建的基本数据接口更新为发布，如果是模板版本更新后部署，对模板与之前版本进行比较，如果兼容，基本数据接口上一版本更新为弃用，如果不兼容，上一版本更新为锁定，新创建的基本数据接口版本升级，状态更改为发布。用户自定义数据接口初始状态为创建，用户提交后，由管理员进行审核，通过将状态更改为发布，否决后返回创建状态，用户在巳经发布的数据接口上进行版本更新，将当前版本更改为弃用，新版本状态为创建，处于创建状态的数据接口用户可以自行修改。版本升级指在当前版本基础上增1，如从v1升级到v2。

3)数据接口展示：提供数据接口的在线说明文档，将数据接口信息解析，首先按照模板分类展示基于该模板的数据接口资源名称，根据资源名称和版本信息显示每个请求方式的说明文档，主要包括该请求方式的URL、输入参数、输出参数以及相关的描述信息。

4)数据接口测试：针对部署的数据接口，输入参数要求的参数值，向数据接口通用生成器服务发出HTTP请求，验证该数据接口的功能。

5)数据接口部署：将处于发布状态的数据接口信息部署，让数据接口通用生成器可以访问该数据接口信息从而生成数据接口。

6)数据接口维护：提供数据接口的维护功能，主要是为每个数据接口添加相应的中文描述信息，如为每个请求方式添加功能描述信息等。

7)数据接口生成服务：以RESTful web API的形式暴露给模型管理，当模板部署成功后，调用该接口按照上章基本数据接口生成方法生成相应的数据接口信息，按照版本管理约束进行版本管理，生命周期状态更新为发布。

8)数据接口通用生成服务：作为服务端处理每个部署的数据接口的请求，执行数据接口信息，从而动态实现RESTful web API。

2，数据采集管理(ETL)。

数据中心的原始数据采自各医院信息系统的各个应用子系统，采自各个应用子系统的各种临床诊疗、管理数据必须经过相关的处理、整理成为标准数据后分门别类进行存储，形成数据中心的各个资源数据库。管理中心信息平台数据采集的提取、转换、加载使用ETL工具实现。ETL负责数据抽取(Extract)、清洗(Cleaning)、转换(Transform)、装载(Load)等处理，是构建数据中心的重要一环。ETL将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理数据挖掘的基础。

2.1，数据采集系统。

数据采集工具ETL快速实现数据的提取、转换、加载和集成。根据业务需求在配置数据转换传输的ETL脚本，并测试脚本是否符合要求。上传脚本至ETL管理平台。通过ETL管理平台控制脚本启动、关闭等。

针对CDR数据，数据源在设计上比较容易。一般情况下，DBMS(SQLServer)会提供数据库链接功能，即通过数据的发布订阅，通过日志同步的方式进行数据同步，针对同步后的数据，使用sql脚本进行数据提取，在DW数据库服务器和原业务系统之间建立直接的链接关系就可以写Select语句直接访问。有一些Excel类型的其他数据文件，一般情况下通过ODBC的方式建立数据库链接——如SQL Server数据导入。如果不能建立数据库链接，可以有两种方式完成，一种是通过工具(SSIS)将源数据映射到数据库表中，然后再将这些源系统文件导入到ODS中。另外一种方法是通过程序接口来完成。

2.2，采集脚本配置。

采集脚本的配置首先需要设置医院各个业务系统或各医院数据中心的数据库链接。针对数据源的采集，系统有病历采集和SQL采集两种方式；SQL采集中，系统根据数据集标准内容编写SQL采集语句并保存配置，实现各医院业务数据库或医院数据中心结构与区域医疗数据中心数据集标准的匹配与对应。系统还针对不同采集模型设置不同采集时间，采集周期，从而错开各个业务模型数据采集时间点，避开系统运行高峰期，避免影响医院业务系统的运行。

2.3，采集调度与监控。

采集调度是根据对各个模型的采集周期进行集中管理，统一管理各个模型在各医院的采集时间，启动、停止各个采集模型。采集监控是对数据的采集过程进行监控，数据采集成功、失败明细情况监控，形成数据采集日志，对失败的数据采用重新采集，控制整体数据采集质量，并根据数据采集监控结果完善数据采集配置方案。

ETL中作业调度与监控实现方式如下，主要使用sql server代理服务进行服务调度与维护：调度系统参数维护，对调度系统的公共参数：任务类型、执行频率、频次、数据日期、本期开始日期和本期结束日期进行设置和修改；作业步定义与维护，定义作业对应的实际ETL处理过程，生成作业编号，定义作业类型和作业的驱动关系，作业的运行所需要的条件，或直接编写sql脚本作为作业内容；调度异常处理，对调度过程中出现的异常情况进行处理，提供错误查找、出错重跑功能。

同时配置可以执行的Job类型：ActiveX、操作系统(CMD的运行)、PowerShell、各种复制任务、SQL Server分析服务(SSAS)命令(例如XML/A)、SQL Server分析服务(SSAS)查询(MDX)、SQL Server集成服务(SSIS)包(SQL Server 2000li de DTS包)、T-SQL脚本。

同时可以对作业执行日志进行查看：调度日志，管理记录调度中的主要过程和异常信息，如调度开始、调度完成、数据库操作异常和读写文件异常的日志；Job执行日志，管理记录Job执行信息的日志，提供该日志的查询、删除和执行状态重置功能；Job详细事件日志，管理记录Job执行中的详细事件(清洗记录条数、数据库具体操作情况)的日志，提供对日志的查询、删除操作。

同时进行作业步(ETL_Step)的功能类型设置及数据处理：

1)文件注册：FTP的源数据文件，经过解压缩后，使用SSIS中的相关组件(或自主研发FTP文件解析服务)，ETL系统就可以相应的处理流程。

2)数据清洗：从FTP来的源数据文件，CDR同步数据中，可能存在非法数据或冗余数据或者数据规则标准不统一，而且文件格式上也不标准，从而无法被ETL过程立即使用，因此必须对数据文件进行数据清洗(删除非法、冗余数据、统一数据规则标准、转换成ETL过程能“加载”处理的文件格式)。

3)数据加载：将清洗后的数据(文件格式)通过Job加载到SQL SERVER数据库相应的数据库表中。

4)ODS数据合并：将各个分行的相同类型的源业务系统数据合并到SQL SERVER数据库中同一张数据表中。

5)PI加工：根据业务需求、业务规则和分析模型，从ODR数据表中加工出业务所需的PI。

6)报表加工：根据业务需求、业务规则和分析模型，从ODR数据表和PI表中中加工出业务所需的报表。

7)ETL调度程序：调度ETL加工各个过程的运行。

8)监控程序：监控ETL过程的运行状态(加工进度、加工效率、成功、警告、错误等)信息，及时向系统的运行维护人员报告系统运行状态。

其中作业步的流程和依存关系：

1)清洗类型的Job的运行依赖于相应数据源的状态，源数据通过触发器、日志分发等方式通知ETL系统后才能进行清洗Job的调度。

2)ODS层加载类型Job的运行依赖于相应的清洁文件是否由清洗程序生成，即相应的清洗Job是否正确运行完成。

3)从ODS到ODR的数据转换依赖ODS层的相关数据是否齐备，即相应的加载Job是否正确运行完成。

4)PI加工的进行依赖ODR层数据，即相应的转换Job是否正确运行完成。

5)根据数据依赖关系，分区域进行作业调度，各区域之间的ETL处理可以并行处理。

其中作业调度方式包括：

1)前导Job驱动，ETL过程中各个操作需按一定次序进行，前导Job表示ETL过程中先要进行处理的Job，Job的前导Job可以有多个。

2)时间驱动，当到达某个时点时，Job便开始运行。

3)上述条件综合驱动，要上述三种情况至少两种均满足，Job才能运行。

4)Job的并发设计，每个Job只要满足了驱动关系后，便开始以后台方式运行。这样便实现了不同区域和同一区域的Job的最大限度的并行。考虑系统资源的情况，可以事先设定最大并行数。

5)并发冲突设计，当并行跑的Job都需要共同使用同一资源的时候，会产生资源占用的冲突，ETL过程中通常的冲突，用令牌的方式来避免冲突，只有获得令牌的JOB才能跑，否则等待令牌释放。

最后定义数据转换流程中检查点和核对点：

1)文件，文件与源系统数据进行比较检查，核对下传数据准确性。

2)清洁文件，将清洁文件与下传文件进行比较检查，从而可判断清洗处理过程的正确性。

3)ODS库表，将ODS库表中的数据与下传文件中数据进行比较检查，从而可判断加载处理过程的正确性。

4)ODR库表，将LDM库表中的数据与ODS库表中数据进行比较检查，从而可判断转换处理过程的正确性。

5)PI值，将PI值与LDM层相关的库表进行比较检查，从而可判断PI计算处理过程的正确性。

日志信息设计：

1)调度过程日志。以文件的方式存在，用于记录Job调度中的主要过程和异常信息，如调度开始、调度完成、数据库操作异常和读写文件异常。

2)Job执行日志。数据库表方式存在，给Job的调度提供必要的信息，是Job调度策略计算的依据，调度模块和Job之间的接口之一。

3)Job详细事件日志。数据库表方式存在，记录ETL处理过程中的详细信息，如清洗记录成功条数、失败条数或数据库操作情况(INSERT\UPDATE\DELETE)。

给出异常处理设计：所有被拒绝的行、可接受的错误数以及合理退出的方式。

通知设计，重要信息(成功/失败)的通知：

成功退出：

1)分段提交方式，当分段提交的当次任务都正确完成，即Job运行状态临时表中登记的作业状态全部为完成时，退出ETL调度。

2)自动提交方式，当当期所有的任务都正确完成，即Job运行状态表中登记的作业状态全部为完成时，退出ETL调度。

2、失败退出：

1)关键作业异常，关键作业运行异常时，影响剩下的作业不能运行时，则退出ETL调度。

2)超过ETL时限，当超过预先设定的ETL时限时，退出ETL调度。

3)数据库异常，当不能正常操作数据库时，退出ETL调度。

4)操作系统异常，当发生操作系统异常，导致程序不能正常运行，如文件系统异常导致读写文件错时，需要退出ETL调度。

5)手工退出，需要人为干预ETL调度的时候，能以手工操作的方式退出ETL调度。

2.4消息持久化。

业务系统通过集成平台进行集成后，无论在是业务系统进行信息交换过程中，还是集成平台在进行消息处理过程中都有可能出现不同种类的异常情况。根据多年的经验，对集成运行过程中可能出现的问题进行全面的分析，并从集成平台产品和集成方案方面设计了多层次、多角度、多路径的异常处理机制，保证整个集成方案运行的可靠性和稳定性。

1)数据清洗：数据清洗的任务是过滤那些不符合要求的数据，将过滤的结果交给业务主管部门，确认是否过滤掉还是由业务单位修正之后再进行抽取。不符合要求的数据主要是有不完整的数据、错误的数据、重复的数据三大类。

(1)不完整的数据：这一类数据主要是一些应该有的信息缺失，如供应商的名称、科室的名称、工号信息缺失、业务系统中主表与明细表不能匹配等。使用两种方式对数据完整性进行判断，首先是通过脚本进行数据筛取，在必要字段上增加一个查询不完整数据过程，另一个方法是在数据模型设计过程中，添加约束，通过系统报错后的异常处理进行筛查，对于这一类数据过滤出来，按缺失的内容分别写入不同日志文件向客户提交，要求在规定的时间内补全。补全后才写入数据仓库。

(2)错误的数据：这一类错误产生的原因是业务系统不够健全，或业务调整后，系统升级过程中发生的脏数据，在接收输入后没有进行判断直接写入后台数据库造成的，比如数值数据输成全角数字字符、字符串数据后面有一个回车操作、日期格式不正确、日期越界等。这一类数据也要分类，对于类似于全角字符、数据前后有不可见字符的问题，只能通过写SQL语句的方式找出来，然后要求客户在业务系统修正之后抽取。日期格式不正确的或者是日期越界的这一类错误会导致ETL运行失败，这一类错误需要去业务系统数据库用SQL的方式挑出来，交给业务主管部门要求限期修正，修正之后再抽取。

(3)重复的数据：对于这一类数据——特别是维表中会出现这种情况——将重复数据记录的所有字段导出来，让客户确认并整理。

数据清洗是一个反复的过程，不可能在几天内完成，只有不断的发现问题，解决问题。对于是否过滤，是否修正一般要求客户确认，对于过滤掉的数据，写入Excel文件或者将过滤数据写入数据表，在ETL开发的初期可以每天向业务单位发送过滤数据的邮件，促使他们尽快地修正错误，同时也可以作为将来验证数据的依据。数据清洗需要注意的是不要将有用的数据过滤掉，对于每个过滤规则认真进行验证，并要用户确认。

2)数据转换。

数据转换的任务主要进行不一致的数据转换、数据粒度的转换，以及一些商务规则的计算。

(1)不一致数据转换：这个过程是一个整合的过程，将不同业务系统的相同类型的数据统一，比如同一个供应商在结算系统的编码是XX0001，而在CRM中编码是YY0001，这样在抽取过来之后统一转换成一个编码。

(2)数据粒度的转换：业务系统一般存储非常明细的数据，而数据仓库中数据是用来分析的，不需要非常明细的数据。一般情况下，会将业务系统数据按照数据仓库粒度进行聚合。

(3)商务规则的计算：不同的企业有不同的业务规则、不同的数据指标，这些指标有的时候不是简单的加加减减就能完成，这个时候需要在ETL中将这些数据指标计算好了之后存储在数据仓库中，以供分析使用。

2.5支持主动、被动群集。

由于集成平台处于医院各类系统的中心位置，集成平台的HA高可用性是非常重要的，根据医院接入系统的数量、实时性要求和消息吞吐量，我们提供多种类型的高可用性方案来进行部署，以保证集成平台系统出现问题时，尽可能减少对业务的影响。

集成平台通过群集技术来实现对高可用性的要求，集成平台支持主动-被动群集模式、分离模式、负载均衡模式。

在主动-被动群集模式下，两台集成平台服务器连接到一个共享的数据存储，通常放置在SAN中。

主动节点上的集成平台服务运行，被动节点上的集成平台服务停止。

当主动节点上的服务出现故障的时候，群集软件将激活被动节点并启动集成平台服务。激活的节点使用相同的数据存储，所以集成平台的配置和当前正在处理的消息都会在新服务上继续运行，就像集成平台仅仅执行了一次正常的重启操作一样。同集成平台之间的连接将通过虚拟IP指向激活的节点。

2.6支持数据验证服务。

当集成平台服务器出现电源故障或异常关机等操作时，由于操作系统写失败，可能会导致数据损坏；集成引擎提供了数据验证服务，能够对损坏的数据进行恢复和修复。当引擎检测到异常的关闭，集成平台将对消息存储执行数据验证，确保数据的完整性。

数据验证处理分为两个阶段：

阶段1：验证集成引擎中当前正在处理的消息；

阶段2：验证已经处理过的历史消息。

2.7支持错误处理机制。

消息在集成平台中进行处理，如果出现错误，集成平台设计了多层次的错误处理机制，并提供了多种类的组件，可以非常方便、灵活的进行错误处理。

2.8支持消息跟踪机制。

集成引擎使用不同种类的消息系统向各种各样的不同系统发送消息，其中一些消息标准，尤其是HL7，明确的定义了应答消息，用于表明这些信息被远程系统成功的接收和正确的处理。这些应答可以让集成引擎重发消息，或通知系统管理员有些系统没有正确的处理或根本没有响应。

集成平台中的消息跟踪机制实现了将发送的消息和从远程系统接收的应答消息进行匹配，根据应答进行判断并执行重发、报错、通知等相应的后续操作。

2.9支持连接重建机制。

当应用系统连接到集成平台后，可能会由于消息收发系统故障、程序感染病毒、操作系统宕机、服务器掉电、网络通信中断等原因，造成消息发送、接收服务暂时无法连通。

我们要求当发生连接失败的情况后，消息发送系统首先要能做到主动发现连接失败，并按照设定的时间间隔，定时自动重新建立连接，直到重连成功。

2.10支持消息重发机制。

通过HL7的消息发送、应答模式，可以保证消息发送后被接收系统成功接收到。如果发送系统向集成平台发送消息后，由于网络阻塞或丢包、接收服务出错等问题，没有收到接收系统的应答消息。

当消息发送完成后，要有一个计时机制，当超过预设的最长应答时间后仍没有接收到接收系统的应答消息，那么发送系统需要自动进行消息重发操作，并记录重发次数加1，如果重发后仍未收到应答，那么应该继续重发，直到达到预设的最大重发次数，标识消息重发失败；如果重发后收到应答，那么结束重发，标识消息发送成功。

2.11支持重复消息检测机制。

由于网络延迟、系统故障、接收系统无应答，发送系统可能会多次重复发送同一个消息，如果接收系统多次处理同一消息，某些情况下可能会多次执行业务操作，造成数据出错。

所以我们要求接收系统需要对重复的消息进行判断，如果收到的消息同之前已处理过的消息相同，就不要再进行处理，直接返回一个拒绝应答就可以了。

2.12支持错误消息验证机制。

接收系统经常会遇到两类错误信息，一类是无法处理，例如接收到并不需要处理的消息事件类型，不兼容的消息版本，不合适的处理标识；一类是处理出错，例如收到的消息解析过程中发现缺少一些必填项，或者数据无法理解，或者格式不正确，类型不对，长度超长等。

针对每一个接收到的消息，无论正确错误，都必须有一个应答。如果接收到的无法处理的消息，那么需要返回一个拒绝应答MSA-1＝AR或CR；如果在解析和验证消息过程中发现错误，那么需要返回一个错误应答MSA-1＝AE或CE。如果消息完全没有任何问题，那么返回一个成功应答MSA-1＝AA或CA。

如果在消息处理解析和验证过程中出现错误，那么要把错误信息保存应答消息的ERR段中。

2.13支持错误应答处理机制。

当消息发送系统将消息发送完毕后，收到来自集成平台或其它系统所返回的应答信息，需要根据应答消息中唯一识别ID找到对应发送信息，并修改发送消息的状态为成功、拒绝或错误。

然后可以决定如何进行后续处理，例如显示一个错误提示给操作人员，或者记录到错误日志中等。系统管理和维护人员可以根据消息的状态决定如何进行后续的处理。

2.14支持基于数据中心的数据访问服务。

包括区域平台对接、医联体机构之间对接、对外数据上报。

辅助实现医院内外医疗资源和数据资源的共享与业务协同，提高医疗服务效率和质量，建设外延型医院信息化系统。

医联体医疗协作共享体系是以医院为联动核心和业务指导核心，将医联体内诸多医院通过访问医院数据中心平台及协作平台，将医疗卫生服务协作服务串联起来，形成医疗服务协作网络。医疗卫生服务协作共享体系业务范围包含：医疗数据共享、预约挂号、预约检查、委托读片、区域检查检验中心、区域病理中心、特殊人群健康关怀、慢性病防治全程管理。数据范围主要涵盖电子病历、健康体检、医疗影像、检查检验等医疗服务数据和双向转诊、远程会诊、远程教育等医疗协同数据。

2.15支持运维监控。

集成平台同各类应用系统进行实时数据交换，承载着医院核心业务流程，如果信息交换过程出现问题必须及时的发现并提示给相关人员。我们的集成平台提供了主动和被动相结合，多角度、多层次的监控机制，将信息交换的风险尽可能的降低。

集成监控平台可显示系统运行状态信息和引擎中的消息处理情况。可以将系统连接故障，接口吞吐量异常等问题进行实时的监控和提示，同时可以详细查看每个问题的详细处理日志，并根据需要进行相应的重新处理、重新发送等后续处理。

监控平台可以访问集成引擎所处理过的所有消息的快照记录，消息储存在在集成平台的归档记录中，可以设置归档消息的保存周期，根据需要对已归档的消息进行编辑、重发和重新处理。

监控平台可通过可视化的方式对消息的处理流程和消息的完整路径进行展示。

监控平台是一个基于Web浏览器的应用，可通过Internet Explorer,MicrosoftEdge,Firefox,Chrome或Safari来访问。所以在任何操作系统上都可以连接到这个监控平台进行监测。

1)错误和保持队列：用于显示错误队列和保持队列中当前消息数量和内容。

2)消息视图：监控平台中的消息能够以更加可读的格式呈现给用户，HL7消息可以通过树形结构对字段名称和数值进行展现。也可以通过关键字高亮显示的文本格式来进行查看。可以帮助用户更加方便的阅读消息，更加快速的在消息中查找关键信息。

3)引擎统计：

系统统计：监控集成引擎的消息吞吐量和内存使用率。

延迟统计：监控集成引擎处理消息，以及外部系统响应消息所花费的时间。

性能统计：监控单位时间内每个路由和过滤器处理消息花费的时间。

消息统计：对消息中的内容进行分析后，对消息类型、来源等进行统计。

4)服务器状态：可以查看集成平台运行日志和系统审计日志。

可以查看系统运行线程，用来帮助识别集成引擎出现的问题。

可以收集日志、配置、系统信息等各类诊断信息，并打包成独立的归档文件，提供给技术支持人员做更加深入的问题分析。

5)引擎正常运行时间：监控平台中具备引擎正常运行时间报告功能，用户可以自定义时间范围查看引擎运行记录和处理的消息总量。

2.16通知机制。

监控平台提供多层次的通知机制，管理员可以在系统全局或每个独立的组件设置阈值，用于触发警告或警报。如果一个警告在指定时间内未被处理，则问题被升级并通知到指定的人或组。

例如当LIS系统消息接收服务出现故障，集成平台无法将消息发送出去，消息队列中积累了大量的消息时达到设定的阈值时，这时候可以及时的通知集成平台管理员，以及LIS系统工程师，马上解决出现的问题。

2.17监测列表。

监测列表用于将组件按逻辑领域进行分组，可以独立的监控，或按名单进行转移。通过名单可以设定按指定日期、时间周期发送通知。可以按照用户选定的通信方式(邮件、短信、寻呼)进行通知。

监测列表是用户自定义的路由、通信点和web服务分组：创建列表，需要监测的组件，相关的订阅人、设置监测列表用户通知日程表。

3，数据接入处理。

在数据接入后，需要针对原始数据进行探索性分析，对于整个数据来讲是获得对数据一个初步的认识以及对先验知识的一个探索分析过程，例如数据类型，缺失值，数据集规模，各特征下的数据分布情况等，并利用第三方绘图库进行直观的观察，以获取数据的基本属性与分布情况，另外，通过单变量分析与多变量分析，可以初步探索数据集中各特征之间的关系，以验证在业务分析阶段所提出的假设。

3.1缺失值处理。

数据集中缺失值的获取方法可以直接通过python中的pandas中自带的多种方法获取，在大多数数据集中缺失值都普遍会存在，因此，对于缺失值的处理好坏会直接影响到模型的最终结果。如何处理缺失值，主要依据在缺失值所在属性的重要程度以及缺失值的分布情况。

在缺失率少且属性重要程度低的情况下，若属性为数值型数据则根据数据分布情况简单的填充即可，例如：若数据分布均匀，则使用均值对数据进行填充即可；若数据分布倾斜，使用中位数填充即可。若属性为类别属性，则可以用一个全局常量“Unknow”’或是“NULL”，但是，这样做往往效果很差，因为算法可能会将其识别为一个全新的类别，因此很少使用。

当缺失率高(>95％)且属性重要程度低时，直接删除该属性即可。然而在缺失值高且属性程度较高时，直接删除该属性对于算法的结果会造成很不好的影响。

缺失值高，属性重要程度高，主要使用的方法有插补法与建模法。

插补法主要有随机插补法，多重插补法，热平台插补法，以及拉格朗日插值法与牛顿插值法。随机插补法是从总体中随机抽取某几个样本代替缺失样本；多重插补法是通过变量之间的关系对缺失数据进行预测，利用蒙特卡洛方法生成多个完整的数据集，在对这些数据集进行分析，最后对分析结果进行汇总处理；热平台插补是指在非缺失数据集中找到一个与缺失值所在样本相似的样本(匹配样本)，利用其中的观测值对缺失值进行插补。拉格朗日差值法和牛顿插值法。

建模法可以用回归、贝叶斯、随机森林、决策树等模型对缺失数据进行预测。例如：利用数据集中其他数据的属性，可以构造一棵判定树，来预测缺失值的值。

一般而言，数据缺失值的处理没有统一的流程，必须根据实际数据的分布情况，倾斜程度，缺失值所占比例等来选择方法。在我做数据预处理过程中，除了使用简单的填充法外与删除外，更多情况下采用建模法进行填充，主要在于建模法根据已有的值去预测未知值，准确率较高。但建模法也可能造成属性之间的相关性变大，可能影响最终模型的训练。

3.2异常值(离群点)。

3.2.1异常值的发现。

1)简单的统计分析。

2)原则，基于正态分布的离群点检测，如果数据服从正态分布，在原则下，异常值为一组测定值中与平均值的偏差超过3倍标准差的值。如果数据服从正态分布，距离平均值之外的值出现的概率为属于极个别的小概率事件。如果数据不服从正态分布，也可以用远离平均值的多少倍标准差来描述。

3)基于模型检，首先建立一个数据模型，异常是那些同模型不能完美拟合的对象；如果模型是簇的集合，则异常是不显著属于任何簇的对象；在使用回归模型时，异常是相对远离预测值的对象。

4)基于距离，通过在对象之间定义临近性度量，异常对象是那些远离其它对象的对象。

5)基于密度，当一个点的局部密度显著低于它的大部分近邻时才将其分类为离群点。适合非均匀分布的数据。

6)基于聚类,基于聚类的离群点：一个对象是基于聚类的离群点，如果该对象不强属于任何簇。离群点对初始聚类的影响：如果通过聚类检测离群点，则由于离群点影响聚类，存在一个问题：结构是否有效。为了处理该问题，可以使用如下方法：对象聚类，删除离群点，对象再次聚类。

3.2.2异常值处理。

删除异常值，明显看出是异常且数量较少可以直接删除。

不处理，如果算法对异常值不敏感则可以不处理，但如果算法对异常值敏感，则最好不要用这种方法，如基于距离计算的一些算法，包括kmeans，knn之类的。

平均值替代，损失信息小，简单高效。

视为缺失值，可以按照处理缺失值的方法来处理。

3.3去重处理。

对于重复项的判断，基本思想是“排序与合并”，先将数据集中的记录按一定规则排序，然后通过比较邻近记录是否相似来检测记录是否重复。这里面其实包含了两个操作，一是排序，二是计算相似度。目前在做竞赛过程中主要是用duplicated方法进行判断，然后将重复的样本进行简单的删除处理。

3.4噪音处理。

噪音是被测变量的随机误差或者方差，主要区别于离群点。由公式：观测量(Measurement)＝真实数据(True Data)+噪声(Noise)。离群点属于观测量，既有可能是真实数据产生的，也有可能是噪声带来的，但是总的来说是和大部分观测量之间有明显不同的观测值。噪音包括错误值或偏离期望的孤立点值，但也不能说噪声点包含离群点，虽然大部分数据挖掘方法都将离群点视为噪声或异常而丢弃。然而，在一些应用(例如欺诈检测)，会针对离群点做离群点分析或异常挖掘。而且有些点在局部是属于离群点，但从全局看是正常的。

对于噪音的处理主要采用分箱法于回归法进行处理：

分箱法：分箱方法通过考察数据的“近邻”来光滑有序数据值。这些有序的值被分布到一些“桶”或箱中。由于分箱方法考察近邻的值，因此它进行局部光滑。

用箱均值光滑：箱中每一个值被箱中的平均值替换。

用箱中位数平滑：箱中的每一个值被箱中的中位数替换。

用箱边界平滑：箱中的最大和最小值同样被视为边界。箱中的每一个值被最近的边界值替换。

一般而言，宽度越大，光滑效果越明显。箱也可以是等宽的，其中每个箱值的区间范围是个常量。分箱也可以作为一种离散化技术使用。

回归法：可以用一个函数拟合数据来光滑数据。线性回归涉及找出拟合两个属性(或变量)的“最佳”直线，使得一个属性能够预测另一个。多线性回归是线性回归的扩展，它涉及多于两个属性，并且数据拟合到一个多维面。使用回归，找出适合数据的数学方程式，能够帮助消除噪声。

需要说明的是，在上述流程中或者附图的流程图中示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本实施例提供了一种数据处理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”、“单元”、“子单元”等可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图4是根据本申请实施例的数据处理装置的结构框图，如图4所示，该装置包括：

确定单元41，用于确定数据采集方式，所述数据采集方式包括：利用数据接口采集、利用复制订阅的方式采集以及利用SSIS的方式采集；

处理单元43，用于利用数据采集管理系统，按照所述采集方式从数据中心采集各医院信息系统的各个应用子系统的原始数据，并将采集到的原始数据进行数据清洗和数据转换，将得到的目标数据进行分类存储，所述数据采集管理系统具有如下功能：数据采集、采集脚本配置、采集调度与监控、消息持久化、主被动群集模式、数据验证服务、数据错误处理机制、消息跟踪机制、连接重建机制、消息重发机制、重复消息检测机制、错误消息验证机制、错误应答处理机制、基于数据中心的数据访问服务、运维监控、通知机制以及监测列表，所述数据清洗表示过滤不符合要求的数据，所述数据转换包括不一致数据的转换、数据粒度的转换以及商务规则的转换。

需要说明的是，上述各个模块可以是功能模块也可以是程序模块，既可以通过软件来实现，也可以通过硬件来实现。对于通过硬件来实现的模块而言，上述各个模块可以位于同一处理器中；或者上述各个模块还可以按照任意组合的形式分别位于不同的处理器中。

实施例提供了一种计算机设备。结合本申请实施例数据处理方法可以由计算机设备来实现。图5为根据本申请实施例的计算机设备的硬件结构示意图。

计算机设备可以包括处理器51以及存储有计算机程序指令的存储器52。

具体地，上述处理器51可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，简称为ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

其中，存储器52可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器52可包括硬盘驱动器(Hard Disk Drive，简称为HDD)、软盘驱动器、固态驱动器(SolidState Drive，简称为SSD)、闪存、光盘、磁光盘、磁带或通用串行总线(Universal SerialBus，简称为USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器52可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器52可在数据处理装置的内部或外部。在特定实施例中，存储器52是非易失性(Non-Volatile)存储器。在特定实施例中，存储器52包括只读存储器(Read-Only Memory，简称为ROM)和随机存取存储器(RandomAccess Memory，简称为RAM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(Programmable Read-Only Memory，简称为PROM)、可擦除PROM(Erasable ProgrammableRead-Only Memory，简称为EPROM)、电可擦除PROM(Electrically Erasable ProgrammableRead-Only Memory，简称为EEPROM)、电可改写ROM(Electrically Alterable Read-OnlyMemory，简称为EAROM)或闪存(FLASH)或者两个或更多个以上这些的组合。在合适的情况下，该RAM可以是静态随机存取存储器(Static Random-Access Memory，简称为SRAM)或动态随机存取存储器(Dynamic Random Access Memory，简称为DRAM)，其中，DRAM可以是快速页模式动态随机存取存储器(Fast Page Mode Dynamic Random Access Memory，简称为FPMDRAM)、扩展数据输出动态随机存取存储器(Extended Date Out Dynamic RandomAccess Memory，简称为EDODRAM)、同步动态随机存取内存(Synchronous Dynamic Random-Access Memory，简称SDRAM)等。

存储器52可以用来存储或者缓存需要处理和/或通信使用的各种数据文件，以及处理器51所执行的可能的计算机程序指令。

处理器51通过读取并执行存储器52中存储的计算机程序指令，以实现上述实施例中的任意一种数据处理方法。

在其中一些实施例中，计算机设备还可包括通信接口53和总线50。其中，如图5所示，处理器51、存储器52、通信接口53通过总线50连接并完成相互间的通信。

通信接口53用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。通信接口53还可以实现与其他部件例如：外接设备、图像/数据采集设备、数据库、外部存储以及图像/数据处理工作站等之间进行数据通信。

总线50包括硬件、软件或两者，将计算机设备的部件彼此耦接在一起。总线50包括但不限于以下至少之一：数据总线(Data Bus)、地址总线(Address Bus)、控制总线(Control Bus)、扩展总线(Expansion Bus)、局部总线(Local Bus)。举例来说而非限制，总线50可包括图形加速接口(Accelerated Graphics Port，简称为AGP)或其他图形总线、增强工业标准架构(Extended Industry Standard Architecture，简称为EISA)总线、前端总线(Front Side Bus，简称为FSB)、超传输(Hyper Transport，简称为HT)互连、工业标准架构(Industry Standard Architecture，简称为ISA)总线、无线带宽(InfiniBand)互连、低引脚数(Low Pin Count，简称为LPC)总线、存储器总线、微信道架构(Micro ChannelArchitecture，简称为MCA)总线、外围组件互连(Peripheral Component Interconnect，简称为PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(Serial AdvancedTechnology Attachment，简称为SATA)总线、视频电子标准协会局部(Video ElectronicsStandards Association Local Bus，简称为VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线50可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

另外，结合上述实施例中的方法，本申请实施例可提供一种计算机可读存储介质来实现。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种数据处理方法。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。