医院的信息化是一个无底洞，建设永无止尽，随着医院的发展，会在过程中采购很多不同厂家的系统，比如基础HIS，LIS，PACS，EMR，HRP等等系统，这些系统也不可能完全由一个公司能够提供完全，这就不可能避免的出现了一些信息孤岛，信息不能有效的共享，数据标准不统一，一份完整的电子病历需要从不同的系统中去抽取不同的数据，这些难免给医院信息管理带来灾难，为此数据中心势在必行。

1 数据中心的目的

1.1 规范数据

保证不同业务系统数据相对独立的基础上，建立数据交换和共享机制，通过对数据的加工、清洗、传递和交换，实现数据的标准化、一致化。建立过程中可以参考卫生部相关数据集标准，同时标准规范化的数据也是进行区域交换所必须的。

1.2 信息共享

建立信息生命周期中各种分散资源的管理与协调中心，使分布在不同地域、科室的医生、护士、医技等人员都可以从这个中心出发开展工作。比如患者的全生命周期数据，在所需要的各环节都是可以随时从中心下载使用的。

1.3 辅助决策

通过统一的数据中心系统为企业领导实现规范、准确、及时的医院运营管理提供基础。避免直接从业务生产系统提取各种数据。

2 数据中心工具选择

在业界有很多工具都是可以实现建立数据中心的目的的。包括各种ETL工具，以及Oracle的E-LT工具。2者的主要区别就在于是否需要ETL服务器，E-LT是不需要硬件服务器的，加载速度更快，这个工具就是当前oracle主推的Oracle Data Integrator(ODI)。如下示意图：

3 ODI的体系结构

3.1 概述

下面先看一下ODI的体系结构，ODI通过建立资料库管理各种配置信息。分为主资料存储库和工作区资料存储库，在首次登陆的时候需要创建在对应的管理DB上，并通过ODI管理工具连接到工作区资料库中进行各种配置操作，在对应的资料存储库中分别存储了如下的对象：

接口是建立在模型之上的，而模型建立在逻辑架构的基础上。通过选择上下文，逻辑架构和物理架构关联了起来。接口中还可以知名目标区域和临时区域分离。

3.2 ODI存储库概念

主存储库：master repository ,保存top信息，具体位置可以在任何可以支持的数据库里面。通过 Topology Management 可以访问。

工作存储库：work repository保存工程信息，具体位置可以在任何支持的数据库中。通过Designer 可以访问

3.3 ODI Top概念

TOP信息保存在主存储库(master repository)中主要有如下信息：

技术：各种数据库类型对应的技术体系。当前ODI几乎支持所有的数据库，所以对于我们的整合是毫无问题的。

数据服务器：用来存储数据的容器，比如Oracle 10g的实例 等，一般一个数据服务器对应一项技术。简单点说就是一个数据库连接对象。

物理架构：physical schedule，数据服务器的一个子容器，或者说是一个子集。比如oracle的用户。ODI对于不表数据库的物理架构一般会要求有两个，一个是目标物理架构，即：架构，一个是工作区物理架构，即：工作架构。并可以定义工作区中临时表的前缀等信息。

逻辑架构： 和对应的物理架构有类似的数据结构(但不进行任何数据定义)。

上下文：逻辑体架构通过上下文和物理架构关联，运行时通过选择不同的上下文，可选择不同的逻辑-物理对应关系。

换句话说，由于我们的接口等组件的定义都是在逻辑架构上的。因此，具有类似物理结构的物理架构可以通过上下文的关联，对应上同一个逻辑架构，我们可以将数据结构类似的物理结构通过同一个接口实现数据抽取。

工作存储区：建立起到工作存储区的连接。在登录设计器时，通过选择在这里定义好的工作存储区可编辑项目、接口等信息。

3.4 ODI数据模型

数据模型：目标数据库的表、视图等结构。包括字段，数据类型，约束等内容。

反向：将物理数据库中的数据模型“拷贝”出来。设计者可以使用物理数据库结构或者在此基础上做任何修改。这是一个比较有用的功能，相当于从数据库中把定义反向到存储模型上，我们可以先用脚步在数据库中建立好，再反向到模型中，而不是在模型中一个一个的存储来定义，反向的效率高得多。

3.5 工程

工程是ODI工作的基础单位。所有的接口、过程、变量都保存在工程中。

文件夹：组织包、接口、过程的单位;

包：组织接口、过程、变量和其他组件，按照既定的流程运行的容器。

接口：ETL的主要步骤在这里完成，从数据源的抽取数据，中间做转换，创建临时表和约束，加载数据等。所有的过程由选择的KM来控制。

过程：可以辅助接口，针对特定技术做一些命令来操作数据库，比如写ETL日志，比如在目标数据库中做数据转换。类似于数据库里面的过程。而且可以通过设置选项来控制命令执行的流程。

变量：类似于程序语言中的变量。可以定义可选择的类型并动态赋值。

函数：没有使用过。

知识模块：oracle提供的加载转换模块，内容很多，后面详细介绍。

方案：包或接口的一个固定版本。方案不随包或接口的修改而改变。

3.6 代理

代理：代理是一个轻量级的运行时组件，可以定时反复地执行制定的任务。通过代理我们可以自动地做日结或月结作业;或定时跑任何一个作业。

物理代理：每个物理代理对应一个Agent。也对应一个物理数据库。

逻辑代理和上下文：逻辑代理可通过上下文关联到一个物理代理。

3.7 知识模型

知识模块：Knowledge Module，是连串命令的模板。其中的命令通用性越好，KM的使用范围越广。KM有多种，分别使用在接口的不同阶段，其中有：loading(加载),integration(集成),checking(检查), reverse-engineering(反向), and journalizing(日志)

工作方式：通过生成在运行时执行的代码工作。

4 ODI应用

通过几个简单的步骤即可完成一个简单的ODI数据抽取实例。

① 建立物理方案，物理服务器

② 建立逻辑方案

③ 建立上下文

④ 通过上下文连接物理方案与逻辑方案

⑤ 建立模型

⑥ 模型下建立目标存储库

⑦ 建立接口，实现数据抽取。

这里面虽然实现了数据抽取，但是距离我们实际的应用还是比较远的。这里在说下ODI在实际应用中比较重要的几个特性。

4.1 CDC

CDC(Change Data Capture)，即变化数据捕获，通过不同的知识模块可以有不同的方式来捕获变化数据，比如触发器也是一种常见的捕获方式。通过对源系统建立CDC日志，当村长改变时，可以通过订阅CDC日志来实现获取变化日志。

4.2 Web service

在集成应用中，我们通过SOA来整合业务流程，比如医生站下达医嘱后，需要把医生站下达医嘱这个事件的消息传递给LIS，PACS系统。虽然有很多种方式实现，但是都是希望对原系统的改动尽量的少。所以这里就可以通过把这个改变发布为一个web service，这样可以很好的供SOA使用。

5 总结

建立数据中心无疑是一项非常复杂的项目，还需要我们做大量的试验及验证，但是当有一个好的工具时，效果会很多，即我们常说的“站在巨人的肩膀上”。本次重点对ODI进行了一些说明，后续我们需要应用在实际案例中去，希望有识之士共同探讨。