本小节结合基于健康档案的区域卫生信息平台的一个应用场景，根据上一小节描述的建立数据模型的方法，给出了信息模型的一个具体实例。
（一）目的
以实际用例的方式，描述健康档案数据建模过程，其内容包含信息主题域确定、类确定、类关联关系、类属性，以及最终落实到数据库逻辑设计实现的一系列分析与实现过程。
（二）场景与信息域分析
场景分析的目的是定义出数据的范围。通过开发用例模型提供相关领域事务的过程。用例模型是利用用例图捕获项目范围，以便能够完全定义设计出数据集合。场景分析一般使用故事板按照时间顺序，叙述事件发生过程以及故事中每个事件环节所涉及的参与者、以及相互间的关系和需要交换和传递的信息。以确定数据的类对象，以及类对象关联。HL7 V3对于医疗服务和管理的业务域开发出部分场景分析，提供给开发者使用。通过对场景和信息域分析，可以借鉴和应用HL7开发好的域信息模型作为健康档案数据建模的参考模板。
图3-8 新生儿登记信息域分析（略）
如上图所示为新生儿登记信息域分析D-MIM图，在图中描述了在新生儿登记事件域中所涉及的实体、角色以及相关活动事件（如新生儿监测、新生儿免疫接种等）。
（三）主题域的确定
针对上述场景应用数据概念模型主题域对《出生医学证明》中的信息进行泛化分析，将《出生医学证明》信息内容划分在事件、角色、人主题域内。
从用例分析来看，涉及以下几个域，
（1）人的基本信息，包括新生儿与父母，用实体域的子域人表示；
（2）单位信息，用实体域的子域组织表示；
（3）地点信息，用实体域的子域地点表示；
（4）检测信息，用实体域的子域检查表示；
（5）登记信息，用实体域的子域登记表示；
（四）类的确定
选取信息模型中具有的类：实体、角色、活动。
实体域
| 角色域
| 活动域
|
组织机构
| 业务人员
| 挂号
|
人员
| 联系人
| 检查
|
地点
| 患者
| |
| | 标识物
| |
（五）类关联
图3-9 《出生医学证明》泛化类关联（略）
（六）类属性
1. 与人域有关的属性：
| | 类
| 属性
| 数据类型
|
儿童身份证
| IdentifiedEntity
| Id
| SET
|
儿童姓名
| Person
| Name
| BAG
|
性别
| Person
| administrativeGenderCode
| CE
|
出生日期
| Person
| birthTime
| TS
|
出生医院类型
| Organization
| Code
| CE
|
家长姓名
| E_Person
| Name
| BAG
|
工作单位
| E_Person.Scoper.Organization
| Name
| BAG
|
联系电话
| E_Person
| Telecom
| BAG
|
住址
| E_Person
| Addr
| BAG
|
户籍住址
| E_Person
| Addr
| BAG
|
建证单位
| R_EmploymentStaff.Scoper.Organization
| Name
| BAG
|
建证单位联系电话
| R_EmploymentStaff.Scoper.Organization
| addr
| BAG
|
2. 与事件域有关的属性：
| | 类
| 属性
| 数据类型
|
建证日期
| RegistrationEvent
| effectiveTime
| GTS[0..1]
|
出生体重
| Observation
| Value
| ANY
|
儿童过敏史
| Observation
| Value
| ANY
|
接种禁忌
| Observation
| Value
| ANY
|
抗原检测结果
| Observation
| Value
| ANY
|
（七）数据库设计
根据信息模型类及类之间的关系，针对“类的确定”及“类关联”所述内容，实现面向对象数据模型数据库设计，如下图所示：
图3-10 面向对象数据模型数据库设计（略）
根据信息模型的数据类型及之间的类关系，针对“类属性”，实现实现面向对象数据模型数据库设计，如下图所示：
图3-10 数据类型类及类关系（略）
在具体实现上可以选择能够支持面向对象数据模型的数据库管理系统。
第四章 区域卫生信息平台系统架构
第一节 平台架构分析
一、平台系统功能
（一）基础功能
基于健康档案的区域卫生信息平台的使用对象主要是医疗卫生人员，最终的服务对象是居民和患者。医疗卫生人员为了更好的为居民和患者提供可靠的、可及的、连续的医疗卫生服务，需要依赖平台提供的众多服务。在平台提供的这些服务中有些是很基础但又很关键的服务，比如：个人的身份识别、健康档案索引服务、以人为中心的存储服务、数据交换服务以及数据调阅服务，下面将分别对这些基础服务进行描述。
1. 个人身份识别服务
为了建立对区域范围内各医疗机构业务联动，实现数据共享或业务协同，对各医疗机构在个人身份上必须具有统一的身份机制，此项工作是作为区域卫生信息平台建设的最为基本性的任务。
人群分类情况
从人群的整体来看，主要可分为两大类：
参保人群：即参与了基本医疗保障的本地居民，目前主要是城镇职工基本医疗保险、城镇居民基本医疗保险、新型农村合作医疗的参保人。
非参保人群：由于我国的国情决定了还有相当一部分人群（特别是在农村及经济欠发达地区）未纳入国家社会保障体系，或者是外来就医人员，这里归纳为非参保人群。
电子凭证分类情况
电子凭证是指能识别个人身份的电子依据，在这里大多是指卡，卡的种类主要有医疗保障就医凭证、医院自费就医凭证、市民卡或者其他电子凭证。
居民身份识别需求
由于发卡机构的多样性，个人手中可能会有多张与医疗卫生相关的电子凭证，如个人可能同时拥有医保卡、社保卡、妇保卡、健康卡等。在区域医疗卫生系统中，则需要将各业务条线的健康档案进行整合，因此会出现这样的问题：区域范围内持多张卡的同一患者，在系统里会被认为是多个人，即多张卡没有对同一人进行关联，这样就可能造成无法调阅某个人完整的健康档案。个人身份识别是区域医疗卫生系统所要解决的基本问题，对于本系统的建设起着至关重要的作用。
2. 健康档案索引服务
健康档案索引服务全面掌握区域卫生信息平台所有关于个人的健康信息事件，包括居民何时、何地、接受过何种医疗服务，并产生了哪些文档。
健康档案索引服务中主要记录两大类的信息：
健康事件信息：包括时间、地点、健康事件名称等；
文档目录信息：包括临床文档、预防保健文档等。
3. 以个人为中心的存储服务
在区域卫生信息平台中，针对个人的数据包括：个人注册信息库、临床诊疗信息库、公共卫生信息库、时序档案信息库。
个人注册信息主要是指个人身份信息，可供系统唯一标识个体身份，以便使相关业务数据与所记录的对象建立对应关系。
临床就诊信息主要包括就诊患者基本信息、实验室检验报告、医学影像图像检查报告、医学影像图像文件、住院相关病案、就诊患者的就诊日志信息等。
公共卫生信息是指与居民相关的疾病预防控制、精神卫生、妇幼保健等业务数据。
时序档案信息是指对与患者相关信息（包括临床就诊数据、疾病控制与管理数据等）建立的索引信息，此外还根据业务流程或预定义的规范对业务信息进行相关处理。
4. 数据交换服务
在区域卫生信息平台中，数据交换服务是一个非常重要的基础功能。平台需要从医疗机构获取各种基础的业务数据，这些数据的获取都是通过平台提供的数据交换服务来完成的。
数据交换服务至少要提供如下的一些功能：适配器管理功能、数据封装功能、数据传输功能、数据转换功能、数据路由功能、数据推送功能、数据订阅发布功能和传输监控等。
5. 数据调阅服务
区域卫生信息平台从医疗机构中采集数据，并经过一系列的处理后存入数据中心，这些过程只解决了数据怎么来、怎么存的问题，还没有解决怎么用的问题，这就要求平台提供相应的数据利用方式来为医疗卫生人员提供服务。这些数据利用的方式包括：数据调阅、业务协同、辅助决策等，其中业务协同和辅助决策可以被看成是在平台加载的应用系统，而数据调阅因其通用性和安全性要求则被视为平台的基础功能给予提供。数据调阅服务是为医疗卫生人员提供的一种基于Web方式安全的访问健康档案的功能。
（二）互联互通性
目前医疗卫生机构中存在大量处理业务的信息系统，例如：医院内的HIS、CIS、LIS、RIS、PACS等系统，社区服务中心内的HIS、LIS、CHIS等系统，公共卫生条线的疾控、妇幼等系统，这些业务系统被统称为基本业务信息系统（Point Of Service，POS）。在现有条件下，要实现医疗机构内部信息系统应用之间的互联互通问题，有两种方式，其一是为所有医疗卫生机构新建业务系统，其二是建设区域卫生信息平台来与医疗机构内部信息系统应用交互。平台与医疗机构内部信息系统应用的交互能力就是所谓的互联互通性（Interoperbility）。
平台需要从医疗机构内部信息系统应用中获取数据，平台也向医疗机构内部信息系统应用提供信息共享、协同服务等功能。平台与医疗机构内部信息系统应用之间的交互被视为互联互通性一个应用场景。平台从医疗机构内部信息系统应用获取数据后需要内部各构件协同工作来提供对外服务，例如：注册服务构件与全程健康档案服务构件之间交互，这些平台内部构件之间的交互也是互联互通性的一个应用场景。
概括而言，互联互通性是系统与系统之间进行协作的技术规范，它包含两个层面的含义，第一个层面是指系统与系统之间能够进行数据交换，即消息层互联；第二个层面是指系统能够认识并准确理解被交换数据的含义并且按照预期操作进行，即语义层互通。
互联互通规范主要包含两大类内容，其一为描述医疗机构内部信息系统应用与区域卫生信息平台之间的交互接口，被称为健康档案互联互通规范；其二为描述区域卫生信息平台内部各构件之间的协作行为，被称为平台互联互通规范。
二、数据来源模式
（一）孤岛数据
孤岛数据是指那些不能相互共享利用、孤立的、分散的业务数据。根据当前我国医疗卫生信息化的现状，可以看出多数的医院内部信息系统存在“信息孤岛”的现象，从而也就产生了相应的孤岛数据。典型的孤岛数据有：
1. 社区健康档案系统数据
社区卫生服务中心所使用的健康档案管理系统，大多数是为该社区的居民建立个人基本健康档案，一旦建档完成后就保存在本地的服务器上，绝大多数的建档档案数据独立存在于本社区内，既没有被临床诊疗相关的业务系统“激活”，也没有被上级机构所采集共享以实现跨社区的联动。该系统完全为建档而建档，建好的档也就成为“死档”，没能体现应有的利用价值。
2. 医院信息系统（HIS）数据
HIS系统一般是当前医院首先建设的信息系统，主要是为实现以收费为中心的医院内部信息管理，早期建设的HIS系统也是完全独立于医院内部，与医院外的业务系统无任何联动，有的甚至与医院内部其他信息系统（如LIS、CIS等）也毫无关联（因为往往同一家医院HIS、LIS、CIS的开发分别由不同的开发商承担，医院难以协调开发商对多系统进行整合）。
3. LIS数据
LIS是相对专业化程度较高的系统，每家医院独立使用这套系统，LIS数据仅存在于本医院内部，当病人跨院就诊时，往往需要重新检验，造成了大量的人力、财力的浪费，往往这也是造成老百姓看病难、看病贵的主要原因。
4. PACS数据
与LIS类似，PACS系统专业化程度高，由于产生的医学影像数据也只存在于本医院内，造成病人跨院就诊时重复检查，也是孤岛数据的一个重要表现。
5. 医院体检系统数据
医院建设的体检系统也是完全独立的，仅记录来本院体检人员的信息，与其他医院内部业务系统无业务联动。
6. 其他
除以上所涉及到的孤岛数据外，其他医疗机构也存在类似的情况，如疾病预防控制中心的慢病管理系统等，往往也是独立存在的“孤岛”。孤岛数据的存在给医疗卫生从业人员带来的很多的麻烦，如对于每个孤岛系统都需要不断录入人员信息数据，极大地加重了医疗机构从业人员（特别是基层医疗机构，其中以社区卫生服务中心尤为突出）的工作量，导致工作效率低下等问题。
（二）烟囱数据
烟囱数据是指以业务条线为主的业务数据。疾病预防控制业务系统、妇幼保健业务系统中的数据是典型的烟囱数据。目前我国广大区域内疾控业务多以业务条线为主，如传染病管理，每一个病重都是一个业务条线，从国家到省、地区、县市、乡镇的纵向管理，与其他业务条线也是平行的，同样也就造成了相关工作人员，特别是基层数据录入人员的工作负担。从管理上来看，烟囱数据的存在也造成了相关业务条强块弱的局面，为管理层带来了很大挑战。
（三）无系统数据
由于区域内各医疗机构信息化水平参差不齐，很多社区卫生服务中心、卫生服务站（特别是中西部偏远欠发达地区），并没有建成区域信息平台所需要的医疗机构内部信息系统（POS），因此造成基础数据无法采集。对于这类区域医疗机构，需要在新建信息系统时，基于本区域平台来建设，平台提供将提供相关业务的数据标准，以便新建的系统能良好地集成到区域卫生信息平台。
三、数据存储类型
业务数据的类型主要包括文档数据、操作型数据、辅助决策型数据。文档数据：以文档形式存在于平台中的临床和预防保健业务数据，例如检验报告、处方，传染病报告卡等。这些数据是结果数据。操作型数据：操作型数据存储，在本指南中一般是指平台从业务系统中采集、汇总、供实时业务查询和统计使用的数据：
操作型数据是从医疗机构内部信息系统采集上来的，不是由操作型数据所在的平台产生的；
操作型数据是从多个医疗机构内部信息系统数据源采集上来，并加以汇总的数据，不是医疗机构内部信息系统数据的简单采集和堆积；
从逻辑上操作型的数据结构基本与原来医疗机构内部信息系统数据源的类似，但是在汇总时会使用统一的基础数据（例如居民信息、机构信息、代码等），也会消除一些冗余信息；
操作型数据主要服务于统一的即时查询和实时的统计。
辅助决策数据：存储在数据仓库中，以主题方式组织，是经过二次加工的历史数据。
四、系统架构类型
区域卫生信息平台涉及到与居民健康相关的所有业务，因此其业务数据具有类型多、容量大的特点。根据业务数据的特点，对数据存储的要求也不尽相同。系统架构与数据存储的模式分为集中式、分布式和混合式。
集中式存储方式：集中存储的优点是效率高且方法简单，但扩展性和灵活适应性受到一定局限。在本系统建设中，对于居民基本信息（包括姓名、性别、出生年月、身份证号、社会保险号等），由于其使用频率高，数据容量相对较小，可采用数据中心集中式存储的方式；对于公共卫生信息，如疾病预防数据、妇幼保健数据、精神卫生数据，则采用中心集中存储的模式，这样可以保证该类数据的安全性。
分布式存储方式：分布存储一般说来效率较低，技术实现复杂，但其扩展性和灵活性有很大优势。在本系统建设中，对于医学影像信息，其数据量大，可采用分布式的存储模式，这类信息通过注册到区域卫生信息平台，当医疗机构需要调阅时，可通过平台查询获取数据所存储的地址（一般为某医疗机构），再从目的地获取所需要的信息。这样既减轻了平台的负载，也提高了数据的调阅效率，但缺点是对医疗机构之间的网络要求较高，区域范围内各医疗机构之间必须是双向网络，而且需要保证一定的带宽。
混合存储方式（联邦式）：对于其他业务数据（如实验室检验数据、就诊记录数据），则可以根据实际的业务需求，采用分布式存储＋集中式存储的混合模式。
总的说来，区域卫生信息平台可以支持这三种架构来实现数据存储。
五、数据利用模式
（一）健康档案信息共享
本平台建立后，首先可以解决信息共享的需求。原先分布在医疗机构、社区、公共卫生机构内的关于区域内居民的健康信息均可以交换整合到本平台中的卫生信息数据中心，各医疗卫生机构可以通过平台调阅本区域居民的健康档案和诊疗信息。
1. 诊疗信息共享
诊疗信息共享是区域卫生信息平台建设最基本的目标，也是本平台的核心业务。通过将居民在每家医院的诊疗数据统一采集，形成每个居民完整的诊疗信息档案，供居民自己、临床医生、责任全科医生及相关机构查看。
诊疗信息共享功能范围要求包括：数据中心患者主索引的建立与调阅；就诊患者就诊记录的采集、整合与调阅；实验室检验报告的采集、整合与调阅；医学影像检查报告的采集、整合与调阅；住院病案的采集、整合与调阅等等。
2. 其他卫生服务信息共享
通过将居民的健康档案数据统一采集，实现区域卫生信息资源的互通，为每位社区居民形成一份完整的个人健康档案。社区卫生服务中心/站点和社区卫生服务团队可以从平台调阅区内各社区卫生服务中心的健康档案信息。居民自己查阅并管理自己的健康档案。
（二）医疗卫生业务协同
业务协同需求是指基于本平台实现医疗机构之间的业务协同，医疗机构、社区及纵向业务联动等。在这里医疗机构之间（含医院与社区卫生服务机构之间）在医疗业务上的协同，我们称之为医疗业务协同；如果协同的范围不仅是医院、社区，还有公共卫生机构，协同的内容包括临床和预防保健，我们称之为卫生业务联动。这类应用也是本平台的亮点所在。它集中提现了平台的价值，以及建设平台的必要性。
1. 医疗服务协同
医疗业务协同是指医疗机构与医疗机构之间通过平台实现业务的协同。通过医疗业务协同，可以有效利用医疗资源，降低医疗成本，提高医疗质量。具体而言包括：可包括专家门诊预约、专家远程咨询会诊、跨医院转诊转检、双向转诊，治疗安全警示、药物过敏警示、重复检验检查提示等。
2. 卫生业务联动
卫生业务的联动主要体现在区域范围内各医院、社区卫生服务中心与疾控、妇幼保健等业务条线的业务联动。由于许多卫生服务的信息源头是二、三级医院，例如产妇在产科医院分娩，病人在二、三级医院手术。产妇出院后，社区可以开展后续的产妇保健工作；同样病人手术出院后，需要康复指导。目前由于信息不通，社区卫生服务人员不能及时获得二、三级医院的信息，无法开展高效的卫生服务。
（三）业务管理和辅助决策
1. 医疗卫生业务管理
业务管理需求是指医疗机构内部信息系统所产生的数据对社区业务和条线机构业务进行管理的需求，包括：基本医疗保障业务管理、医疗业务管理、条线业务管理、社区卫生综合管理。此外为了更好地支撑社区卫生服务，还需要对社区全科医生、全科团队和社区卫生机构做绩效考核，对社区卫生机构做财务管理，对社区卫生资源进行管理。
2. 医疗卫生辅助决策
传统的业务管理难以满足管理和决策的需要。管理者/业务人员自身掌握的知识和经验有限，难以从大量数据中得出有价值的信息，从而做出判断或决策。通过辅助决策从大量数据中找出规律，利用数学模型产生信息，为决策者提供分析问题、建立模型等，帮助管理者/业务人员做出判断或决策。辅助决策需求，包括基本医疗保障管理辅助决策、条线管理辅助决策、综合管理辅助决策。
六、隐私保护与信息安全
隐私保护及信息安全是区域卫生信息平台所要重点解决的问题。主要体现在如下几个方面：
（一）隐私保护的需求
居民同意；匿名化服务；根据病种、角色等多维度授权；关键信息（字段级、记录级、文件级）加密存储；
（二）数据调阅对安全的需求
身份认证的需求；角色授权的需求；责任认定的需求；电子签名；时间戳。
（三）应用系统对安全的需求
单点登录；统一授权；应用审计。
第二节 平台框架
根据对各地区域卫生信息化发展目标和需求的分析，基于健康档案的区域卫生信息平台建设应该是在各地目前各医疗卫生机构信息系统的基础上构建一个基于卫生信息数据中心同于EHA数据中心，制定统一的标准，有效整合医疗卫生业务应用系统，形成一个互联互通的医疗卫生业务协作网络。平台总体架构如下图所示：
图4-1 系统总体架构图（略）
系统总体架构分为两个层次：区域卫生管理层和辖区卫生机构层。
区域卫生管理层表示区域卫生信息平台的管理中心，在实际应用中可以是一个地市级卫生信息数据中心，也可以是更高一级的数据中心。区域卫生管理层主要提供一系列服务，作为服务于卫生医疗区域（如省、地区、县市卫生管理机构）的单一实例而存在，主要服务组件包括注册服务、公卫数据服务、医疗数据服务、全程健康档案服务、数据仓库服务等。
辖区卫生机构层，是指在所管辖的区域范围内相关医疗卫生机构（包括三级医院、二级医院、社区卫生服务中心、公共卫生机构等）所有业务应用系统，这些系统生成、收集、管理和使用那些可以公布在与区域范围内居民相关的健康数据，包括临床医疗数据、健康档案数据、公共卫生管理数据等。这些系统分布在所有为居民提供医疗卫生机构的服务点，为广大老百姓提供各类健康服务。
区域卫生管理层和辖区卫生机构层之间通过区域卫生信息应用访问层来进行信息交互，以实现健康档案的互联互通性，信息访问层所提供的服务主要包括两个方面：一方面提供通信总线服务，如消息传输服务、消息路由等；另一方面提供应用软件通用的系统管理功能，如安全管理、隐私管理、应用审计等。
第三节 平台构件组成
一、注册服务
注册服务包括对个人、医疗卫生人员、医疗卫生机构、医疗卫生术语的注册管理服务，系统对这些实体提供唯一的标识。针对各类实体形成各类注册库（如个人注册库、医疗卫生机构注册库等），每个注册库都具有管理和解决单个实体具有多个标识符问题的能力。注册库保有一个内部的非公布的标识符。
（一）个人注册服务
个人注册服务是指在一定区域管辖范围内，形成一个个人注册库，个人的健康标识号、基本信息被安全地保存和维护着，提供给区域卫生信息平台所使用，并可为医疗就诊及公共卫生相关的业务系统提供人员身份识别功能。
个人注册库主要扮演着两大角色。其一，它是唯一的权威信息来源，并尽可能地成为唯一的个人基本信息来源，用于医疗卫生信息系统确认一个人是某个居民或患者。其二，解决在跨越多个系统时用到居民身份唯一性识别问题。个人注册服务是区域卫生信息平台正常运行所不可或缺的，以确保记录在健康档案中的每个人被唯一地标识，他们的数据被一致地管理且永不会丢失。
该注册服务主要由各医院、社区和公共卫生机构来使用，完成居民的注册功能。
（二）医疗卫生人员注册服务
医疗卫生人员注册库，是一个单一的目录服务，为本区域内所有卫生管理机构的医疗服务提供者，包括全科医生、专科医生、护士、实验室医师、医学影像专业人员、疾病预防控制专业人员、妇幼保健人员及其他从事与居民健康服务相关的从业人员，系统为每一位医疗卫生人员分配一个唯一的标识，并提供给平台以及与平台交互的系统和用户所使用。
该功能的基本流程为，各医院、社区和公共卫生机构提供所辖医疗卫生人员基础信息给医政，医政完成审核并将这些医疗卫生人员信息在平台上给予注册。
（三）医疗卫生机构注册服务
通过建立医疗卫生机构注册库，提供本区域内所有医疗机构的综合目录，相关的机构包括二三级医院、社区卫生服务中心、疾病预防控制中心、卫生监督所、妇幼保健所等。系统为每个机构分配唯一的标识，可以解决居民所获取的医疗卫生服务场所唯一性识别问题，从而保证在维护居民健康信息的不同系统中使用统一的规范化的标识符，同时也满足区域卫生信息平台层与下属医疗卫生机构服务点层的互联互通要求。
