数据仓库主要是对业务数据进行综合统计分析，以辅助进行相关决策。业务统计分析和医疗质量辅助分析均是利用现有数据，实现管理辅助决策，从技术角度这类应用可以基于数据仓库技术来实现。数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，在汇总数据的基础之上，支持数据发掘、多维数据分析等当今尖端技术和传统的查询及表报功能，用于支持管理决策。作为区域卫生信息平台特定的优化读取的性能模型，数据仓库的任务是提供一个独立的平台，数据能被转换成可操作的、可搜索的、可管理的和可获得的，而不影响信息平台系统组件所需的关键性能服务水平。必须支持分析、研究和管理汇集在信息平台内的运行数据相关的价值。
辅助决策利用数据仓库可以为许多不同类型业务做出辅助决策，如：医保/新农合管理辅助决策、临床辅助决策、条线辅助决策和管理辅助决策等。目前，辅助决策除了对以上业务提供支持以外，还可以利用数据仓库平台满足公共卫生监测业务域的需求。公共卫生域需要支持一些处理过程，通过操作研究和分析来发现潜在的传染病爆发或运行其他类型公共卫生程序。
八、健康档案浏览器
健康档案浏览器是为终端用户提供的基于Web 的访问健康档案的应用程序。健康档案浏览器的目标是建立一个用户友好的环境，在该环境下授权的医疗卫生人员可以方便地访问区域卫生信息平台中保存的客户相关数据。区域卫生信息平台由七个域系统组成，每一域针对特定的医疗卫生人员。例如，儿童保健域服务于儿童保健人员的需求，处方药品域服务于开处方的医生和调配处方的药剂师的需求。每一个域的解决方案都提供一个终端用户的接口能力，以特别用于域相关的数据集和特殊的功能。
健康档案浏览器的不同之处在于它的通用性，重点在于提供健康档案中任何可用信息的跨域集成视图。这包括通过索引服务追踪到所有事件的相关数据，包括挂号、健康档案存储服务和业务管理服务。随着区域卫生信息平台的应用、发展和成熟，用户需要健康档案浏览器具有能够将自身整合到现有的基本业务系统或其他Web 应用程序的功能。
区域内各医疗机构使用健康档案浏览器可实现对平台整合后业务数据的访问，由于这种方式相对安全（一般只能查阅，不能修改），因此从管理层角度来看，也是一种非常理想的信息共享模式。
第五章 区域卫生信息平台技术架构
第一节 总体技术架构
从前面的需求分析我们知道，基于健康档案的区域卫生信息平台是为区域卫生信息化提供一个以健康档案数据为核心的开发和运行平台，可以使用此产品快速的定制、开发和部署区域卫生信息平台项目，来满足日益增加的区域电子健康信息共享与管理需求。因此基于健康档案的区域卫生信息平台构架设计的目标是建立一个能够容纳管理个人健康档案的可扩充的、开放的、可持续发展的构架，其包括以下方面：
管理业务的扩充：能够围绕电子健康信息建立扩展新的健康管理业务，从公共健康管理的角度来看可以建立不同的疾病监控系统，从医疗服务者的角度看，可以查询、调用以不同组织方式呈现的个人电子医疗档案。
存储健康信息的扩充：能够在系统中增加新的健康信息种类的存储，比如新的医疗影像或检验结果。能够根据每种存储信息的特点对信息内容进行优化，但通过统一的接口对新的健康信息可以和已有的健康信息进行查询、调阅。
接入方式的扩充：区域电子健康信息中心面对的数据源和用户是各个医疗机构及个人用户，所以能够接纳各种现有的和未来的应用系统的数据上传及使用相当重要。中心构架需要能够扩充对各种接入方式的支持。
系统容量的扩充：区域电子健康信息中心是一个数据量庞大的信息系统，在设计时需要考虑对数据存储容量的横向扩充。
系统处理能力的扩充：随着区域电子健康信息中心使用者的增加，系统将承受大量的服务请求压力。系统将使用分布式服务和集群等方式实现系统处理能力的扩充。
为了实现上述的要求，建立一个稳定核心适用全国各地的软件平台，满足各地区域卫生信息化的基本需要，同时还要满足区域卫生信息化持续性发展的需求，因此我们将基于健康档案的区域卫生信息平台的总体技术框架设计如下：
图5-1 总体技术架构图（略）
如上图所示，基于健康平台的区域卫生信息平台主要包括硬件网络基础设施层、数据中心数据层、业务服务层、数据交换层四个层次，还包括贯穿四个层次的标准规范体系和安全保障体系两大体系。
硬件网络层是指支撑区域卫生信息平台的硬件设备和网络平台，其是区域卫生信息平台的基础设施。数据中心层主要是实现基于健康档案的区域卫生信息平台的数据存储，需要解决数据存储的结构、模型、内容、数据库管理软件的选型等。数据交换层和业务服务层主要实现基于健康档案的区域卫生信息平台的数据采集、交换与共享，数据交换层是直接与外部系统进行沟通的技术层，业务服务层是基于数据交换层根据数据结构设计各种业务服务组件来完成平台数据的采集，存储与共享。标准规范体系是区域卫生信息平台中必须遵循和管理的数据标准，是平台运行和应用的数据基础。安全保障体系是从物理安全到应用安全保障整个平台的正常运营。
第二节 数据交换技术方案
一、企业服务总线
数据交换服务总线ESB是整个区域卫生信息平台的技术核心，ESB通常采用面向服务的体系结构。该服务保证在一个异构的环境中实现信息稳定、可靠的传输，屏蔽掉用户实际中的硬件层、操作系统层、网络层等相对复杂、烦琐的界面，为用户提供一个统一、标准的信息通道，保证用户的逻辑应用和这些底层平台没有任何关系，最大限度地提高用户应用的可移植性、可扩充性和可靠性。提供一个基于应用总线的先进应用整合理念，最大限度地减少应用系统互联所面临的复杂性。系统的实现维护都相对简单，保证每一个应用系统的更新和修改都能够实时地实现；同时当新的应用系统出现时能够简便的纳入到整个IT环境当中，与其它的应用系统相互协作，共同为用户提供服务。
面向服务的体系结构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
对松耦合系统的需要来源于业务应用程序需要，根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构，它已经出现很长时间了，其定义的概念与 SOA 相似。然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXML）为基础的。
Web 服务并不是实现 SOA 的唯一方式。但是为了建立体系结构模型，所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新零件数据库，以包括进新供应的货物却是技术流程。因而，工作流在 SOA 的设计中扮演重要的角色。
此外，动态业务工作流不仅包括部门之间的操作，甚至还可以包括与外部合作伙伴进行的操作。因此，为了提高效率，需要定义应该如何获取服务之间的关系的策略，这种策略常常采用服务协定和操作策略等形式。 所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。消息交换技术最好具备如下特性：
（1）基于消息中间件技术，业务中心基于JAVA技术，J2EE标准。
（2）操作系统平台、数据库系统无关性，ESB应完全按跨平台技术设计和实现，兼容目前所有常规操作系统和流行的数据库系统。
（3）基于消息内容路由功能，集成工作流服务。
（4）消息交换符合XML标准，为专为国内卫生行业定制的总线消息协议，可通过协议转换器与HL7等多种国际标准协议兼容。
（5）基于卫生行业各系统发展不平衡的现状。整体EAI设计模式符合
SOA（面向服务系统架构）。
现有的体系结构模型和实践往往是以程序为中心的。应用程序是以某个单一的医疗行业业务需要为出发点。通常，流程信息在组件之间传播。应用程序很像一个黑匣子，没有粒度可用于外部。重用需要复制代码、合并共享库或继承对象。在以流程为中心的体系结构中，应用程序是为过程开发的。流程可以分解成一系列的步骤，每一个步骤表示一个业务服务。实际上，每个过程服务或组件功能都相当于一个子应用程序。将这些子应用程序链接在一起可以创建能够满足业务需求的流程流。这种粒度允许利用和重用整个组织中的子应用程序。
（1）服务请求方
在ESB构架中，服务请求方为发起请求的应用系统，通过ESB提供的源适配器，将请求消息发送到入点的前置服务器的发送队列。
源适配器为发送方应用系统与ESB数据中间交换总线的桥梁，适应目前医疗行业业务系统所采用的系统平台和开发语言有较大差异，各种平台上都有对应的源适配器，支持C，COM，JAVA等不同开发环境。
（2）消息中间件
消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合方法。消息队列的API调用被嵌入到新的或现存的应用中，通过消息发送到内存或基于磁盘的队列或从它读出而提供信息交换。消息队列可用在应用中以执行多种功能，比如要求服务、交换信息或异步处理等。
在MQ中，队列分为很多种类型，其中包括：本地队列、远程队列、模板队列、动态队列、别名队列等。本地队列又分为普通本地队列和传输队列，普通本地队列是应用程序通过API对其进行读写操作的队列；传输队列可以理解为存储-转发队列，比如：我们将某个消息交给MQ系统发送到远程主机，而此时网络发生故障，MQ将把消息放在传输队列中暂存，当网络恢复时，再发往远端目的地。
远程队列是目的队列在本地的定义，它类似一个地址指针，指向远程主机上的某个目的队列，它仅仅是个定义，不真正占用磁盘存储空间。根据应用逻辑划分，ESB主要划分成发送和接收两种队列：
发送队列
接收队列
（3）服务提供方
SOA设计中，将应用系统对外提供的实现了特定的、可标识的一组（业务）功能称为服务。除了业务功能，ESB内配置的服务还实现中心管理接口，以及参与环境的边界配置、操作和监视。
二、数据接口方式
为了实现各医疗卫生业务数据能够与区域卫生信息平台实现联动，需要在医疗卫生机构部署数据交换前置服务部件：以数据交换适配器的方式实现各分区医疗卫生信息系统（HIS、LIS、PACS、社区卫生系统等）的集成接入，按照SOA的设计理念，被集成系统需要与数据交换平台交互的功能组件、数据组件将被封装成“服务”，屏蔽被集成系统所采用的具体技术及其实现方式，以标准的接口方式与数据交换平台衔接。同时根据需要部署前置数据库，进行交换数据的前置缓存。各个应用系统通过与服务总线ESB实现消息交互。通过在业务系统端安装相应的软件适配器，实现与消息交换中心的信息交互。适配器由软件模块、软件配置文件、应用编程接口等组成。
在消息总线系统的整体设计架构中，各个具体的业务系统通过Adapter连接到消息消息交换平台收发业务数据。适配器起着耦合消息交换平台与具体业务系统的作用。在我们的方案中有三种适配器：标准适配器、专用适配器和商用适配器。标准适配器是由标准的Adapter Kernel和API组成。Adapter Kernel实现和消息交换中心的消息交互和对消息的实时监控，并提供将消息分发到应用系统的功能。API是为应用系统提供的一套标准的接口，具有足够的扩展性，可以灵活地嵌入到业务流程中，同时将与业务无关的通讯配置定义与业务代码隔离。具体地，Adapter实现以下的功能：
（1）实现消息的安全、可靠传递；
（2）实现消息的透明传递，Adapter的实施者不必关注传递技术细节；
（3）接口通用化，降低因开发架构不同导致的业务应用侧编程复杂性；
（4）实现具有共同性的消息封装、变换、接收功能。例如，加解密/校验/字符集变换及HCN-XML标准协议；
（5）简单的远程安装配置方法，适配器的函数调用库可以平滑升级而不影响业务应用；
（6）可以与消息交换平台交互管理信息，实现流量控制、报文蓄积、本地日志等功能。
有关适配器组件的有关功能说明如下：
（1）总线连接器
功能概述：连接MQ队列管理器和队列，发送和接收消息。在其内部封装了MQ提供的连接、收发消息等接口。它与其他组件/子模块通过内部调用机制传递控制信息，和消息处理器通过内部接口传递处理好的消息。总线连接器不对消息内容做任何处理。
（2）日志管理器
功能概述：记录运行日志和错误日志，提供不同内部函数对应不同日志记录要求。
（3）配置管理器
功能概述：读取配置文件和业务对象定义以供初始化使用；生成对应消息控制数据（如消息路由、应用程序标志、消息类型）。
（4）异常处理器
功能概述：负责异常处理。根据异常定义，提供异常处理函数；标准化异常处理流程；和日志管理器配合记录错误日志。
（5）消息处理器
功能概述：负责消息的转换、封装、提取。主要功能如下：
总线消息的封装、提取。
提供出口函数接口以实现业务对象与集成消息之间的转换。
（6）专用适配器管理器
功能概述：目标端的主控程序，负责协调各个模块之间的运行关系。启动之后，主控程序通过配置管理器提供的信息启动一个或多个工作进程管理器。
（7）消息分发控制器
功能概述：消息分发服务器的主控程序，负责协调消息分发服务器各个模块之间的运行关系。
（8）工作进程管理器
功能概述：负责启动和控制工作进程。主控程序根据配置信息启动工作进程管理器，每个工作进程管理器对应一个MQ本地队列（消息分发服务器将单一接收队列中的消息根据不同的应用发送到指定的队列）。工作进程管理器可以根据配置启动一个或多个工作进程从而提高消息传递的效率。
（9）工作进程
功能概述：完成一系列的消息处理工作。主要工作任务是：
从配置管理器中获取信息（如MQ连接配置，该应用类型，消息控制信息等）。
实例化消息处理器，封装和转换消息。
实例化日志管理器，实时记录各种日志。
实例化异常管理器，在运行时实时捕捉异常并处理异常。
实例化消息总线连接器，用于与消息交换中心交互消息。
实例化外壳，与应用系统交互消息。
根据工作进程管理器的指令，实现对有关资源的控制。
（10）消息分发器
功能概述：负责将接收到的消息分发到本地队列。消息分发器负责将该接收队列的消息根据消息体里的应用标志分发到各个指定的本地队列中。
（11）接口
功能概述：提供连接应用系统的接口，不同的应用系统对应不同的外部接口。
（12）标准接口
功能概述：提供连接应用系统的标准接口。
（13）文件接口
功能概述：提供文件传输接口。
三、业务组件服务
（一）公共服务
1．监控日志服务
监控日志服务用来记录系统中所处理的业务和系统事件，用户可以通过统一界面配置和浏览所记录的事件。平台中将设计一系列事件体系，包括业务事件和系统事件。各个模块都可以定义各自的所产生的事件，并且通过平台统一的接口进行记录。监控日志服务将根据用户对监控日志服务的配置对事件进行记录。系统同时将提供一个集中式监控日志浏览接口，此接口将分析所有事件记录文件，用网页界面方式供用户查询和浏览。
2．标准转换服务
标准转换服务是用来将一种XML格式的文件通过XSLT转换成另一种格式。一种典型的应用是当用户调用某个病人的记录时，系统将记录从XML格式转换为健康档案浏览器可以显示的HTML格式。标准转换服务可以将原始医疗记录转换为系统标准医疗信息数据结构。
标准转换服务是保证数据长期有效的根本服务。在系统中随着应用的升级，系统中会积累各种历史格式的数据，只用通过变形在使用中转换历史数据，才可以保证数据的可用性和统一性。
3．权限验证服务
权限验证服务用来根据已认证用户的角色来决定是否用户有权限执行指定的操作。权限验证服务提供验证和认证两方面的功能。验证功能有两种方式：显示认证和隐式认证。显示认证需要用户主动输入用户名和相应的用户密码或其他认证方式。在权限验证服务通过密码认证了此用户后，用户才可以用此认证用户的身份来调用他能够调用的服务。隐式认证是指用户或其系统使用以配置好的非对称密钥等系统直接认证其身份，不需要主动输入用户名和密码。系统可以根据其配置直接赋予其所对应的验证用户的身份。认证功能将基于用户的角色定义，赋予某种角色的用户可以拥有与角色相应的权限。
用户的验证和认证管理将被实现为Web Service的一种服务，具体的用户信息和角色信息的存储将被存入LDAP服务器。用户信息将和个人， 医师和机构绑定。每个服务被调用前，如果需要对调用者进行验证和认证，会先调用验证服务确定调用者的身份，然后调用认证服务确认调用者的权限是否能够调用此服务。
4．隐私管理服务
隐私管理服务用来制定从法律，制度和个人要求等几个方面对个人医疗信息的访问进行限制和授权。系统将会指定一个通用的授权制度，比如说允许急救室访问所有病人的医疗信息，或者允许病人访问过的医院里的医师访问此病人的所有信息。系统也可以允许病人自定义授权条件，允许某些医师或某些医疗机构访问自己的医疗信息记录。
隐私管理服务将被实现成Web Service服务。系统中将医疗信息记录按照种类或者条目制定记录ID，在实现时，将为每个用户建立一个授权映射表，指出某些医师或机构已经被授权访问哪些信息。
5．数据加密服务
数据加密服务实现对系统中的关键数据加密保护，其子功能包括密钥管理功能、字段加密功能和WS-Security加密功能。可能加密的数据包括电子健康信息（使用个人、医师或医疗机构密钥），传输信息包和密码等信息。加密所用的非对称密钥由注册服务保存，最终存放在LDAP服务器中。
6．数字签名服务
数字签名服务实现对系统中的信息包进行数字签名，保证数据的完整性和不可抵赖性，其子功能包括针对字段的电子签名和针对XML的电子签名。可能加密的数据包括电子健康信息（使用个人、医师或医疗机构密钥）等信息。加密所用的非对称密钥由注册服务保存，最终存放在LDAP服务器中。
7．目录管理服务
目录管理服务是提供系统内外所用到的服务信息格式的注册服务。在注册信息格式的同时，目录管理服务还保存与此服务相关的描述信息。
（二）通讯服务
1．数据缓存服务
数据缓存服务提供一个医疗机构端原始医疗数据上传过程中的缓存机制，在大批量原始数据的上传过程中，保证了电子健康信息中心的其他服务的响应时间和稳定性。医疗机构端原始医疗数据上传可以采用准实时和批量上传的形式。当数据上传至中心之后，中心将根据不同数据来源来对原始数据进行变形、验证、导入和注册等工作。由于电子健康信息中心的庞大数据量，每条上传数据的处理将会耗用大量系统资源，造成中心响应时间的下降。
相对于中心的其他服务，比如医疗数据调阅等服务来说，数据上传是一个低优先级的服务要求，对于实时性的要求相对较低。数据缓存服务就是实现这个功能，当原始数据上传至中心后，数据缓存服务将数据立即存于可靠的数据缓存中。后续服务会在系统资源允许时从缓存中读取原始记录，调用后续服务将原始记录转换成中心标准格式，注入到信息中心存储服务中。
2．通讯服务协议
HTTP/SOAP 通讯服务协议提供标准Web Service接入服务。作为最为广泛接受的Web Service接入方式，各医疗卫生系统提供商都可以用最少的开发时间，根据各自的技术解决方案，用各种开发工具提供医院原始健康信息的上传功能。同时，HTTP/SOAP 通讯服务还提供了SOA服务的主要调用方式。整个平台使用了基于Web Service的SOA设计理念，会提供大量Web Service服务来提供具体定制和扩充的要求。HTTP/SOAP是主要外部Web Service调用协议。
3．FTP通讯服务
FTP通信方式提供了平台直接从外部FTP服务器上查询可用文件，下载数据文件，并将数据文件递交给相关处理流程的功能。对于一些HIS厂商来说，使用FTP上传原始医疗数据是一种简单的上传方式。此平台提供的FTP模块，可以定时到目标FTP服务器中（可能在医院端，也可能是建立在中心），定时地查询原始数据文件是否已经上载到指定目录。如果已经上载，FTP将依次下载可用的数据文件，将每个文件单独地送入处理流程处理。对于已经处理的文件，可以选择在目标FTP服务器上删除或者改名作为处理完的标记。
（三）注册服务
1．个人注册服务
个人注册服务是平台中的最主要服务之一，其主要功能是维护和提供医疗服务的接受者，比如病人等的唯一标识信息，个人信息和与外部系统中的标识映射信息。对于电子健康档案信息中心平台来说，必须针对一个个人在系统中拥有一个唯一的标识，也就是个人唯一标识。个人唯一标识被广泛地用于和系统中和个人相关的所有信息中，比如共享医疗档案，医疗影像库等。同时，系统中还需要存放个人的相关信息，比如名字、性别、年龄、籍贯等等，这些信息将和个人唯一标识绑定，存放在个人注册服务服务中。个人唯一标识和相关信息的使用可以有效地防止歧义，保障长期医疗信息的一致性，并可以用来提供个人搜索等服务。
由于健康档案采集于各个医疗服务机构，无法被强制统一的上传的原始医疗记录中的个人标识。当原始医疗记录被规范成中心标准格式后，此记录需要对应到中心的相关记录中。个人注册服务的个人标识映射功能就是用来将不同来源记录中的个人标识映射为中心的个人唯一标识。此类映射可以分为自动映射和人工干预映射两种。个人注册服务提供的主要服务包括：
（1）搜索个人：从输入的个人相关信息搜索个人唯一标识；
（2）增加新个人：创建一个新个人唯一标识和相关个人信息；
（3）合并个人：合并两个个人唯一标识和相关个人信息；
（4）搜索中心标识：根据输入的来源信息和来源标识找出对应的个人唯一标识；
（5）模糊搜索中心标识：根据输入的个人相关信息，自动匹配最相关的个人唯一标识；
（6）搜索外部标识：根据来源信息和个人唯一标识找出对应外部系统的个人标识；
（7）设置外部标识映射：设置外部标识，来源信息和个人唯一标识的映射关系。
个人注册服务是以Web Service的形式实现，各服务是直接提供给各模块使用，使用隐式认证方式，但不允许非认证用户使用。服务定义将借鉴IHE PIX的定义，实现相近的功能。对于模糊查询可能考虑使用开源搜索引擎搜索相关度最高的结果。模糊查询的关键信息包括：姓名、性别、年龄、身份证号、社保号、住址、电话号码。合并个人标识和设置外部标识映射功能需要人工干预，相应的用户界面和逻辑将在应用服务器中实现。
2．医师注册服务
医师注册服务主要功能是维护和提供医疗服务的提供者，比如医师、护士等的唯一标识信息，医师信息和与外部系统中的标识映射信息。由于医师的注册机制比较严密，医师注册服务比个人注册服务少了模糊查询和合并医师等功能。除此之外，每个医师都会映射到机构注册服务维护的医疗机构中，在现实中就是该医师注册的医院或诊所。
在医师信息中，还增加了医师的公钥信息，用来在某些记录中对医疗记录进行加密或签名，以满足某些场合安全性的需要。医师注册服务提供的主要服务包括：
（1）搜索医师；
（2）增加新医师；
（3）搜索中心标识；
（4）搜索外部标识；
（5）设置外部标识映射；
（6）设置医师公钥；
（7）设置医师服务机构。
医师注册服务是以Web Service的形式实现，各服务是直接提供给各模块使用，使用隐式认证方式，但不允许非认证用户使用。设置医师公钥、设置医师服务机构和设置外部标识映射功能需要人工干预，相应的用户界面和逻辑将在应用服务器中实现。
3．机构注册服务
机构注册服务主要功能是维护和提供医疗机构，比如医院等的唯一标识信息、机构信息。医疗机构所上传的病人原始健康信息将带有医院的唯一标识以利于中心归档映射。在机构信息中，还增加了机构的公钥信息，用来在某些记录中对医疗记录进行加密或签名，以满足某些场合安全性的需要。机构注册服务提供的主要服务包括：
（1）搜索机构；
（2）增加新机构；
（3）搜索机构标识；
（4）设置机构公钥；
机构注册服务是以Web Service的形式实现，各服务是直接提供给各模块使用，使用隐式认证方式，但不允许非认证用户使用。设置机构公钥、增加新机构功能需要人工干预，相应的用户界面和逻辑将在应用服务器中实现。
4．医学名词注册服务
医学名词注册服务主要功能是维护和提供中心医疗名词定义和医疗机构的名词定义之间的映射定义。在中心的医疗记录中，所有的医疗名词都会以标准的名词定义以保证一致性和支持统计功能。医学名词注册服务提供的主要服务包括：
（1）机构至中心名词映射；
（2）中心至机构名词映射；
（3）名词映射定义。
医学名词注册服务的映射功能是以Web Service的形式实现，各服务是直接提供给各模块使用，使用隐式认证方式，但不允许非认证用户使用。医学名词注册服务的名词映射定义可以使用文件注入和界面设置来实现。
（四）全程健康档案服务
1．数据标准化服务
标准化服务组件将各种非标准化的数据格式转换为系统所认知的统一的标准数据格式，同时也负责对单次的收集数据完整性进行校验。标准化服务组件的运转需要依赖于数据标准管理服务组件。所有能够被标准化以及标准化后的数据结构必须在数据标准管理服务上已经被注册，标准化服务通过Metadata的定义对这些数据格式进行认知和校验。标准化服务的校验实现是通过Xslt和Metadata的数据库中的定义共同完成，原则上基于效率考虑只针对这些这些数据的完整性通过Xslt进行校验，如果需要进一步的严格校验，则需指定相应的校验域，通过Metadata对这些域中的数据以及逻辑关系进行更进一步的校验。
数据库格式的转换是通过标准组件中的标准转换服务组件实现的。标准转换服务通过XSLT将一种XML格式的文件转换成另一种格式。原则上此组件只完成相对较简单且固定的转换操作，复杂的转换和具有特殊性要求的且和一定业务逻辑相关的操作将都交给业务规则服务组件完成。
2．业务规则服务
业务规则服务是系统中对具体业务规则进行实现的一类服务组件，它们负责对业务中的逻辑进行处理，通过对数据装载、主键管理、健康档案索引等服务的调用以及对数据中具体指标的判断，执行不同的业务处理。比如说诊断信息的收集中，如果有一定业务要求，需要对某种传染病进行监控，则就在业务规则服务中加载此项服务判断，对此信息进行分段处理。
业务规则服务可以通过两种模型实现，一种是通过标准的过滤服务对其中的一些关键数据域进行抽取后重新启动一个已经被定义业务流程进行处理，另外一种可以在遵循标准接口的前提下，通过硬编码的方式将业务规则注入到系统中。
过滤服务是一种通用的业务规则服务，可以通过配置实现一些简单的数据分离过滤功能，仅仅适用于那些简单的数据过程，对于复杂的逻辑处理都应放在硬编码的业务规则实现上，不宜将过滤服务认为是一个万能服务，通过非常复杂的配置实现某一业务功能。使用硬编码的方式可以实现所有复杂的业务逻辑，硬编码过程中应将尽量通过调用数据装载服务这样的标准组件来实现通用功能，硬编码只做一些逻辑运算为主的工作。
