卫生部办公厅关于印发《基于健康档案的区域卫生信息平台建设指南(试行)》的通知

卫生部办公厅关于印发《基于健康档案的区域卫生信息平台建设指南（试行）》的通知
各省、自治区、直辖市卫生厅局，新疆生产建设兵团卫生局：
为积极配合深化医药卫生体制改革，推进以健康档案为核心的区域卫生信息化建设，根据部领导指示精神，按照卫生部发布的《健康档案基本架构与数据标准（试行）》（卫办发〔2009〕46号），我部组织编制了《基于健康档案的区域卫生信息平台建设指南（试行）》。现印发你们，供参照试行（建设指南文本在卫生部网站下载），并请在试行过程中及时提出修改建议和意见，以便进一步修改完善。在此基础上，我部还将组织专家研制基于健康档案的区域卫生信息平台技术解决方案，为各地区域卫生信息化建设提供进一步技术指导。
联 系 人：卫生部统计信息中心 胡建平 汤学军
联系电话：（010）68792481、68792477
附件：基于健康档案的区域卫生信息平台建设指南（试行）
二○○九年五月三十一日
附件：
基于健康档案的
区域卫生信息平台建设指南（试行）
（卫生部信息化工作领导小组办公室 二OO九年五月）
目 录
第一章 前言
第一节 编制背景
第二节 关键概念
第三节 编制目的
第四节 适用范围
第五节 主要内容
第二章 区域卫生信息化需求分析
第一节 卫生信息化建设现状
一、 国外区域卫生信息化发展情况
二、 我国卫生信息化建设现状
三、 我国区域卫生信息化发展面临的问题与挑战
第二节 区域卫生信息平台用户分析
一、 居民个人
二、 医疗卫生服务机构
三、 公共卫生专业机构
四、 卫生行政部门
五、 其他卫生相关单位与部门
第三节 区域卫生信息平台业务需求分析
一、 医疗卫生服务的需求
二、 社区卫生服务的需求
三、 公共卫生服务
四、 综合卫生管理的需求
第三章 居民健康档案信息架构
第一节 信息架构概述
一、 信息架构的内容
二、 数据模型的重要性
第二节 健康档案的信息内容
一、 健康档案的系统架构
二、 健康档案的基本内容
三、 健康档案的信息来源
第三节 健康档案数据建模方法
一、 数据概念模型
二、 数据逻辑模型
第四节 数据模型实例
一、 数据建模方法
二、 数据建模实例
第四章 区域卫生信息平台系统架构
第一节 平台架构分析
一、 平台系统功能
二、 数据来源模式
三、 数据存储类型
四、 系统架构类型
五、 数据利用模式
六、 隐私保护与信息安全
第二节 平台框架
第三节 平台构件组成
一、 注册服务
二、 健康档案存储服务
三、 医疗卫生信息共享和协同服务
四、 全程健康档案服务
五、 信息接口服务
六、 医疗机构内部信息系统数据交换
七、 数据仓库
八、 健康档案浏览器
第五章 区域卫生信息平台技术架构
第一节 总体技术架构
第二节 数据交换技术方案
一、 企业服务总线
二、 数据接口方式
三、 业务组件服务
四、 运行监控管理
五、 平台配置管理
六、 技术方案选型
第三节 数据存储技术方案
一、 数据存储结构
二、 技术方案选型
第四节 数据展示技术方案
一、 健康档案浏览器
二、 技术方案选型
第五节 硬件网络支撑平台
一、 网络总体结构
二、 硬件平台要求
三、 几种组网方式
第六节 安全保障体系方案
一、 安全等级
二、 物理安全
三、 系统安全
四、 数据安全
五、 应用安全
六、 安全管理
第七节 标准规范管理方案
一、 标准规范建设原则
二、 遵循与参考的标准
三、 标准规范体系管理
第六章 区域卫生信息平台部署模式
第一节 平台应用架构
第二节 纵向分级部署模式
第三节 横向扩展布署模式
第四节 其他应用模式
第七章 附录
第一节 缩写
第二节 主要参考文献
第一章 前言
第一节 编制背景
《中共中央 国务院关于深化医药卫生体制改革的意见》和《国务院关于印发医药卫生体制改革近期重点实施方案（2009-2011年）的通知》正式发布了。从现在起到2020年将是我国卫生事业发展的关键时期。工业化、城镇化、人口老龄化、疾病谱改变以及生态环境的变化，给居民健康带来新的严峻挑战。同时，随着经济的发展和人民生活水平的不断提高，人民群众对医疗卫生服务将提出更高要求。目前，在我国卫生服务体系中还存在着医疗服务费用增长过快、医疗服务可及性差、医疗资源配置不均衡、卫生服务效率不高、医疗服务质量参差不齐等问题，如果不进行改革，将难以应对这些新的挑战。深化医药卫生体制改革事关百姓切身利益和社会和谐发展。众所周知，构建富有效率的卫生体制是一个世界性难题，纵观各国卫生体制改革之路可以看出，尽管改革思路和方法有所不同，但在利用信息化手段推动卫生体制改革，更好的解决医疗卫生服务需要与服务供给的平衡方面都有着共同的期望。
当前，世界已进入信息时代，信息技术的发展，不仅提高了人们的工作和生活效率，也改变了人们的生产和生活方式。在《2006-2020年国家信息化发展战略》中，党中央、国务院将信息化工作提升到我国现代化建设全局的战略高度，明确提出信息化是全面建设小康社会、构建社会主义和谐社会和建设创新型国家的迫切需要和必然选择。在卫生领域则要求统筹规划电子病历应用发展，促进医疗、医药和医保机构的信息共享和业务协同，满足医疗体制改革的要求。
在医疗卫生服务过程中，大家迫切希望通过建立适用共享的卫生信息系统，使医疗服务人员在任何时间、任何地点都能及时获取必要的信息，以支持高质量的医疗服务；使公共卫生工作者能全面掌控人群健康信息，做好疾病预防、控制和健康促进工作；使居民能掌握和获取自己完整的健康资料，参与健康管理，享受持续、跨地区、跨机构的医疗卫生服务；使卫生管理者能动态掌握卫生服务资源和利用信息，实现科学管理和决策，从而达到有效地控制医疗费用的不合理增长、减少医疗差错、提高医疗与服务质量的目的。为实现这一目标，需要建立以居民健康档案为核心的区域信息共享平台作为支撑。通过区域卫生信息平台，将分散在不同机构的健康数据整合为一个逻辑完整的信息整体，满足与其相关的各种机构和人员需要。这是一种全新的卫生信息化建设模式，世界许多发达国家，已将这种模式作为卫生信息化发展的重要战略方向。
2000年9月加拿大由联邦政府注资成立了名为Infoway的非盈利性机构，领导和负责全国范围内电子健康信息、兼容的标准、通信技术的开发和实施。2002年开始，Infoway投资12亿加元开发区域卫生信息共享基础架构，推动地方卫生信息化，同时加大建设投入，计划于2009年为50%的加拿大人口建立电子健康档案，于2020年覆盖全国。
美国前总统布什在2004年众议院的年度国情咨文中专门强调医院信息系统建设，指出将医疗保健记录计算机化，可以避免严重的医疗差错，降低成本，提高医疗水平，并要求在10年内，确保绝大多数美国人拥有共享的电子健康记录。美国政府2004年提出的这一战略目标正面临严峻的挑战，为此今年在新任总统奥巴马的7870亿美元复苏经济刺激方案中，拿出500亿美元用于推进医疗卫生信息化发展。
2003年底到2004年，英国政府陆续与多家跨国卫生信息化巨头签署了为期10年、总金额逾60亿英镑的合同，拟搭建一个全国性的卫生信息网，部署一系列应用服务。通过这一信息网，患者可以选择并预定医院服务、获取自身的电子病历档案并办理出院手续等；医生可以实现包括电子病历、网上预约、电子处方、医学影像共享及远程医疗咨询等。目前，该全国性卫生信息网已经取得了阶段性成就，成为欧洲国家级卫生信息化建设的典型代表。
不同医疗体制和医疗市场环境的发达国家实践表明卫生信息共享能够提高医疗服务效率、服务质量、医疗服务的可及性，降低医疗成本及降低医疗风险。区域卫生信息化建设已被公认是未来医疗行业的发展方向。
医药卫生信息系统建设是深化医药卫生体制改革、建设服务型政府、促进医药卫生事业健康发展的重要手段和技术支撑。《中共中央 国务院关于深化医药卫生体制改革的意见》明确提出：大力推进医药卫生信息化建设。以推进公共卫生、医疗、医保、药品、财务监管信息化建设为着力点，整合资源、加强信息标准化和公共信息平台建设，逐步实现统一高效、互联互通。要求自2009年开始逐步为城乡居民建立健康档案。
为认真贯彻落实党中央、国务院关于深化医疗卫生体制改革精神，指导我国以健康档案为基础的区域卫生信息化建设规范、科学、有效推进，本指南在遵循卫生部健康档案标准（试行）（健康档案基本架构与数据集标准、健康档案相关卫生服务数据集标准），总结和分析部分地区开展区域卫生信息化建设的经验和教训基础上，提出我国区域卫生信息化平台的基础模型，从业务体系、信息架构、系统架构、技术架构、应用模式等方面阐述我国区域卫生信息平台建设思路，为实施区域卫生信息化建设工作奠定基础。第二节 关键概念
健康管理。健康管理是基于个人健康档案基础上的个性化健康事务管理服务，它是建立在现代医学和信息化管理技术模式上，从社会、心理、环境、营养、运动的角度对个人提供全面的健康促进服务，帮助、指导人们有效地把握与维护自身的健康。
健康档案与电子健康档案。健康档案是居民健康管理（疾病防治、健康保护、健康促进等）过程的规范、科学记录。是以居民个人健康为核心、贯穿整个生命过程、涵盖各种健康相关因素、实现信息多渠道动态收集、满足居民自身需要和健康管理的信息资源（文件记录）。电子健康档案，也称为电子健康记录，即电子化的健康档案，是关于医疗保健对象健康状况的信息资源库，该信息资源库以计算机可处理的形式存在，并且能够安全的存储和传输，各级授权用户均可访问。
病历与电子病历。病历是医疗机构在特定时间，对门诊、住院患者临床诊断治疗过程的系统、规范记录。健康档案与病历有区别，但更有联系。病历是健康档案的主要信息来源和重要组成部分，健康档案对病历的信息需求，并非病历的全部，具有高度的目的性和抽象性。电子病历，即电子化的病历，是记录医疗诊治对象健康状况及相关医疗服务活动记录的信息资源库，该信息资源库以计算机可处理的形式存在，并且能够安全的存储和传输，医院内授权用户可对其进行访问。
区域。具有独立财政支撑，具有完整的医疗卫生体系的行政区划地区。一般说来，区域至少是区、县，也可以是 更大的地市、直辖市，甚至全国、全球。独立财政支撑指的是独立的税收和财政预算。这里的区域概念主要指行政区划中的地区（地级市、或副省级城市及直辖市的区）。
街道和乡镇不是本文所谓的区域，原因是街道不具备独立的财政体系，乡镇虽有独立的财政体系，但是不具有完整的疾控、卫监、妇幼等公共卫生机构，
基本业务信息系统。在区域卫生信息平台建立之前，医疗卫生机构已经有大量正在运行和使用的与健康档案信息相关的卫生业务信息系统，这些系统称为基本业务信息系统或医疗卫生机构内部信息系统。典型的基本业务系统包括医院信息系统、社区卫生服务信息系统和公共卫生信息系统。
目前我国基本业务信息系统处于信息孤岛和信息烟囱的状态，亟待通过建立区域卫生信息平台实现基本业务系统的信息交换，并在此基础之上实现信息共享、业务协同。
区域卫生信息平台。区域卫生信息平台，是连接区域内的医疗卫生机构基本业务信息系统的数据交换和共享平台，是不同系统间进行信息整合的基础和载体。从业务角度看，平台可支撑多种业务，而非仅服务于特定应用层面。
互联互通性。指一个系统或应用软件能够正确使用其他系统或应用软件产生的数据的能力。即系统之间能够传输数据，并且这些数据能够被准确地理解。一般将互联互通性分为功能（语法）互联互通性和语义互联互通性。功能（语法）互联互通性是指两个或多个系统之间通过设定功能和定义报文结构进行信息交换的能力。语义互联互通性是指两个或多个系统共享的信息能够按原有定义被理解的能力。语义互联互通性是信息共享的前提条件，涉及数据的整合、概念、术语、域模型和数据模型以及信息（数据）框架的一致性问题，确定信息的结构和内容。
在本指南中，互联互通性包括两个方面：1）描述医疗卫生机构内部信息系统与区域卫生信息平台之间的信息共享与交换，称为健康档案互联互通性；2）描述区域卫生信息平台内部各构件之间的协作行为，称为区域卫生信息平台互联互通性。
基于健康档案的区域卫生信息平台。以区域内健康档案信息的采集、存储为基础，能够自动产生、分发、推送工作任务清单，为区域内各类卫生机构开展医疗卫生服务活动提供支撑的卫生信息平台。平台主要以服务居民为中心，兼顾卫生管理和辅助决策的需要。基于健康档案的区域卫生信息平台，在下文中简称为本平台。
患者、居民和个人。本指南中患者、居民和个人具有相同的意义，指通过医疗卫生服务体系获取和接受服务的个体。在本指南中这些术语可互换使用。第三节 编制目的
新医改方案提出从2009年开始，逐步在全国建立统一的居民健康档案，为此迫切需要制定一个规范性文件指导和规划各地建立全国统一的居民电子健康档案，以保证各地区域卫生信息化建设科学合理有效地进行，提高系统建设的效率和质量，降低系统建设的风险。
本指南为推进区域健康档案信息的交换和共享提出了架构框架和共同的定义，为国内区域卫生信息化建设提供战略性参考文件。
本指南提供了平台组件和软件服务的相关概念定义和建设思路，可以大大提高各地卫生信息平台具体建设方案的设计效率，节约人力、物力资源。
本指南是在一个概念层次上关于工作流程、信息与功能的介绍，可以使开发商能够清晰了解平台建设需求，缩短平台建设周期。第四节 适用范围
本指南的区域主要是指地级市。本指南主要为地级市的区域卫生信息平台建设提供指导。另外，跨地市级应用，需要省级平台，甚至国家级平台的支撑，所以本指南也可为省级和国家级平台建设提供参考。
本指南以建立全国统一的居民健康档案为目标，主要通过对我国卫生业务体系和医疗卫生体制改革目标需求进行分析，提出基于健康档案的区域卫生信息平台建设方案的指导意见。本指南主要设计出区域卫生信息平台建设的核心--健康档案的信息架构，在此基础上设计基于健康档案的区域卫生信息平台核心的系统架构和技术架构模型，因此本指南只是对整个区域卫生信息平台建设基础模型的总体设计和规范指南，区域卫生信息平台建设的业务细节，技术细节和数据标准等内容不在本指南中做详细描述。同时，本指南只涉及医疗卫生机构内部各业务信息系统与健康档案有关的信息交换，不涉及基本业务信息系统的内部功能。
本指南可供全国各地区在区域卫生信息化建设的技术方案制定、工程招投标和系统实施过程中参考使用。
第五节 主要内容
本指南分为六章和两个附录，除本章前言外，分别是：第二章业务分析、第三章信息架构、第四章系统架构、第五章技术架构和第六章应用模式。
第二章业务分析，从业务角度分析了对平台的需求，提出了必须通过平台才能够开展的业务，以及建立平台之后可以更好开展的业务。通过以人为主线梳理业务，可以发现通过建立统一的电子健康档案可以有效地支撑这些业务。
第三章信息架构，从信息角度分析了健康档案的内容、来源、存储和管理机制，给出了电子健康档案的信息架构。
第四章系统架构，结合平台的业务需求和健康档案的信息架构，提出基于健康档案的区域卫生信息平台的系统功能架构。
第五章技术架构，针对平台的系统功能，给出可能的技术实现选择。
第六章应用模式，结合不同业务和各地情况给出平台的应用模式。
第二章 区域卫生信息化需求分析
“新医改”方案把“建立实用共享的医药卫生信息系统”列为“八大支柱”之一，信息化被提到前所未有的高度，遇到了难得的发展机遇。这就要求卫生信息化建设必须服务于服从于医改，从而决定了卫生信息化建设思路必须摈弃原有单个业务驱动模式，重点转向“以人为本”的健康信息系统建设，以健康档案的为核心的区域卫生信息系统建设将成为卫生信息化新的建设重点。第一节 卫生信息化建设现状
一、国外区域卫生信息化发展情况
近些年来，英国、美国、加拿大、澳大利亚等一些国家先后投入巨资开展了国家和地方级以电子健康档案和电子病历数据共享为核心的区域性卫生信息化建设。这些举措的主要推动力来自于伦理上的需求--最大限度地保证公民的医疗质量和安全性，以提升整体医疗服务质量、提高医疗服务可及性、降低医疗费用、减少医疗风险。其成效可能需要一定的时间方能显现。
英国从1998年开始策划电子健康记录应用，主要目的是提高患者的安全性。国家卫生署制定了国民卫生服务信息战略项目（National Programme for IT， NpfIT），全面将计算机应用引入卫生服务领域，项目利用七年时间分阶段在全科医生中实施。项目目标就是保证医疗专业人员，患者和护理人员 “在正确的时间和地点，拥有正确的信息”，以提高患者的医疗与服务质量，
2004年1月20日美国前总统布什在美国众议院发表国情咨文时提出，要在10年内为全体美国公民建立电子健康档案。2005年，美国国家卫生信息网为实施本计划选择了4家全球领先的信息技术厂商作为总集成商，在四大试点区域分别开发全国卫生信息网络架构原型，研究包括电子健康档案在内的多种医疗应用系统之间互通协作能力和业务模型。美国现任总统奥巴马提出投资500亿美元发展电子医疗信息技术系统，以减少医疗差错，挽救生命，节省开支。
2002年，澳大利亚国家电子健康档案工作组推出了一套电子健康档案系统MediConnect，该系统的预计完成时间为十年，现在已经进入了第四年。根据澳大利亚专家测评，电子健康档案系统投入后每年可创造超过50亿澳元收益，其中约23.1亿澳元（21亿加元）是避免药物不良事件（ADE）所节约的费用。
2000年9月，加拿大成立了名为Infoway的机构以推动国家以及区域卫生信息网的建设。2002年开始，Infoway宣布计划投资数亿美元促进医疗机构及其他终端用户对信息技术的接受，建立全国性的电子健康档案系统、药品信息系统、实验室信息系统、系统影像系统、公共卫生信息系统和远程医疗系统；建立用户、医疗服务机构的统一识别系统以及基础架构和标准的研究，并计划在2009年为50%的加拿大人建立电子健康档案，2020年覆盖到全部人口。
2004年8月，法国通过一项针对国家医疗计划重组的新法律。这项法律确定要建立个人医疗档案，且该医疗档案由患者所有（患者同意方能使用），其目标是为患者提供持续的医疗服务，其经济目标是为了更好地控制医疗成本（比如取消多余的辅助性检查）。
通过卫生信息共享来提高医疗服务效率、提高医疗服务质量、提高医疗服务可及性、降低医疗成本、以及降低医疗风险的作用已经得到充分验证，并被公认是未来卫生信息化建设的发展方向。目前，越来越多的国家已经认识到开展国家级及地方级的区域卫生信息共享的核心内容是居民健康档案。
区域卫生信息化和电子健康档案建设是一项十分复杂、难度较大的系统工程，在实施过程中，仍然面临诸多挑战，各国的各种探讨和建设实践，为我国基于健康档案的区域卫生信息化建设提供了可供借鉴的经验。
二、我国卫生信息化建设现状
在信息技术飞速发展的过程中，我国卫生信息化建设经历了从无到有，从局部到全局，从医院向其他各个业务领域不断渗透的过程，卫生信息化逐渐成为医疗卫生服务体系不可或缺的部分。
我国卫生信息化建设具有明显的阶段性，可以将其分为三个阶段，目前整体上处于第二阶段，部分地区开始进入第三阶段。第一个阶段是在21世纪前的计算机技术应用阶段，如医院财务管理、收费管理、药品管理等，将传统业务管理模式计算机化，实现计算机技术在医疗卫生系统的广泛应用；第二个阶段是进入21世纪后，依托计算机网络技术加快业务领域的信息系统建设阶段，如公共卫生、卫生监督、妇幼保健、新型农村合作医疗等信息系统建设。SARS危机以后，卫生部在几年时间内，完成了覆盖中央、省、市、县、乡五级的网络直报系统，各级疾病预防控制机构和卫生行政部门可以同时在线报告信息，极大地提高了传染病疫情等报告的及时性和准确性。同时，加强了国家和省两级突发公共卫生应急指挥决策系统建设，极大地提高了突发公共卫生事件的应急反应和危机处置能力。在医院，信息化建设的重点转移到临床信息系统建设，如逐步推广HIS、PACS、RIS、LIS等临床信息系统。
前两个阶段的信息化建设，主要依赖于计算机和网络技术的发展，与其他行业相比，总体水平还很落后。
卫生部制定的《全国卫生信息化发展规划纲要2003-2010年》中，明确提出了区域卫生信息化的工作目标：“围绕国家卫生信息化建设目标选择信息化基础较好的地区，开展以地（市）县（区）范围为单元的区域卫生信息化建设试点和研究工作，建立区域卫生信息化示范区。区域化卫生信息系统包括电子政务、医保互通、社区服务、双向转诊、居民健康档案、远程医疗、网络健康教育与咨询，实现预防保健、医疗服务和卫生管理一体化的信息化应用系统。至2006年，拟建立5-8个区域卫生信息化示范区，实现区域内各卫生系统信息网上交换、区域内医疗卫生信息集中存储与管理，资源共享的卫生信息化区域，总结经验后，逐步推广。”
根据规划纲要的要求和本地卫生业务发展的需要，一些经济发达地区开始积极探索建立本地区的区域卫生信息化建设，取得了明显进展。如，上海市闵行区、广州番禺区和福建厦门市都开展了基于健康档案的区域卫生信息化建设工作，部分实现了区域居民健康档案在医院、社区之间的共享以及基于健康档案的“电子双向转诊服务”。
由于医疗卫生行业的特殊性，卫生信息化建设发展速度目前还落后于其他行业。第一，卫生信息系统的业务内容复杂。仅以医院的收费系统为例，就涉及到几千个专业的检查项目、几十万个药品名称，其复杂程度远远大于银行的存取款系统；第二，卫生信息系统涉及纷繁复杂的规范以及标准，仅各种医学术语就多达200多万条。而且诸多标准仍在不断研究发展之中，全球卫生信息系统的互联互通，均在规范与标准方面遭遇巨大阻力；第三，医疗卫生信息系统涉及不同的运行机构、管理部门以及业务类别，但是传统的卫生管理体制导致部门垂直管理，各部门间相对独立，缺少联系，因而不可避免地形成了众多垂直封闭的信息系统，大大减缓了卫生行业的信息共享进程。
三、我国区域卫生信息化发展面临的问题与挑战
卫生信息化建设滞后的原因，除了上述客观原因外，其根本还在于建设理念与模式上的偏差。以IT技术和专业领域需求为驱动的建设理念，在一定程度上促进了信息化发展，但同时也成为其前进方向上的阻碍。目前，我国区域卫生信息化主要存在下面一些问题：
1．系统分割、相互独立。各个卫生机构相对独立开展业务，相互封闭，信息分散，连续性和协调性差，信息不能共享和交换。
2．业务流程不统一、不规范。很多业务工作没有国家统一规范和要求，各地区和单位根据自身需要，自行制定工作规范和标准，导致信息不能交换和共享。由于业务流程不规范，很多单位的信息化就是现有管理模式的计算机化，不能充分发挥信息系统应有的优势。
3．需求分析缺少理论方法，仅以项目和IT为驱动。卫生信息化项目建设作为业务应用发展的组成部分而提出，缺乏整体规划。现在很多信息系统均是按照此种方式建设。
4．纵向信息系统的建设导致众多的“烟囱”、“孤岛”。在信息化建设的第二阶段，疫情网络报告系统、应急指挥系统、妇幼保健系统、医院信息系统的建设大大提高了相关部门的管理能力和应急反应速度，但是由于信息系统垂直建设的特点，原本分割的业务部门在信息上沟通更为复杂，形成大量“信息烟囱”和“信息孤岛”。
5．理论研究薄弱，信息标准研究起步较晚。卫生信息系统的发展速度远远快于标准的建立，造成了众多信息系统分别制定各自标准，却没有国家权威统一卫生信息标准的局面。
6．投入不足、技术人才短缺。资金、技术和专业人才匮乏是多年来一直困扰卫生信息化发展的难题之一。在区域卫生信息体系建设中，这一问题显得尤为突出：一方面区域卫生信息体系建设是复杂的、需要长期建设的系统工程，需要投入大量资金予以支持，而政府在这方面的持续性投入往往不足；另一方面，区域卫生信息体系建设涉及到卫生管理、医疗、预防保健、卫生经济以及信息技术等多专业学科，专业人才的缺乏也直接制约了系统的建设和发展
综上所述，卫生信息化建设在经过十多年的发展，取得众多成绩的同时，也存在诸多问题。这些问题的解决，需要统一标准，统一规划，建立起机构之间的共享机制，体现以人为本的基于健康档案为核心的区域卫生信息平台的需求日益迫切。第二节 区域卫生信息平台用户分析
目前，我国居民的健康相关信息分散在各个卫生服务机构，没有形成统一的居民健康档案。从用户的角度分析，基于健康档案的区域卫生信息平台包括以下几类用户。
居民个人；
医疗卫生服务提供机构：如医院、社区卫生服务中心、妇幼保健院、专科医院等；
公共卫生专业机构：如疾病预防控制中心、卫生监督所等；
卫生行政部门：如卫生局、卫生厅、卫生部等；
相关部门：如保险、药监、计生、公安、民政等相关部门。
不同用户对基于健康档案的区域卫生信息平台需求有不同的关注点，具体如下：
居民个人：主要关注的是如何能获得可及的、优质的卫生服务；获取连续的健康信息、全程的健康管理等方面。
卫生服务提供机构：主要关注的是如何保证服务质量、提高服务效率；如何有利于针对性的服务的开展、健康管理的系统化等方面。
公共卫生专业机构：主要关注的是如何加强疾病管理、卫生管理、应急管理、健康教育等方面。
卫生行政部门：主要关注的是如何提高卫生服务质量、强化绩效考核、提高监督管理能力、化解疾病风险等方面。
相关部门用户：主要关注的是风险管理、业务协同等方面。
一、居民个人
随着经济的发展，城乡居民迫切需要享受更高品质的医疗卫生服务，及时获取有效的医药保健信息，提高生活质量。这种需求主要体现在以下几个方面：
可及的卫生服务：通过提高医疗机构的医疗服务质量和服务效率，降低医疗成本，有效缓解“看病贵”的状况。通过区域卫生信息平台，医院开展专家门诊预约、远程咨询会诊、转诊、转检、慢性病跟踪监控等服务，使居民就医更方便。建立区域性健康档案，实现健康信息共享，改变城乡居民的就医观念，逐步实现“小病在社区，大病在医院”，有效缓解“看病难”的状况。
优质的卫生服务：居民在进行诊疗时，可以让就诊医生查阅自己的健康档案及诊疗信息，从而使就诊医生更好的为自己服务，并可以通过治疗安全警示、药物过敏警示等有效减少医疗事故，并可对不必要的检验/检查进行提示，逐步缓解“看病贵”的问题。
连续的健康信息：按照标准，收集整理各卫生机构的健康信息，建立居民贯穿整个生命周期健康档案，群众可以查询自己的健康资料，或使用全区域统一的标识在各医疗机构中进行就诊，享受便捷的、全方位的疾病诊治、医疗咨询、健康教育、医疗保健等健康服务。从而进行自我医疗管理、制定自我疾病防范及维护自己的健康档案信息。
全程的健康管理：各医疗机构可运用卫生信息平台为居民提供主动的、人性化的健康服务，一方面为城乡居民提供方便、快捷、全面、科学的健康服务和保障。另一方面将有助于增强居民的健康保健意识，极大地提高居民的健康水平与生活质量。
二、医疗卫生服务机构
（一）医院
为了提高医疗质量和提供更合适的治疗方案，希望获得更多的病人健康信息，包括：
医生可以调阅到当前患者的历次诊疗信息，及当前患者相关家属的健康信息，能够查询个人健康档案与患者在其他医院的就诊资料。
医生在为患者诊治时可以获得治疗安全警示、药物过敏警示、重复检验/检查提示，有效减少医疗事故发生、降低重复检查费用。
在进行远程会诊时，所有专家都可以调阅到当前患者的检查报告、医学影像。全市范围内病人检验单，检查报告的共享和互认。
此外，医院希望减少信息重复录入的工作量，可从电子病历中自动获取并提交疾病控制、妇幼保健、精神卫生等公共卫生业务单位或部门需要的数据和信息。
（二）社区卫生服务中心
为提供更优质预防、保健、健康教育、计划生育、医疗、康复的社区卫生服务，社区全科医生在进行社区卫生服务时可以调阅到管辖居民的所有诊疗信息（急诊、门诊、住院、健康等信息）及健康档案信息。全科医生作为社区居民的“家庭医生”，在远程医疗和会诊时可以调阅居民的所有诊疗信息及健康档案信息。可以通过查询、分析特定时间与特定范围内人群的健康或疾病状况，诊断确定社区的主要卫生问题、优先考虑的问题、危险因素，为制定社区卫生规划、合理分配利用有限资源、最大限度地促进人群健康、实施有效管理、进行科学评价提供依据。
社区医生可以将公共卫生各业务条线（疾病控制、卫生监督、妇幼保健、精神卫生）需要的数据通过平台上传到公共卫生系统中，并且获得公共卫生下发的数据，完成相应社区服务，避免数据重复录入。
（三）妇幼保健院
妇幼保健各业务数据离散度较大，分布在医院、社区、围产保健机构，难以形成个案全面的数据管理，围产保健个案跟踪数据缺乏，保健与临床信息无法统一。妇幼保健院希望得到更丰富的信息，提供更优质、更全面的妇幼保健服务。妇幼各业务工作量大，需建立与其他机构和卫生行政部门的横向网络体系，完成妇幼保健信息与其他信息系统数据的共享与交换实现妇幼保健业务与医疗业务，做到数据一处录入，多处利用，实现妇幼保健行政管理业务的全面整合。如下图所示：
图2-1 跨部门、跨系统的妇幼保健服务关系图（略）
三、公共卫生专业机构
（一）疾病控制中心
疾病预防控制中心希望实时从各医院、社区卫生服务中心（站）获取疾病个案信息，智能分析出区域群体疫情信息，与医疗机构联网完善传染病的上报流程和模式，提高上报效率和质量，实现传染病、慢病、精神病等疾病的实时监控和预警报告。
方便、实时的疾病预防控制信息和方案发布服务，让整个区域所有卫生机构紧密结合在一起，将该体系纳入全区域应急联动体系和卫生信息网络体系，实现业务联动，共同构筑区域人民疾病预防的健康大堤。
（二）卫生监督机构
希望建立起管理对象档案，通过管理对象档案实现不同机构，不同业务业间的信息共享，通过管理对象档案和居民健康档案和关联，实现将个人的健康管理和人群管理统一起来。通过信息共享，加强执法力度，杜绝人工管理的弊端，实现卫生监督的实时、动态的高效管理，覆盖到全市各卫生监督所，医院，娱乐场所，食品加工，餐饮，公共卫生，学校等，形成集卫生监督信息收集、加工、存储、检索、分析、研究、传输为一体的综合信息网络体系。
加强卫生监督信息系统的基础建设，建立卫生监督信息系统功能规范和信息标准体系。卫生监督机构建立网络化信息应用系统，实现网上受理审批，监督信息公布查询等信息化应用目标。
（三）急救中心和突发公共卫生事件处置机构
基于区域卫生信息平台和区域卫生数据中心，建立区域急救中心和突发公共卫生事件应急指挥机制和规范。
急救中心希望及时、准确进行社会急救医疗信息资料、声像、业务档案的收集、分类等级和归档，完成各类院前急救医疗数据、报表的统计工作，实现急救业务的日常受理，派车，医疗救助及应急事件急救的指挥和调度，及相应的信息统计。
通过建立120急救管理系统，使急救用户发出的呼叫信息以及系统产生的信息包括急救中心受理情况和医院出车情况、中心值班人员情况等本信息能够定期上报至区域卫生信息平台。
通过区域卫生信息平台，建立疾病电子监测机制，收集媒体网络信息和交通通报等信息，进行突发公共卫生事件监测和突发公共卫生事件相关预警处理。
在疫情和突发公共卫生事件等重大危害时期，需进行医疗资源统一调度、院前急救、医疗救治、过程跟踪与反馈等医疗救治信息服务和管理职能。
（四）健康教育中心
希望获得更全面、更准确的疾病分布情况和居民对健康教育的需求信息，有针对地进行健康教育计划，发布健康教育知识，举办健康教育活动，评价健康教育效果，进行健康知识测试等一系统健康教育活动，提升全区域的健康水平。
四、卫生行政部门
区域卫生信息系统建成后，可以为政府提供应急指挥的信息支撑系统，提高决策水平和效率，为民办实事。
建立了一个涵盖区域全民诊疗信息、预防保健信息、公共卫生信息等全面的卫生数据中心。利用平台采集到的海量数据，就可以实现对业务、管理有效的数据支持。同时由于对区域的在运行系统的数据有了跟踪能力，及时关注，避免管理上的被动。
政府可以利用突发公共卫生事件应急指挥和处理平台，结合社会各方的资源，加强对突发公共卫生事件的监测和预警；当有突发公共卫生事件发生时，可以按照应急预案及其启动程序要求，应对各种突发公共卫生事件，保证突发公共卫生事件应急处理工作能有力、有效、有序地进行，维护正常的社会秩序和生活秩序。政府通过网络可以随时查阅区内医疗卫生行业各种最新的统计数据，加强宏观管理，优化卫生资源的配置。建设区卫生信息网是一项利国利民的大事。
为城乡居民提供更加便捷的健康服务。保障区内各类人才的健康需求，增强区域竞争能力。
可以通过网络全面掌握全区医疗卫生服务体系、救助体系、保障体系等方面的详细资讯，为制定区内公共卫生政策提供准确依据。
利用数据中心和卫生信息平台对区域内各种医疗卫生数据进行采集，归并与挖掘分析，提供业务监督与决策支持。
五、其他卫生相关单位与部门
医保、药监、计生、公安、民政等相关部门希望各相关部门加强沟通，密切配合，提高业务能力，增强服务功能。通过区域卫生信息平台，实现卫生机构和相关机构信息互联互通。如：
药监部门可以通过区域卫生信息平台，获得丰富的药品使用有关数据，可以进行实时在线的不良药物事件的监测，提供用药分析服务等等。
社会保险部门通过区域卫生信息平台，区域掌握了大量健康数据，对这些数据进行统计分析，了解医疗整体面貌，进一步辅助和推动医保/新农合业务的开展，并完成审核监督、定点医疗机构布点、医保政策制定或更新等辅助管理。
区域卫生信息平台从民政系统获取女性人群的婚姻信息，并将划定年龄段的已婚女性作为孕产妇保健预备管理对象。从民政系统获取残疾人群信息，在健康档案的建设中，为该类人群建立残障专项档案、提供残疾康复管理。
区域卫生信息平台从公安系统获取出生人口信息、户口迁入人口信息，触发新增人群（出生、户口迁入）的健康档案建档工作。可从公安系统获取户口迁出的人口信息，触发户口迁出人群所对应的健康档案的封存和转档。
区域卫生信息平台从计生委系统中获取育龄妇女信息，在健康档案的建设中，将育龄妇女作为孕产妇保健预备管理对象。计生局可以从健康档案中获取孕产妇保健专项档案信息。
商业保险公司可以借助该信息网络平台获得更全面、更准确的健康档案，为居民提供更加丰富更加便捷的健康服务。第三节 区域卫生信息平台业务需求分析
居民健康档案被定义为贯穿一生的临床数据纵向记录。虽然医疗保健行业一般认为，临床数据的价值会随着时间流逝而逐渐减少，但居民健康档案的一个重要价值因素，在于提供权威数据（被识别的或未被识别的）的二次使用，如监控、研究、本地或区域的疾病预防策划，生物医学设备召回和维护，或者公众健康委托计划的执行等。
一、医疗卫生服务的需求
在医疗保健业务工作中，我们不仅需要获取跨越不同系统的健康信息，还需要获取跨越不同区域卫生管理机构与边界的健康信息。在更大的医疗服务机构范围内实现或追踪诊疗预约与转诊。
电子健康档案包括居民从生到死，各个生命时期所有的关于医疗健康保健的信息和资料，包括居民的基本信息，出生证明，个人健康档案，家庭健康档案，每次就诊的病历，报告，处方，体检结果等等。电子健康档案的共享就是各医疗卫生机构（医院，社区中心等）将各自对居民医疗卫生服务的业务数据采用统一的标准汇总到数据中心形成每个居民完整的健康档案信息，同时各医疗卫生机构又能够方便地共享查询这些资料为居民提供医疗卫生服务。
（一）提高医疗服务质量的需要
健康档案应具有高亮显示潜在病患居民，将及时提醒随访医生及时关注其的健康状况，极大的提高了居民健康状况的依赖心理，能较大程度的提高医疗服务质量。
（二）节省患者支出，缓解群众看病贵问题的需要
促进基本公共卫生服务逐步均等化，通过基于网络的信息技术，为每个人建立一个健康档案，实际上就能够实现个体化程度上的健康管理，居民个人的健康的资料，像儿童出生的情况、疫苗接种、中老年人慢性病的情况、大医院的就诊记录，以及诊断治疗的重要的记录，如CT、核磁、X线的检查、影像学的资料都可以建立在这个档案当中。这样无论是在基层就医或者到大医院就医，医生马上就可以知道患者病史，避免了很多重复的医学检查，既提高了效率，也节省了患者支出。
（三）争抢生命绿色通道“黄金时间”的需要
院前急救是急救医疗服务系统的3大组成部分之一，是抢救病人的前沿，院前急救工作直接关系到病人的生死存亡，具有很强的医疗性和社会性。急症患者很多因为错过了急诊抢救的黄金6小时，而面临愈后效果差，甚至失去生命的结果。
通过居民健康档案可以在第一时间了解决患者的病史、药物过敏史等情况，并有针对性地进行医疗诊治准备，避免无法询问病情因病史不明确导致救治不力的情况，真正的把握急诊抢救的黄金6小时。
（四）有效、合理利用医疗资源的需要
在不同机构之间开展的有效、持续的患者服务与医疗管理，加强农村卫生服务体系和城市社区卫生服务体系建设两项基础工作，通过建立居民健康档案，促进城乡医疗卫生事业协调发展，真正解决城乡居民“看病难看病贵”问题。促进大中型医院与城市社区卫生服务机构之间形成业务联动、优势互补、疾病诊治连续化管理的机制，最终实现小病在社区，大病进医院，康复回社区的就医格局。
实行社区卫生服务机构与大中型医院多种形式的联合与合作，建立分级医疗和双向转诊制度，探索开展社区首诊制试点，由社区卫生服务机构逐步承担大中型医院的一般门诊、康复和护理等服务。实现双向转诊的重要一点就是信息共享与沟通，这有赖于信息化建设。没有电子病历、健康档案等基础信息，信息化支撑转诊可谓无源之水，只有有了基础信息，才能够说得上转诊时各类医疗机构之间共享信息，才能谈以此实现提高质量降低费用的目的，实现区域医疗资源的合理利用。
（五）用例分析
用例一：医院与社区双向转诊
医院与社区双向转诊业务的主要参与者及其需开展的业务如下：
社区医生：办理转院申请，接收康复病人，健康跟踪随访。
综合医院医生：接收转入病人，查阅检验结果以及张三既往病史，对张三进行治疗，病情稳定后，办理转社区进行康复申请。
下表是对场景描述，通过对现在使用的流程、使用区域卫生信息平台后的流程进行对比，对有平台后的益处进行分析。
表2-1 医院与社区双向转诊情景描述
场景：李四经常性头晕，病情越来越严重，社区医生怀疑其得了脑部肿瘤。建议到综合医院确诊并治疗。
无区域卫生信息平台
社区医生建议李四到综合医院确诊并治疗。
综合医院医生为李四重新全面检查。经过多番检查、治疗、观察，最后确诊为脑部肿瘤，并做手术治疗。
手术进展较顺利，病情开始基本稳定。由于综合医院病床紧张，建议办理出院。
使用区域卫生信息平台
社区医生帮李四办理转诊申请。
综合医院医生接收张三转入。
通过区域卫生信息平台，直接获得检查结果
综合医院医生查阅检验结果以及张三既往病史发现数年前的情况对当前病情可能产生影响。
综合医院医生就此和张三回顾情况，以确认一些细节。
根据这些临床证据和问诊情况，综合医院医生做出诊断，决定手术治疗。
手术进展较顺利，病情开始基本稳定。由于综合医院病床紧张，转诊到社区医院康复治疗。
基本治愈后，出院，社区医生定期跟踪随访。
益处
节省重复的检查。
提供完善的资料使得医生能够做出明确的大部分诊断。
医疗卫生人员不再仅仅依靠患者的无重点的回忆和一些补充信息，而是可以直接获取精确和完善的历史信息。
提供完整的信息提高了快速准确诊断的可能性。
提高综合医院资源利用率。
病人得到更全面的健康服务，康复治疗、健康跟踪随访。
用例二：实验室检验结果共享
实验室检验结果共享业务的主要参与者及其需开展的业务如下：
原接诊医生：办理转院申请。
专科医生：接收转入病人，查阅检验结果以及病人既往病史，对病人进行治疗。
下表是对场景描述，通过对现在使用的流程、使用区域卫生信息平台后的流程进行对比，对有平台后的益处进行分析。
表2-2 实验室检验结果共享情景描述
场景：张三腹部疼痛已经持续几周了，身体状况日益衰弱。由于诊断不明，他的医生建议他进行一系列的化验检查并让他去专科医生那里就诊。
无区域卫生信息平台
检验结果通过传真或者快递送到专科医生处。
专科医生查看检验报告。
专科医生与张三会面，询问张三既往病史，从而判断是否有其他因素引起疾病。
由于未能精确地查明原因，专科医生建议做进一步检查以查明病因。
使用区域卫生信息平台
张三的原接诊医生，办理转院申请。
专科医生接收张三转入。
通过区域卫生信息平台，直接获得检查结果
专科医生查阅检验结果以及张三既往病史发现数年前的情况对当前病情可能产生影响。
专科医生就此和张三回顾情况，以确认一些细节。
根据这些临床证据和问诊情况，专科医生做出诊断，并开出治疗处方。
益处
节省递送检查结果所需的时间和金钱。
提供完善的资料使得医生能够做出明确的大部分诊断。
医疗卫生人员不再仅仅依靠患者的无重点的回忆和一些补充信息，而是可以直接获取精确和完善的历史信息。
提供完整的信息提高了快速准确诊断的可能性。
二、社区卫生服务的需求
社区卫生服务是我国城镇医药体制改革的重要内容和主要环节，并成为我国新型城市卫生服务体系的重要组成部分，作为整个卫生体系的“网底”，开展“六位一体”的业务，建立个人健康档案，分析个体健康状况和健康风险因素，针对个体差异采取干预措施，制定保健计划，降低患病风险，改进健康行为，提供细致周到的健康服务，是社区卫生的主要服务内容。
（一）开展“六位一体”业务的需要
社区卫生机构以全科医师为骨干，健康为中心、社区为范围、家庭为单位、需求为导向，妇女、儿童、老年人、慢性病人、残疾人等为重点，融预防、保健、医疗、健康教育、计划生育技术指导和常见病、多发病、诊断明确的慢性病的治疗和康复服务为一体即"六位一体"的社区卫生服务。
每个居民都需要建立自己的健康档案册，每个家庭有保健册，0-7岁儿童和60岁以上老人及8种重点管理的慢性非传染性疾病，把老年人、妇女、儿童和残疾人作为重点服务的人群，把慢性非传染性疾病及妇幼保健作为重要服务内容通过健康档案实现6位一体的动态监测和管理。
（二）开展健康干预跟踪服务的需要
通过区域卫生信息平台实现区域内健康档案信息共享、联动医疗机构间的双向转诊、委托/受托检验和医学影像检查、图像和报告传递，实现个人医疗卫生保健服务的跟踪。
健康干预服务质量是衡量一个区域居民健康水平的重要标志。探索区域内居民在不同医疗机构间从孕产期保健到婴儿出生、儿童保健、终老的健康跟踪服务，利用手机短信预约服务等提供便捷和人性化的服务，可以有效提升健康干预服务质量。
建立具有统一功能体系、统一指标体系和统一操作模式的社区卫生管理信息系统，提高社区卫生管理和业务指导机构的管理效率和质量，向社区居民提供更满意的卫生健康服务。
（三）全科医生扩大和加深临床经验的需要
居民健康档案是记录居民健康状况的系统化文件或资料库，包括个人病患记录、健康检查记录、各年龄阶段的保健记录及个人和家庭一般情况记录等。一个好的健康档案是良好病人照顾的基础，也是医生扩大和加深临床经验乃至科研的工具，这已经为广大医务界人士所认同。
建立和完善全科医疗的健康档案具有十分重要的意义和必要性：
第一、系统完整的健康档案可为全科医生提供病人全面的基础资料，是全科医生全面了解病人个体及其家庭问题、作出正确临床决策的重要基础。
第二、传统的病历记录均是以各器官系统为单元、以疾病为中心的记录，而全科医疗服务是连续性的，是以现代的生物-心理-社会医学模式进行临床思维，以健康问题为中心收集资料并进行诊疗的，因此其健康档案记录的形式和内容与以往病历有所不同。
第三、传统的门诊病历杂乱无章，而全科医疗病历记录是连续而规范的。
第四、完整、系统的健康档案记录是医生本身继续教育的一个重要资料。
第五、全科医疗健康档案记录的内容和形式可克服以往门诊病历过于简单、不规范、医疗及法律效力差等缺点，成为基层全科医疗服务领域内重要的医疗法律文书。
第六、健康档案记录为预防医学的实施提供资料。
第七、健康档案是评价全科医生服务质量和医疗技术水平的工具之一。
第八、通过建立个人、家庭和社区健康档案，能够详细了解和掌握社区居民的健康状况、社区家庭问题和卫生资源。
下面从产后访视、高血压管理两个用例来分析区域卫生平台建立后的工作模式的改变和效果。
（四）用例分析
用例一：产后访视
产后访视业务的主要参与者及其需开展的业务如下：
分娩医院医生：记录分娩信息；
辖区医院医生；进行产后28天内访视；
辖区社区医生；进行产后42天内访视；辖区社区进行计划生育措施指导，进行科学育儿知识教育，做儿童计划免疫接种计划，做儿童保健健康计划。
下表是对场景描述，通过对现在使用的流程、使用区域卫生信息平台后的流程进行对比，对有平台后的益处进行分析。
表2-3 产后访视情景描述
场景：一个婴儿在一家医院出生了，产妇出院后，分娩医院进行产后访视。
无区域卫生信息平台
分娩医院进行产后访视。
婴儿管辖社区定期从社区或街道了解婴儿出生情况，并到婴儿家庭做随访，将婴儿信息录入计划免疫系统。
使用区域卫生信息平台
平分娩医院进行产后28天内访视。
平台将该产妇分娩信息和和产后28天内访视信息主动推送到辖区社区，社区提醒并开展42天产后访视。
辖区社区进行计划生育措施指导，进行科学育儿知识教育，做儿童计划免疫接种计划，做儿童保健健康计划。
益处
辖区医院和辖区社区工作变被动为主动。
减少产后访视遗漏，减少计划免疫遗漏。
为辖区医院和辖区社区提供更完整的信息，提高了快速准确诊断、合适保健的可能性。
用例二：高血压病管理
高血压管理业务的参与者及其需开展的业务如下：
高血压病例发现医院医生：确诊病人是否为高血压患者，病情稳定后将病人转诊到辖区社区。
辖区社区医院医生：接收转入的高血压患者，康复治疗，为病人建立高血压专档案，并进行长期随访跟踪。
辖区疾病控制中心：辖区疾病控制中心了解全区域的高血压疾病情况。
下表是对场景描述，通过对现在使用的流程、使用区域卫生信息平台后的流程进行对比，对有平台后的益处进行分析。
表2-4 社区高血压病管理情景描述
场景：一个病人送往医院，发现是高血压患者。基本治愈后转诊到社区医院康复，并进行长期随访跟踪。
无区域卫生信息平台
医院医生发现病人是高血压，进行治疗。
基本治愈，或是病情稳定后，进行转诊到社区。
社区接诊，并手工录入信息建立高血压病人专档。
社区进行康复治疗。
康复后，社区对该病人进行长期专病随访跟踪。
使用区域卫生信息平台
医院医生发现病人是高血压，通过平台查询该病人的健康档案，了解该病人高血压是否是长期的，还是其它因素引起的，找出合适的诊疗方案，确诊是否为高血压患者。
基本治愈，或是病情稳定后，通过区域卫生平台进行转诊到社区，并将本次就诊记录自动归入该病人区域健康档案中。
通过区域卫生平台进行接诊。
平台自动提醒社区建立高血压病人专档，建档案可从医院就诊信息默认到档案。
社区进行康复治疗。康复后，平台自动提醒社区对该病人进行长期专病随访跟踪。
辖区疾病控制中心了解全区域的高血压疾病情况。
益处
为医生提供更多信息，让医生更准确地作出合适的诊疗方案。
辖区社区建档案更方便。
自动提醒，使辖区社区可减少高血压病人访视遗漏。

三、公共卫生服务
公共卫生体系由国家公共卫生机构、地方公共卫生机构和基层公共卫生组织组成，包括疾病预防控制（卫生防疫）机构、120急救中心、妇幼保健机构、传染病及精神病防治机构等机构与组织，肩负起医疗救治、疾病预防、健康促进、环境卫生、传染病防治、个人卫生教育、早期诊治疾病等公共卫生职责。
处理公共卫生事务在各机构产生了大量的数据信息，但往往应用于机构内病历记录的信息采集、保存和传输，无法实现共享与利用。在此背景下，人们表现出强烈的信息共享需求，因为他们都是典型的需要在许多医疗服务提供者之间进行大量信息的管理和交换的复杂案例，这种共享不仅仅是在某个区域卫生管理内的组织机构之间，还经常发生在位于不同的地区和省的健康组织机构之间。
（一）公共卫生业务联动工作的需要
居民健康档案建立后，在120急救中心的信息平台上储存有用户的信息资料，系统会在15秒内自动弹开该用户的相关信息（前期建立档案时，记录的既往病史，体检时的有关记录、家庭住址、亲属联系方式等），急救中心的工作人员会根据GPS定位（若没有GPS定位，可根据前期登记的家庭住址）通知与呼救用户现场最近的急救车辆前往抢救。同时开通医院生命绿色通道，用户发出的呼救信息不仅反应在120系统平台，同时也会反应到绿色通道对口医院的平台上，根据患者既往病史，使医院提前做好抢救准备。促使用户的呼救信息能够反应到呼救中心、绿色通道的对口医院。
（二）疾病预防与控制管理需要
健康档案是指一个人从出生到终老的整个生命过程中，其健康状况的发展变化情况以及所接受的各项卫生服务记录的总和，疾病预防保健专业机构以居民健康档案采集的信息为依据，开展质量控制和管理，能够更好地了解和掌握辖区内居民的基本健康状况及其变化和趋势，有效开展医疗、预防、保健、康复、健康教育和计划生育技术指导等服务，开展重点人群、重点疾病的防治管理工作。
（三）突发公共卫生事件处理的需要
突发公共卫生事件是指突然发生，造成或者可能造成社会公众健康严重损害的重大传染病疫情、群体性不明原因疾病、重大食物和职业中毒以及其他严重影响公众健康的事件。在我国已建立起了“院前急救?D?D医院急诊?D?D?D重症监护”三位一体的EMSS急诊服务体系，由四个环节紧密结合处理如下图所示：
图2-2 EMSS急诊服务体系关系模式图（略）
四个环节分别由不同的机构不同工作人员协同完成，“救人”是整个环节最大的目标，环节之间沟通最多的就是病情及病史，因而健康档案实质上成了整个环节的第一道也是唯一的“令牌”。
具体来说：患者的临床表现往往为急诊患者，最突出的表现是急性症状。因病情多变、复杂，往往一时很难明确临床诊断，病情危急，重点是立即抢救生命、稳定病情，“治病”意味先要明确疾病诊断，再行相应治疗措施，因而通过居民健康档案适时的查阅，提高抢救病人的“黄金时间”，为预防暴发大规模的疾病提供理论依据与信息支持。
（四）公共卫生服务需要
在全国建立格式、内容相对统一的信息化居民健康档案，将能够确保居民的健康信息跟人流动，在异地工作居住时，依然能够享受到由政府提供的基本公共卫生服务。国家的基本公共卫生服务项目将包括疾病预防、免疫接种、妇幼保健、健康教育、职业卫生、精神疾病管理治疗等内容，由城市的社区卫生服务中心 （站）、乡镇卫生院和村级卫生室（所）向辖区内所有居民均等提供。国家还将加强对边远、贫困和流动人口等特殊人群的卫生经费投入和服务，逐步缩小城乡居民基本公共卫生服务差距。
下面从出生医学证明签发和传染病报告两个例子来分析公共卫生服务对居民健康档案提出的需求。
（五）用例分析
用例一：出生医学证明签发
出生医学证明签发后业务的主要参与者及其需开展的业务如下：
医院医生：医学出生证签发。
社区医生：进行产后随访，新生儿随访，为婴儿建立健康档案和做计划免疫计划并做跟踪。
下表是对场景描述，通过对现在使用的流程、使用区域卫生信息平台后的流程进行对比，对有平台后的益处进行分析。
表2-5 出生医学证明签发及后续服务触发情景描述
场景：一个婴儿在一家人民医院出生了，医院需签发医学出生证明，婴儿所管辖社区需为婴儿做计划免疫计划并做跟踪。
无区域卫生信息平台
人民医院管理部门需录入婴儿出生信息到医学出生证签发系统，并打印出医学出生证。
婴儿管辖社区定期从社区或街道了解决婴儿出生情况，并到婴儿家庭随访，将婴儿信息录入计划免疫系统。
婴儿所管辖社区为婴儿做计划免疫计划并做跟踪。
使用区域卫生信息平台
通过区域卫生信息台，从孕产妇档案、分娩记录获取婴儿出生信息，共享到医学出生证签发系统，并打印出医学出生证。
区域卫生信息台主动提醒社区，期管辖区域内有一婴儿出生了，社区医生根据产妇健康档案主动做随访。并为婴儿建立健康档案。
社区为婴儿做计划免疫计划并做跟踪。
益处
减少重复信息录入，提高数据质量。
辖区社区工作被提醒需做随访和计划免疫，而不是定时做调查。节省社区的工作量。
减少产后访视、计划免疫遗漏，提高区域产后访视率和计划免疫覆盖率。
用例二：结核病防治
结核病防治业务的参与者及其需开展的业务如下：
结核病防治病例发现医院医生：确诊病人是否为结核病患者，同时上报上级CDC和辖区慢病站（或结核病防治所），病情稳定后将病人转诊到辖区社区。
辖区社区医院医生：接收转入的结核病患者，康复治疗，为病人建立结核病防治专档案，并进行长期随访跟踪。
辖区慢病站（或结核病防治所）：根据结核病病人的病情，给出专业的治疗计划和跟踪治疗计划。
辖区疾病控制中心：辖区疾病控制中心了解全区域的结核病疾病情况。
下表是对场景描述，通过对现在使用的流程、使用区域卫生信息平台后的流程进行对比，对有平台后的益处进行分析。
表2-6 结核病防治情景描述
场景：王五在医院确诊为结核病。将病例上报CDC和辖区慢病站（或结核病防治所）。基本治愈后转诊到社区医院康复，并进行长期随访跟踪。
无区域卫生信息平台
医院医生发现病人是结核病，通过直报系统上报CDC。手工将病例报辖区慢病站（或结核病防治所）。
辖区慢病站（或结核病防治所）：根据结核病病人的病情，给出纸质的治疗计划和跟踪治疗计划，人工送住医院。
基本治愈，或是病情稳定后，进行转诊到辖区社区。
社区接诊，并手工录入信息建立结核病病人专档。
社区进行康复治疗。
康复后，社区对该病人进行长期专病随访跟踪。
使用区域卫生信息平台
医院医生发现病人是结核病，通过区域平台，将病例病信息主动推送到CDC和辖区慢病站（或结核病防治所）。
辖区慢病站（或结核病防治所）根据结核病病人的病情，制定治疗计划和跟踪治疗计划，通区平台发送到医院。
医院根据治疗计划进行诊疗，慢病站（或结核病防治所）通过平台获取实时信息，进行过程监督，提出治疗意见。
基本治愈，或是病情稳定后，通过区域卫生平台转诊到社区，并将本次就诊记录自动归入该病人区域健康档案中。
社区通过区域卫生平台进行接诊。
平台自动提醒社区建立结核病病人专档，建档案可从医院就诊信息默认到档案。
社区进行康复治疗。康复后，平台自动提醒社区对该病人进行长期专病随访跟踪。
辖区疾病控制中心了解全区域的结核病疾病情况。
益处
节省递送病例、治疗计划和跟踪治疗计划所需的时间和金钱。
慢病站（或结核病防治所）可对病人病情变化进行实时过程监督，随时提出治疗意见，提高诊断效率。
辖区社区建档案更方便。
自动提醒，使辖区社区可减少结核病病人访视遗漏。

四、综合卫生管理的需求
综合卫生管理部门可以利用突发公共卫生事件应急指挥和处理平台，结合社会各方面的资源，加强对突发公共卫生事件的监测和预警；当有突发公共卫生事件发生时，可以按照应急预案及其启动程序要求，应对各种突发公共卫生事件，保证突发公共卫生事件应急处理工作能有力、有效、有序地进行，维护正常的社会秩序和生活秩序。
（一）进一步深化医疗体制改革的需要
目前利用信息化建设进行卫生体制的改革取得了显著的成绩，为了满足更深入的卫生体制改革，需要进一步加强信息化建设广度和深度，实现数据更广泛的共享与交换，充分利用数据实现医疗卫生管理与服务的需求，同时加强系统的运营维护管理，才能推动进一步的医疗卫生服务体制的深化改革。
（二）合理配置医疗卫生资源需求
区域卫生信息平台建成后，卫生行政部门可以获得宏观管理所需的数据支持，以辅助其决策，高效开展电子政务、疫情监测、应急联动等；通过互联互通的医疗卫生网络体系将使行政管理部门对卫生业务部门的监督和控制更加的及时和准确，提高对整体卫生资源的调配力度，加强对疾病与疫情的控制，加强卫生监督，提高行业内的应急指挥处理能力。卫生信息的发布与公示将加强了对医疗机构的管理和约束，增强政策的透明度。丰富的医疗卫生信息资源，为政府进行全市的宏观管理，宏观调控和决策支持提供基础数据。
加强宏观管理，优化卫生资源的配置。为城乡居民提供更加便捷的健康服务。保障区内各类人才的健康需求，增强区域竞争能力。可以通过网络全面掌握医疗卫生服务体系、救助体系、保障体系等方面的详细资讯，为制定公共卫生政策提供准确依据。
（三）资源整合，减少重复投资需求
近年来卫生信息化建设的发展速度较快，但不可忽视的是，不管是硬件建设，还是应用系统的开发，以及数据的采集与信息利用，大多数都是出于一种低水平重复的无序状态。每个单位都建设小而全的网络信息系统，采用不统一的系统软件，使用不规范的应用系统，配备不少的专业计算技术人员，投入不菲的建设与维护资金，结果是财力、物力与人力投入很大，带来的却不是令人满意的效益。各部门、各系统的数据无法交换共享，遇到如SARS等突发事件时，连最基本的统计数据都无法自动获取，还要通过手工方式收集、上报、统计，难以发挥卫生信息系统的作用。
（四）实现跨业务跨系统的数据共享利用的需求
由于卫生信息化建设各自为政，缺乏统一规范和部署，各医疗卫生机构之间的网络物理上不联通，业务标准、数据标准不一致，数据无法交换共享，形成了各单位、各条线的信息孤岛。首先，各单位对基础与公共信息都要重复采集与存储，由此造成人力、物力与财力的重复投资；其次，由于数据的重复采集与存储，导致数据冗余，影响数据的一致性与唯一性；最后，虽然数据被多处采集与存储，但由于标准不一致，数据还是无法交换、共享。
下面从突发公共卫生事件应急指挥、卫生服务绩效评价两个用例来分析区域卫生平台建立后的工作模式的改变和效果。
（五）用例分析
用例一：突发公共卫生事件应急指挥
概括性地描述开展此业务需要哪些信息，这些信息从哪些机构来。分别描述业务工作现在的工作流程和有了平台之后的工作流程，以表表示，进行比较。
突发公共卫生事件应急指挥业务的主要参与者及其需开展的业务如下：
应急指挥人员：人力组织、物资调拨等。
事件控制和救治现场人员：现场流行病学调查、传染源隔离、医疗救护、现场处置、监督检查、监测检验、卫生防护、现场抢救、现场隔离与控制、转运救治、物资调拨、病因调查、保护易感人群、宣传教育等工作。
下表是对场景描述，通过对现在使用的流程、使用区域卫生信息平台后的流程进行对比，对有平台后的益处进行分析。
表2-7 突发公共卫生事件应急指挥情景描述
场景：突发公共卫生事件，各部门都行动起来了。事件控制和救治工作涉及应急队伍组织、现场流行病学调查、传染源隔离、医疗救护、现场处置、监督检查、监测检验、卫生防护、现场抢救、现场隔离与控制、转运救治、物资调拨、病因调查、保护易感人群、宣传教育等综合处理工作，众多部门在统一指挥下，协同采取应对措施。
无区域卫生信息平台
区域应公共卫生急物资和人力资源了解不够，对事件危险、自身应急能力不能做出准确的评估，指挥决策困难。
应急队伍组织、现场流行病学调查、传染源隔离、医疗救护、现场处置、监督检查、监测检验、卫生防护、现场抢救、现场隔离与控制、转运救治、物资调拨、病因调查、保护易感人群、宣传教育等综合处理工等工作信息不能共享，很难协同。
使用区域卫生信息平台
平时，通过区域卫生信息平台获得区域应公共卫生急物资和人力资源，评估应急能力，做出各应急预案，并建立疫情和突发公共卫生事件监测机制。
战时，基于区域卫生信息平台，利用先进的信息处理技术、科学的危机处理方法和现代的管理手段实现对突发事件相关数据的采集、危机判定、决策分析、命令部署、实时沟通、联动指挥、现场支援等功能。以在最短的时间内对危机事件做出最快的反应，采取合适的措施预案，有效地动员和调度各种资源进行指挥决策。指挥机构可及时、有效地调集各种急需的资源，实施疫情控制和医疗救治工作。
益处
区域应公共卫生急物资和人力资源方面的信息收集更全面、更准确。
业务协同更畅顺。
指挥决策更准确。
减轻突发公共卫生事件对人民健康和生命安全造成的威胁，用最有效的控制手段和最优的资源投入，将事件造成的负面影响与损失控制在最小范围内。
用例二：卫生服务绩效评价
卫生服务绩效评价业务的主要参与者及其需开展的业务如下：
卫生服务的提供者：如社区卫生服务中心的工作人员。
卫生服务绩效评价者：区域政府部门，卫生主管部门，以及社区卫生服务中心领导。
下表是对场景描述，通过对现在使用的流程、使用区域卫生信息平台后的流程进行对比，对有平台后的益处进行分析。
表2-8 卫生服务绩效评价情景描述
场景：在开年度财政预算会议上，局长提出了以下几个问题：公共卫生服务经费如何补偿？补偿多少？政府应该怎么购买公共产品？怎么评估工作量？以什么样的价格购买？
无区域卫生信息平台
无法了解公共卫生服务开展的准确、详细的数量和质量，无法定价。
只能按照“平均主义”发放卫生服务补偿经费。
使用区域卫生信息平台
通过区域卫生信息平台，政府实时了解获得公共卫生服务的工作量和工作质量。
必须通过建立完善绩效考核分配机制，通过区域卫生信息平台对公共卫生服务的开展进行过程监督，将社区卫生服务中心绩效分配机制从原来“以收益为基础”调整为“以效率为基础”。
益处
规范公共卫生服务经费的使用，提高财政资金的使用效率。
充分体现“按劳取酬”和“优劳优得”，激发医疗卫生人员的工作积极性，提高工作效率，提高社区卫生服务能力和水平。

从上面的分析可以发现，不管是公共卫生服务、医疗卫生服务、社区卫生服务，还是区域卫生综合管理，其最终目的都是为了满足人们的医疗健康服务。公共卫生服务、医疗卫生服务、社区卫生服务、区域卫生综合管理都离不开居民健康档案信息。区域卫生信息平台的建设必须以健康档案为核心，通过区域卫生信息平台，构建统一的居民电子健康档案，实现健康信息在区域内不同卫生机构间共享利用，实现各机构间业务更加协同，以提高医疗卫生业务质量和效率，提高卫生监管与决策能力，逐步缓解和解决“看病贵，看病难”民生问题。
第三章 居民健康档案信息架构
第一节 信息架构概述
居民的健康档案信息客观上来源于众多医疗卫生服务机构，只有将这些分散在不同地点、以不同形式表示和存储的数据信息通过统一的标准汇集和交换，才能形成统一和完整的居民电子健康档案，实现信息共享。研究制定居民健康档案信息架构，就是为了让区域卫生信息平台建设者，依照统一的建模方法和技术路线，把分散的、不一致的信息资源，规范和整合为一个完整的逻辑主体。信息架构是基于健康档案的区域卫生信息平台的核心，在构建信息架构时必须充分考虑到区域中各种卫生及相关业务活动的业务要求。
一、信息架构的内容
信息架构组成包括数据模型、数据存储模式与数据管理三个部分。数据模型是对卫生领域各种活动所产生和使用信息和数据的抽象表述，为卫生信息领域中不同应用开发者提供统一的建模工具和方法，保证数据定义和表述的一致性。数据模型进一步细分为：数据概念模型、数据逻辑模型、数据物理模型，以及相对应的数据标准。数据存储模式是指数据的存储框架，其所研究和解决的问题是，共享数据资源在空间上如何分布和存储的问题。数据管理主要是制定贯穿健康档案数据生命周期的各项管理制度。信息架构涉及的内容如图3-1所示。
图3-1 信息架构涉及的内容（略）
（一）数据模型
数据模型是平台信息架构规划中最重要的内容，定义良好的数据模型可以反映业务模式的本质，确保信息架构能为业务需求提供全面、一致、完整的高质量共享数据，且为划分应用系统边界、明确数据引用关系、定义应用系统间的集成接口提供开发依据。良好的数据建模与数据标准的制定是实现数据共享、保证信息一致性、完整性与准确性的基础。在这一基础上，区域卫生信息平台才能通过信息系统的应用开发，实现基于数据的管理和决策功能。
数据模型分为：数据概念模型、数据逻辑模型、数据物理模型。数据概念模型是对卫生领域各种数据的最高层抽象，用来描述卫生信息的概念化结构，数据范围以及数据之间的联系等，与具体业务域和技术实现方法无关。数据概念模型的特点是凌驾于个别业务需求之上，满足全局的共性需求。数据逻辑模型是用户对某一业务域内对数据的抽象描述，从具体的一个业务域提出对数据内容和逻辑关系的理解，而与信息技术实现方法无关。数据逻辑模型的特点是技术无关性。数据物理模型是描述数据具体存储实现方式，例如使用什么数据库系统或使用什么存储介质。数据模型是本章描述的重点。关于数据标准部分，可参考相关的国际和国内标准。
（二）数据存储模式
对于基于健康档案的区域卫生信息平台来说，数据存储模式是信息架构要考虑的一项重要内容。对于区域卫生信息的使用者而言，没有必要关心数据的存储模式。这比如大家从互联网上查找新闻时，大家并不关心存储这条新闻的服务器放在那个国家，也即不必关心数据存储模式。但是区域卫生信息平台的设计者，需要从经济可行性、技术可行性和管理可行性方面去考虑选择不同的数据存储模式。
数据存储模式种类有以下三种：集中式、分布式和联邦式。集中式：建设一个统一的数据中心，把一个区域内需要共享的数据集中全部存储在数据中心。分布式：一个区域内没有统一的数据存储中心，数据可以分散在不同的机构和地点。例如，某个患者需要访问上个月做的X光检查资料，区域卫生信息平台会将该患者的访问需求转移到他上个月去的医院的系统，将存储在该医院的数据提供给患者使用。所谓联邦式是集中与分布相结合的数据存储模式，对于用户经常访问的数据集中在数据中心，其余分散在不同地点或机构。
如何选择适宜的数据分布存放模式，将在 “系统架构”和“技术架构”等章节有进一步的描述。
（三）数据管理
数据管理主要是制定贯穿健康档案数据生命周期的各项管理制度，包括：数据模型与数据标准管理，数据存储管理，数据质量管理，数据安全管理等制度。
基于健康档案的区域卫生信息平台的数据管理制度将在平台的建设过程中逐步完善。
二、数据模型的重要性
数据概念模型提供了一个易于理解的健康档案的整体信息定义框架，是健康档案信息模型的基础架构。在数据概念模型的指导下，可以针对各个具体的业务域建立相应的逻辑数据模型。因此，数据概念模型将为基于健康档案的区域卫生信息平台的开发提供一个整体信息框架和数据应用指南。
数据逻辑模型描述具体的健康档案信息，它与数据概念模型一样独立于任何具体的信息系统。其作用是为健康档案中来源于各种卫生服务活动的所有记录信息，建立一个统一的标准化的数据表达模式和信息分类框架，并方便对健康档案信息的快速理解和实现健康档案的信息共享。
在基于健康档案的区域卫生信息平台中，数据模型有利于支持多个信息系统的开发，减少重复性工作，降低开发成本，加快系统的开发速度。在同一个数据模型指导下开发的多个系统间具有良好的信息一致性，为系统间的数据交换与共享奠定了基础。
数据分类虽然与数据模型之间有着内在的关系，但数据分类不能代替数据模型。数据分类框架关心的是对数据的分类，确定数据所在的位置，以便用户存放、查找及使用数据，但并不涉及对于主题域、类之间的关联以及类属性的描述。而建立数据模型的目的是为了更全面地理解信息和描述信息。第二节 健康档案的信息内容
一、健康档案的系统架构
健康档案的系统架构是以人的健康为中心，以生命阶段、健康和疾病问题、卫生服务活动（或干预措施）作为三个纬度构建的一个逻辑架构，用于全面、有效、多视角地描述健康档案的组成结构以及复杂信息间的内在联系。通过一定的时序性、层次性和逻辑性，将人一生中面临的健康和疾病问题、针对性的卫生服务活动（或干预措施）以及所记录的相关信息有机地关联起来，并对所记录的海量信息进行科学分类和抽象描述，使之系统化、条理化和结构化。
健康档案的三维系统架构如图3-2所示：
图3-2 健康档案的三维系统模型（略）
第一维（X轴）：生命阶段
按照不同生理年龄可将人的整个生命进程划分为连续的若干生命阶段，如：婴儿期（0～1岁）、幼儿期（1～3岁）、学龄前期（3～6岁）、学龄期（6～12岁）、青春期（12～20岁）、青年期（21～45岁）、中年期（46～60岁）、老年期（60岁以上）等八个生命阶段。也可以根据基层实际工作的需要，将人群化分为：儿童、青少年、育龄妇女、中年和老年人。
第二维（Y轴）：健康和疾病问题
每一个人在不同生命阶段所面临的健康和疾病问题不尽相同。确定不同生命阶段的主要健康和疾病问题及其优先领域，是客观反映居民卫生服务需求、进行健康管理的重要环节。
第三维（Z轴）：卫生服务活动（或干预措施）
针对特定的健康和疾病问题，医疗卫生机构开展一系列预防、医疗、保健、康复、健康教育等卫生服务活动（或干预措施），这些活动反映了居民健康需求的满足程度和卫生服务利用情况。
健康档案的三维概念模型，可以清晰地反映出不同生命阶段、主要疾病和健康问题、主要卫生服务活动三者之间的相互联系。同时，坐标轴上的三维坐标连线交叉所圈定的空间位置（域），表示了人在特定生命时期、因特定健康问题而发生的特定卫生服务活动所需记录的特定记录项集。由于三维空间中的任意一个空间位置都对应着某个特定的健康记录，从而构成了一个完整、立体的健康记录，这些健康记录全面地反映了个人健康档案内容的全貌。
健康档案的三维概念模型为健康档案内容的规划与设计提供了一个科学、合理、灵活的指导框架。由于人的健康状况及健康危险因素很大程度上受到社会经济和环境因素条件的影响，因此在不同的社会经济发展阶段、不同的地区和环境条件下，所需重点关注的主要健康问题以及所需记录的主要健康信息必然存在差异。在进行健康档案的规划设计时，应因地制宜，在三维概念模型的指导下，根据不同环境条件和关注的重点选取适合本地需求的主要健康问题和记录项集；并可根据实际情况进行灵活的调整（更新、缩减或扩展），使有限的卫生资源得到合理的分配和充分利用。
另一方面，与特定健康问题和卫生服务活动相对应的记录项集的内容，即内部记录项也不是一成不变的。在所关注的健康问题及卫生服务活动的深度和广度不断调整、完善的过程中，健康记录的内容可以随着居民健康管理需求或干预措施的变化与改善而进行适时调整。
由此可见，用于描述健康记录的数据模型必须具备良好的可扩展性，在满足所记录的健康内容不断变化的同时，能够保持数据模型的稳定。
二、健康档案的基本内容
根据健康档案的基本概念和系统架构，健康档案的基本内容主要由个人基本信息和主要卫生服务记录两部分组成。
（一）个人基本信息
包括人口学和社会经济学等基础信息以及基本健康信息。其中一些基本信息反映了个人固有特征，贯穿整个生命过程，内容相对稳定、客观性强。主要有：
1．人口学信息：如姓名、性别、出生日期、出生地、国籍、民族、身份证件、文化程度、婚姻状况等。
2．社会经济学信息：如户籍性质、联系地址、联系方式、职业类别、工作单位等。
3．亲属信息：如子女数、父母亲姓名等。
4．社会保障信息：如医疗保险类别、医疗保险号码、残疾证号码等。
5．基本健康信息：如血型、过敏史、预防接种史、既往疾病史、家族遗传病史、健康危险因素、残疾情况、亲属健康情况等。
6．建档信息：如建档日期、档案管理机构等。
（二）主要卫生服务记录
健康档案与卫生服务活动的记录内容密切关联。主要卫生服务记录是从居民个人一生中所发生的重要卫生事件的详细记录中动态抽取的重要信息。按照业务领域划分，与健康档案相关的主要卫生服务记录有：
1．儿童保健：出生医学证明信息、新生儿疾病筛查信息、儿童健康体检信息、体弱儿童管理信息等。
2．妇女保健：婚前保健服务信息、妇女病普查信息、计划生育技术服务信息、孕产期保健服务与高危管理信息、产前筛查与诊断信息、出生缺陷监测信息等。
3．疾病预防：预防接种信息、传染病报告信息、结核病防治信息、艾滋病防治信息、寄生虫病信息、职业病信息、伤害中毒信息、行为危险因素监测信息、死亡医学证明信息等。
4．疾病管理：高血压、糖尿病、肿瘤、重症精神疾病等病例管理信息，老年人健康管理信息等。
5．医疗服务：门诊诊疗信息、住院诊疗信息、住院病案首页信息、成人健康体检信息等。
三、健康档案的信息来源
健康档案信息量大、来源广且具有时效性。其信息收集应融入到医疗卫生机构的日常服务工作中，随时产生、主动推送，一方采集、多方共享，实现日常卫生服务记录与健康档案之间的动态数据交换和共享利用，避免成为“死档”，并减轻基层卫生人员的负担。
由于人的主要健康和疾病问题一般是在接受相关卫生服务（如预防、保健、医疗、康复等）过程中被发现和被记录，所以健康档案的信息内容主要来源于各类卫生服务记录。主要有三个方面：一是卫生服务过程中的各种服务记录；二是定期或不定期的健康体检记录；三是专题健康或疾病调查记录。
卫生服务记录的主要载体是卫生服务记录表单。卫生服务记录表单是卫生管理部门依据国家法律法规、卫生制度和技术规范的要求，用于记录服务对象的有关基本信息、健康信息以及卫生服务操作过程与结果信息的医学技术文档，具有医学效力和法律效力。
与健康档案内容相关的卫生服务记录表单主要有以下六个部分：
（一）基本信息
1．个人基本信息：个人基本情况登记表。
（二）儿童保健
2．出生医学登记：出生医学证明。
3．新生儿疾病筛查：新生儿疾病筛查记录表。
4．儿童健康体检：0～6岁儿童健康体检记录表。
5．体弱儿童管理：体弱儿童管理记录表。
（三）妇女保健
6．婚前保健服务：婚前医学检查表、婚前医学检查证明。
7．妇女病普查：妇女健康检查表。
8．计划生育技术服务：计划生育技术服务记录表。
9．孕产期保健与高危管理：产前检查记录表、分娩记录表，产后访视记录表、产后42天检查记录表，孕产妇高危管理记录表。
10．产前筛查与诊断：产前筛查与诊断记录表。
11．出生缺陷监测：医疗机构出生缺陷儿登记卡。
（四）疾病控制
12．预防接种记录：个人预防接种记录表。
13．传染病记录：传染病报告卡。
14．结核病防治：结核病人登记管理记录表。
15．艾滋病防治：艾滋病防治记录表。
16．血吸虫病管理：血吸虫病病人管理记录表。
17．慢性丝虫病管理：慢性丝虫病患者随访记录表。
18．职业病记录：职业病报告卡、尘肺病报告卡、职业性放射性疾病报告卡。
19．职业性健康监护：职业健康检查表。
20．伤害监测记录：伤害监测报告卡。
21．中毒记录：农药中毒报告卡。
22．行为危险因素记录：行为危险因素监测记录表。
23．死亡医学登记：居民死亡医学证明书。
（五）疾病管理
24．高血压病例管理：高血压患者随访表。
25．糖尿病病例管理：糖尿病患者随访表。
26．肿瘤病病例管理：肿瘤报告与随访表。
27．精神分裂症病例管理：精神分裂症患者年检表、随访表。
28．老年人健康管理：老年人健康管理随访表等。
（六）医疗服务
29．门诊诊疗记录：门诊病历。
30．住院诊疗记录：住院病历。
31．住院病案记录：住院病案首页。
32．成人健康体检：成人健康检查表。第三节 健康档案数据建模方法
健康档案的数据模型用于描述健康档案信息、以及帮助健康档案的管理和使用者更加全面地理解健康档案信息。在数据和信息模型方面，目前最有影响力和发展前景的无疑是HL7的RIM模型。HL7是卫生信息交换第七层协议的英文缩写（Health Level Seven）。HL7是一个非营利性的自愿组织，它的会员由对开发和促进卫生领域的临床和管理标准感兴趣的医院、信息技术厂商、医疗保险机构、以及政府协会组成。HL7于1987 年3 月在美国宾州大学医院组建，其宗旨是解决不同厂商设计的信息系统如何实现信息交换和数据共享的问题，至今已逾20多年。
HL7研究和开发RIM（ReferenceInformation Model）模型的目的是为了解决大家开发和制定的信息标准不一致问题，需要为标准开发和制定者提供一个最高层次的参考模型。RIM是一个纯粹的对象结构模型，某一个业务域的专家在开发数据标准中，其所使用到的任何元素、数据类型、词汇或代码如果都是衍生自RIM 规范要求，就可保证与其他业务域一致。
目前，国外一些健康档案的数据模型工作很多都是基于HL7 RIM或采用了HL7 RIM的思想和方法。虽然起初HL7主要是针对临床信息的交换而开发的，但随着HL7的发展、尤其是引入RIM之后，HL7的模型和方法已经不再局限于临床应用，而是能够满足病人管理、财政、公共卫生、EHR、基因组学等更广泛领域的建立信息模型的需求。考虑到与国际主流信息模型接轨的需要， 可采用RIM以及HDF数据模型开发框架（HDF）作为健康档案数据建模的方法。
一、数据概念模型
数据概念模型与具体业务域和技术实现方法无关，仅仅描述数据范围以及数据之间的联系，健康档案的数据概念模型完全对应于HL7 RIM，使用六个主题域去抽象描述涵盖卫生及相关域的全部数据信息内容。
（一） 健康档案数据的主类（主题域）
现实世界是由各种各样的实体（事物、对象）所组成的，每种对象都有自己的内部状态和活动特征，不同对象间的相互联系和相互作用就构成了各种不同的系统。人们为了更好的认识客观世界，把具有相似内部状态和活动特征的实体（事物、对象）综合在一起称为类，类是具有相似内部状态和运动规律的实体的集合。我们从一个个具体的事物中把共同的特征抽取出来，就形成了一个一般性的概念，这就是"归类"。例如：把转诊、报销、检查、开医嘱等工作归类为“活动”。
HL7 RIM模型把全部卫生信息（数据）抽象为六个类，因此健康档案数据模型也用六个类表述，也称之为“域”或“主类”。这六个“域”或“主类”中两个最基本的主类是：活动和实体；另外两个主类连接活动和实体，它们是：参与和角色；最后两个主类是：活动关联和角色连接。它们之间的关系如图3-4所示。
图3-3 数据模型的主类示意图（略）
各个主类的含义如下：
活动：表示卫生服务活动（或干预措施），这些服务活动或干预措施产生相关的健康档案记录信息。
实体：是指物理意义上的人和物。包括所有生命体（Living Subjects）（如人和动物）、机构（正式的和非正式的）、材料（如持久和非持久的货物、食物、组织、容器）和场地。
角色：是指“实体”在“参与”卫生服务活动（或干预措施）过程中所扮演的各种角色。
参与：定义“角色”和“活动”之间的关系，是指“实体”通过扮演的“角色”“参与”卫生服务活动（或干预措施）的行为方式。
活动关联：描述“活动”之间的相互关系。
角色关系：描述参与卫生服务活动（或干预措施）的各个角色之间的关系。
以下是对各个主题域的进一步说明：
1．活动
活动是从数据角度定义健康档案信息模型的基础。在健康档案平台中共享的各种数据通常都关联到生成它的主要卫生服务活动（或干预措施）。活动域表示发生在与健康档案平台相关的各个系统中的不同活动类型。它的范围仅限于有值的活动类型，这些值用于居民电子健康记录的共享。
通过活动，可以记录在特定时间（或时刻）对所感兴趣的特定对象的状态所发生的变化。这里所说的时间概念可能是一个时间点（时刻），也可能是一个由开始时间和结束时间所定义的时间段。
2．活动关联
活动关联描述的是活动之间的关联关系。活动在发生时就会被记录在健康档案的信息平台之中。
根据那些向健康档案信息平台提供活动数据的医疗机构内部信息系统应用程序的能力的不同，用于确定某个特定活动如何与早已记录在某一个人的健康档案之中的其他活动相关联的数据，可能存在关联，也可能不存在关联。例如，当产生出一项检验结果并将其录入到实验室机构信息系统之中时，该系统就会将该结果发布到健康档案信息平台。对于这样的一个结果，它可能包含或不包含足够的信息，用于确定究竟是什么实验室医嘱导致了此项实验室检验项目的执行。与此类似，它也可能包含或不包含足够的信息，用于确定为该实验室检验申请时所处的就医背景。
不过，健康档案信息平台预期支持的是将不同活动彼此关联起来的能力，而活动关联则用于表达支持这一能力。健康档案信息平台需要识别的是活动之间不同类型的关联关系。例如，历史型活动关系，组成型活动关系，依赖型链接关系和相关型链接关系。
3．实体
实体包括人、地点、环境、资源、资料等。
人包括用于表示参与医疗保健系统的人员、组织机构或其他类型群体的所有实体或信息类。基本来说，人旨在表示的是在健康档案信息模型之中，要使我们能够确定出一个医疗活动是关于谁的，即患者；谁参与了与该活动相关联的医疗服务提供过程，即医疗服务提供者以及他们所属的组织机构。人的定义中所包括的一个关键概念就是分组的概念。此概念可表示一组正在作为医疗活动对象的患者。关于这个概念的一个具体例子就是，在公共卫生服务域中，传染病暴发所涉及到的一群患者。
地点概括为描述健康档案信息模型之中位置概念的信息。地点用于回答个人健康档案之中关于医疗活动“在何处”或者说“在哪”发生的问题。在信息模型中采用地点，就可以让健康档案信息模型包含医疗活动在哪发生，机构位于何处，某个设施位于何处，事故发生在何处，患者在哪接受家庭护理服务，等等之类的信息。
环境描述健康档案信息模型之中位置概念的所处的环境信息。
“环境”是指特定时刻表现在地点上的理化特性。当环境因素影响个人健康时，或者当需要对传染病的媒介或携带者加以隔离时，与地点相关联的这个概念，就是众多健康监测需求的关键。
在健康档案信息模型中，医疗活动表示为活动。资源保存的是那些用于完成医疗活动的不同类型资源的有关信息。资源之中所保存的这些信息用于回答关于“在提供特定医疗服务的过程中，究竟涉及到了哪些资源”的问题。资源的范围包括人力资源，设备资源，信息资源，物质资源和供应品资源。
在健康档案信息模型中，资源的能力是运用政策和业务规则时所需的一个关键信息。比如，资源能力可能会声明，“医生”类型的某人力资源不能在某个时间段内开展医疗活动。
4．角色
角色中保存的是关于特定类型实体在其参与医疗服务提供或获取时表现出来的那些职能信息。通常将角色分配给人员。角色的类包括服务提供者、服务接受者或客户、支持人员、经授权的信息接收者、经授权的系统用户、经授权的应用程序、管理者或管理员等。
（二）数据概念模型图
数据概念模型的主类（包括子类）的UML图如图3-5所示。该图来源于HL7。
图3-4 数据概念模型的UML图（略）
二、数据逻辑模型
健康档案的数据逻辑模型是通过继承数据概念模型并对数据概念模型进行细化（演绎）而产生的。健康档案的概念数据模型采用HL7 RIM，健康档案的逻辑数据模型也 可采用HL7的信息模型建立方法，并最大程度地遵循已有的HL7标准的内容。由于HL7到目前为止并没有提出一个完整的健康档案的信息模型，加上我国健康档案信息有着一些特殊性，当采用HL7 RIM和HL7的方法论建立健康档案的数据模型时，必然存在着对HL7的扩充工作。因此，我国标准的、完善的健康档案数据模型的建立也必然要经历一定的发展历程。
（一）数据逻辑模型概述
RIM是一个最抽象的数据概念模型，本身并无法用于表述具体的数据或含义。要实现对某域中具体健康档案数据的描述，要在RIM的基础上派生和细化（演绎）为域信息模型D-MIM（Domain Message Information Model）和精细化消息模型R-MIM（Refined Message Information Model）。R-MIM是对一个具体业务活动的数据进行规范表述的模型，例如，“注射单”具体应包含哪些项目，每个项目用什么方式表述。 D-MIM是一个业务域的数据逻辑模型，该域中所有R-MIN都继承和依从D-RIM模型，而D-MIM模型又完全继承和依从RIM模型。
目前HL7已经开发出常用的D-MIM和R-MIM模型，提供给应用开发者直接使用。在数据模型的层次上，RIM属于数据概念模型，而D-MIM和R-MIM都对应于数据逻辑模型，HL7的RIM、D-MIM、R-MIM与数据模型的层次关系如图3-6所示。
图3-5 数据模型与HL7模型之间的层次对应关系（略）
HL7域信息模型D-MIM
D-MIM 是RIM的派生，它包括在特殊域（Domain）中适用的经过充分扩充的类克隆（Class Clone）、属性和关系。类克隆是用来满足特定目的而设计的精细化的RIM基础类。精细化的过程可以约束RIM类的属性和关系，但不能添加RIM基础类中未出现的任何属性。D-MIM 是构建域中所有精细化消息信息模型（R-MIM）的共同基础。
对应于健康档案的数据模型来说，D-MIM侧重于描述健康档案所涉及的某个域的数据模型，这个数据模型反映了某个域的数据模型全貌（如：类克隆、属性和类关系），但还不包含健康档案逻辑数据模型所需要的一些信息内容细节。
HL7精细化消息信息模型R-MIM
R-MIM是带有注释的一个或一组消息的信息内容细节，是D-MIM的一个子集。R-MIM表达了一个或多个层次消息描述的信息内容，它源自由R-MIM入口点标示的根类。R-MIM是所有其它HL7消息制品的源，这些制品可以是一组XML Schema或者其他格式的消息制品。
对应于健康档案的数据模型来说，R-MIM描述了具体的健康档案信息，R-MIM所描述的逻辑模型可以用于指导进一步的数据库设计。
（二）数据模型域
通过继承数据概念模型建立相应的数据逻辑模型时，需要根据健康档案的信息内容划分出不同的域，先建立反映一个域的信息模型D-MIM，然后再细化并生成描述具体信息内容的信息模型R-MIM。
对应于健康档案的信息内容，将健康档案数据模型对应的域划分成五大业务域组和31个子域，如表3-1所示。
表3-1 健康档案的数据模型对应的子域
域分组
各子域
1 儿童保健
01 出生医学登记
02 新生儿疾病筛查
03儿童健康体检
04体弱儿童管理
2 妇女保健
01 婚前保健服务
02 妇女病普查
03 计划生育技术服务
04 孕产期保健服务与高危管理
05 产前筛查与诊断
06 出生缺陷监测
3 疾病控制
01 预防接种
02 传染病报告
03 结核病防治
04 艾滋病综合防治
05血吸虫病病人管理
06 寄生虫病病人管理
07 职业病报告
08 职业性健康监护
09 伤害监测报告
10 中毒报告
11 行为危险因素监测
12死亡医学证明
4 疾病管理
01 高血压病例管理
02 糖尿病病例管理
03 肿瘤病例管理
04 精神分裂症病例管理
05 老年人健康管理
5 医疗服务
01门诊诊疗
02 住院诊疗
03 住院病案首页
04 成人健康体检
数据模型的域在整个健康管理过程中并不是独立的，之间存在着一定的关系。如“出生医学登记”将产生“预防接种”服务；“传染病报告”的信息可来源于“医疗服务域组”、“疾病管理域组”、“儿童保健域组”或“妇女保健域组”的卫生服务活动所产生的信息。数据模型域如图3-6所示。
图3-6 数据模型的域示意图（略）
1. 儿童保健域组
儿童保健工作是卫生工作的重要组成部分，属于专业公共卫生的范畴。
各级卫生行政部门是儿童保健工作的主管部门，负责制订儿童保健工作方针政策、发展规划、技术规范与标准，并组织实施。妇幼保健机构作为辖区妇幼保健的技术指导中心，根据职责分工，对社区卫生服务机构、乡镇卫生院和其他医疗机构的儿童保健工作进行技术指导和业务培训，推广适宜技术。
儿童保健服务的对象为0-18岁儿童。儿童保健管理包括散居儿童保健管理、托幼机构卫生保健管理、儿童保健信息管理等。根据不同年龄儿童生理和心理发育特点，为胎儿期、新生儿期、婴幼儿期、学龄前期、学龄期及青春期儿童提供基本保健服务，具体内容包括生长发育监测、喂养与营养指导、儿童早期发展促进、心理行为发育评估与指导、免疫接种、常见疾病防治、健康安全保护、健康教育与健康促进等内容。
2. 妇女保健域组
做好妇女卫生保健工作、保障妇女儿童的身心健康，关系到每个家庭的幸福，关系到整个中华民族素质的提高，关系到计划生育国策的贯彻落实。
各级卫生行政管理部门设立相应的机构如妇幼卫生处等，负责分管妇幼卫生工作。各级妇幼卫生专业机构、综合医院妇产科、儿科、保健科等科室和厂矿企业等有关部门具体负责妇女保健工作的执行。
妇女保健工作内容主要包括：推广科学接生，实行孕产妇系统管理；积极防治妇女常见病、多发病；妇女经、孕、产、哺乳、更年期的卫生保健工作；进行卫生学调查，提出妇女劳动保护和卫生保健的建议，并督促实施以及出生缺陷筛查与管理（含新生儿疾病筛查与治疗）。
3. 疾病控制域组
疾病预防控制工作是提高全民健康水平的重要内容。各级卫生行政管理部门都设置了疾病预防控制中心作为疾病预防控制工作的直接管理部门。
疾病控制的主要工作内容包括：传染病防治（如艾滋病、结核病、霍乱、乙肝等）；预防免疫接种服务；慢性病防治（如糖尿病、高血压等）；职业病防治；地方病防治；职业健康监护；疾病预警预测等。
4. 疾病管理域组
疾病管理是公共卫生服务的重点内容之一。
疾病管理工作主要通过疾病预防控制机构、社区卫生服务机构、乡镇卫生院及相关医疗机构等开展。
疾病管理的主要工作内容包括：以社区或乡镇为中心开展的高血压病例管理、糖尿病病例管理、肿瘤及精神病病例管理等。
5. 医疗服务域组
医疗服务以门诊诊疗服务和住院诊疗服务为主，同时还包括家庭病床、门诊下地段服务以及健康体检等方式。
各级各类医疗机构为国民提供医疗服务，包括医院、妇幼保健院、乡镇卫生院、社区卫生服务机构、疗养院、诊所和医务室等。
（三）数据模型的词汇
HL7的词汇域用于表示类的属性。词汇域分“不可扩展”和“可扩展”两种类型。“可扩展”意味着在建立信息模型时，可以通过扩展已有的编码集来满足本地化的需求。
健康档案的数据元和数据集标准为建立健康档案的数据模型提供了重要的参考，大多数数据元可以直接映射到HL7标准中。
1．健康档案相关卫生服务基本数据集
基本数据集是指构成某个卫生事件（或活动）记录所必需的基本数据元集合。与健康档案相关的每一个卫生服务活动（或干预措施）均对应一个基本数据集。基本数据集标准规定了数据集中所有数据元的唯一标识符、名称、定义、数据类型、取值范围、值域代码表等数据元标准，以及数据集名称、唯一标识符、发布方等元数据标准。
针对健康档案的主要信息来源，目前已制定出健康档案相关卫生服务基本数据集标准共32个。按照业务领域（主题）分为3个一级类目：基本信息、公共卫生、医疗服务。其中“公共卫生”包含4个二级类目：儿童保健、妇女保健、疾病控制、疾病管理。32个卫生服务基本数据集的具体标准文本见附件。
表3-2 列出了健康档案相关卫生服务基本数据集标准目录。如：《出生医学证明基本数据集》的数据集标识符为“HRB01.01_V1.0”，表示该数据集标准属于“健康档案领域（HR）”中的一级类目“公共卫生（B）”下的二级类目“儿童保健（01）”，数据集顺序号为“01”，数据集版本号为“1.0”。
表3-2 健康档案相关卫生服务基本数据集标准目录
序号
一级类目
二级类目
数据集标准名称
数据集标识符
1
A基本信息

个人信息基本数据集
HRA00.01_V1.0
2
B公共卫生
01儿童保健
出生医学证明基本数据集
HRB01.01_V1.0
3
新生儿疾病筛查基本数据集
HRB01.02_V1.0
4
儿童健康体检基本数据集
HRB01.03_V1.0
5
体弱儿童管理基本数据集
HRB01.04_V1.0
6
02妇女保健
婚前保健服务基本数据集
HRB02.01_V1.0
7
妇女病普查基本数据集
HRB02.02_V1.0
8
计划生育技术服务基本数据集
HRB02.03_V1.0
9
孕产期保健服务与高危管理基本数据集
HRB02.04_V1.0
10
产前筛查与诊断基本数据集
HRB02.05_V1.0
11
出生缺陷监测基本数据集
HRB02.06_V1.0
12
03疾病控制
预防接种基本数据集
HRB03.01_V1.0
13
传染病报告基本数据集
HRB03.02_V1.0
14
结核病防治基本数据集
HRB03.03_V1.0
15
艾滋病防治基本数据集
HRB03.04_V1.0
16
血吸虫病病人管理基本数据集
HRB03.05_V1.0
17
慢性丝虫病病人管理基本数据集
HRB03.06_V1.0
18
职业病报告基本数据集
HRB03.07_V1.0
19
职业性健康监护基本数据集
HRB03.08_V1.0
20
伤害监测报告基本数据集
HRB03.09_V1.0
21
中毒报告基本数据集
HRB03.10_V1.0
22
行为危险因素监测基本数据集
HRB03.11_V1.0
23
死亡医学证明基本数据集
HRB03.12_V1.0
24
04疾病管理
高血压病例管理基本数据集
HRB04.01_V1.0
25
糖尿病病例管理基本数据集
HRB04.02_V1.0
26
肿瘤病例管理基本数据集
HRB04.03_V1.0
27
精神分裂症病例管理基本数据集
HRB04.04_V1.0
28
老年人健康管理基本数据集
HRB04.05_V1.0
29
C医疗服务

门诊诊疗基本数据集
HRC00.01_V1.0
30
住院诊疗基本数据集
HRC00.02_V1.0
31
住院病案首页基本数据集
HRC00.03_V1.0
32
成人健康体检基本数据集
HRC00.04_V1.0
2. 健康档案数据元
健康档案32个相关卫生服务基本数据集中共包含2252个数据元。其中两个或两个以上数据集中都包含的数据元，称为公用数据元。公用数据元是不同业务领域之间进行无歧义信息交换和数据共享的基础。健康档案公用数据元标准规定了健康档案所必须收集记录的公用数据元最小范围及数据元标准，目的是规范和统一健康档案的信息内涵和外延，指导健康档案数据库的规划设计。
健康档案公用数据元标准中共包含公用数据元1163个，191个数据元值域代码表。
制定健康档案数据元字典的主要作用是：统一和规范健康档案的信息内涵；指导健康档案数据库及相关健康管理信息系统的开发设计；支持健康档案与相关卫生服务活动以及其它信息资源库相互间的数据交换与共享；为相关卫生服务活动的信息管理规范化与标准化提供依据；为构建整体的卫生信息模型和国家卫生数据字典提供基础信息资源。
3．健康档案数据元字典
（1）基本概念
数据元字典是列举并定义了特定的语义环境中所有相关数据元的一种信息资源。健康档案数据元字典的特定语义环境是指健康档案，健康档案数据元字典中包含的是健康档案记录内容所涉及的所有数据元。健康档案的内涵和信息来源特征，决定了健康档案数据元字典中的数据元来源于与健康档案相关的各个卫生服务信息基本数据元集，是从各个业务数据元集中抽取的与个人健康管理相关的数据元。健康档案数据元的纳入原则主要有：
一是公用数据元，即在2个或2个以上业务数据元集中都包含的数据元。公用数据元体现了相关卫生服务活动对基于健康档案的数据交换和共享的需要。
二是健康档案信息利用者所需要使用的非公用数据元，如某些居民健康管理和健康监测的需要、卫生管理统计指标的需要、与外部卫生相关部门进行数据交换的需要等。
（2）数据元字典的特性
业务无关性。当所有从各个业务数据元集中抽取的数据元组成健康档案数据元字典后，即表现出与业务的无关性，即健康档案数据元字典中的数据元是独立于任何具体的卫生服务活动（业务应用系统）的，虽来源于相关业务，但已不再隶属于某个特定的业务环境。
灵活性。健康档案数据元字典中数据元的业务无关性，为卫生服务模式的改革发展及业务流程的再造与不断优化，提供了灵活的指导框架。譬如：根据某个新开展的卫生服务活动的需求，可以从健康档案数据元字典中，提取任意一组所需要的数据元来组装成一个新的卫生服务基本数据元集，并指导重新设计一个或一组能适应新的卫生服务活动要求的卫生服务记录表单。而且这些新的数据集和记录表单将自然符合既往的相关规范和标准，满足信息资源整合的需要。
可扩展性。随着卫生改革的发展进步，根据各项卫生服务活动在广度和深度上不断调整和完善的实际需求，健康档案相关卫生服务基本数据集的内容也将相应变化，不断推出新的标准版本，而且健康档案数据元字典的数据元纳入原则也会根据实际情况适时调整。因此，健康档案数据元字典是可扩展的。
第四节 数据模型实例
一、数据建模方法
（一）技术路线
对于基于健康档案的区域卫生信息平台，建立数据概念模型的方法如下图所示，接下来的内容对建立数据概念模型的方法进行了进一步的描述。
图3-7 建立信息模型的技术路线（略）
（二）场景分析
场景（Scenarios），就是指某域所发生的或可能发生的事件的描述，可以理解为现实活动的实例。完整的场景体现了事件的触发、发展、结局的过程。在概念模型建模场景分析里，对信息从医疗机构内部信息系统到健康档案平台存储过程的描述就是一个场景。而场景分析则是对这些场景进行重现、域的定义、归纳提取类、类关联、类属性的过程。
（三）信息域分析
在信息域分析中主要考虑要存储信息的域的范围，以及与其它域的信息之间的关系，如“新生儿出生证明”信息域与“计划免疫接种卡”信息域之间存在着一定的关系。
（四）主题域的确定
在信息域分析的基础上再对信息拆解、对比、描述、再定义、组合等分析，即对各组成元素进行分析、判别、抽象，并归纳。根据数据概念模型，将信息泛化到实体、角色、活动、参与、活动关联、角色关系）6个主题域中，活动作为信息的主体，其余5个均为事件的关联方，要深刻理解各个主题域内容以及主题域之间的关系，将分析抽象的结果与数据概念模型主题域结合。
（五）类的确定
确定信息在主题域中确定使用的类对象。如新生儿信息使用实体表达，登记事件信息使用活动表达等等。
（六）类关联
按照数据概念关系，描述出泛化后的实体、角色、活动、参与、活动关联、角色关系等对象之间的关系，有HL7相关标准的要使用HL7标准。
（七）类属性
将要保存的信息元素与信息模型的对象属性做对应关系映射。首先需要了解信息模型的数据类型的概念及其之间的关系，如LIST与List类型、AD类型之间的关系，AD类型的属性及属性取值范围，其所涉及的概念。
（八）数据库设计
对应数据库具体实现，考虑使用对象数据库模型设计方式。
二、数据建模实例
本小节结合基于健康档案的区域卫生信息平台的一个应用场景，根据上一小节描述的建立数据模型的方法，给出了信息模型的一个具体实例。
（一）目的
以实际用例的方式，描述健康档案数据建模过程，其内容包含信息主题域确定、类确定、类关联关系、类属性，以及最终落实到数据库逻辑设计实现的一系列分析与实现过程。
（二）场景与信息域分析
场景分析的目的是定义出数据的范围。通过开发用例模型提供相关领域事务的过程。用例模型是利用用例图捕获项目范围，以便能够完全定义设计出数据集合。场景分析一般使用故事板按照时间顺序，叙述事件发生过程以及故事中每个事件环节所涉及的参与者、以及相互间的关系和需要交换和传递的信息。以确定数据的类对象，以及类对象关联。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 系统总体架构图（略）
系统总体架构分为两个层次：区域卫生管理层和辖区卫生机构层。
区域卫生管理层表示区域卫生信息平台的管理中心，在实际应用中可以是一个地市级卫生信息数据中心，也可以是更高一级的数据中心。区域卫生管理层主要提供一系列服务，作为服务于卫生医疗区域（如省、地区、县市卫生管理机构）的单一实例而存在，主要服务组件包括注册服务、公卫数据服务、医疗数据服务、全程健康档案服务、数据仓库服务等。
辖区卫生机构层，是指在所管辖的区域范围内相关医疗卫生机构（包括三级医院、二级医院、社区卫生服务中心、公共卫生机构等）所有业务应用系统，这些系统生成、收集、管理和使用那些可以公布在与区域范围内居民相关的健康数据，包括临床医疗数据、健康档案数据、公共卫生管理数据等。这些系统分布在所有为居民提供医疗卫生机构的服务点，为广大老百姓提供各类健康服务。
区域卫生管理层和辖区卫生机构层之间通过区域卫生信息应用访问层来进行信息交互，以实现健康档案的互联互通性，信息访问层所提供的服务主要包括两个方面：一方面提供通信总线服务，如消息传输服务、消息路由等；另一方面提供应用软件通用的系统管理功能，如安全管理、隐私管理、应用审计等。第三节 平台构件组成
一、注册服务
注册服务包括对个人、医疗卫生人员、医疗卫生机构、医疗卫生术语的注册管理服务，系统对这些实体提供唯一的标识。针对各类实体形成各类注册库（如个人注册库、医疗卫生机构注册库等），每个注册库都具有管理和解决单个实体具有多个标识符问题的能力。注册库保有一个内部的非公布的标识符。
（一）个人注册服务
个人注册服务是指在一定区域管辖范围内，形成一个个人注册库，个人的健康标识号、基本信息被安全地保存和维护着，提供给区域卫生信息平台所使用，并可为医疗就诊及公共卫生相关的业务系统提供人员身份识别功能。
个人注册库主要扮演着两大角色。其一，它是唯一的权威信息来源，并尽可能地成为唯一的个人基本信息来源，用于医疗卫生信息系统确认一个人是某个居民或患者。其二，解决在跨越多个系统时用到居民身份唯一性识别问题。个人注册服务是区域卫生信息平台正常运行所不可或缺的，以确保记录在健康档案中的每个人被唯一地标识，他们的数据被一致地管理且永不会丢失。
该注册服务主要由各医院、社区和公共卫生机构来使用，完成居民的注册功能。
（二）医疗卫生人员注册服务
医疗卫生人员注册库，是一个单一的目录服务，为本区域内所有卫生管理机构的医疗服务提供者，包括全科医生、专科医生、护士、实验室医师、医学影像专业人员、疾病预防控制专业人员、妇幼保健人员及其他从事与居民健康服务相关的从业人员，系统为每一位医疗卫生人员分配一个唯一的标识，并提供给平台以及与平台交互的系统和用户所使用。
该功能的基本流程为，各医院、社区和公共卫生机构提供所辖医疗卫生人员基础信息给医政，医政完成审核并将这些医疗卫生人员信息在平台上给予注册。
（三）医疗卫生机构注册服务
通过建立医疗卫生机构注册库，提供本区域内所有医疗机构的综合目录，相关的机构包括二三级医院、社区卫生服务中心、疾病预防控制中心、卫生监督所、妇幼保健所等。系统为每个机构分配唯一的标识，可以解决居民所获取的医疗卫生服务场所唯一性识别问题，从而保证在维护居民健康信息的不同系统中使用统一的规范化的标识符，同时也满足区域卫生信息平台层与下属医疗卫生机构服务点层的互联互通要求。
医疗卫生机构注册服务主要由医政（卫监）来使用，完成医疗卫生机构的注册。
（四）医疗卫生术语和字典注册服务
建立术语和字典注册库，用来规范医疗卫生事件中所产生的信息含义的一致性问题。术语可由平台管理者进行注册、更新维护；字典既可由平台管理者又可由机构来提供注册、更新维护。
二、健康档案存储服务
健康档案存储服务是一系列存储库，用于存储健康档案的信息。根据健康档案信息的分类，健康档案存储服务分为七个存储库：个人基本信息存储库、主要疾病和健康问题摘要存储库、儿童保健存储库、妇女保健存储库、疾病控制存储库、疾病管理存储库以及医疗服务存储库。
三、医疗卫生信息共享和协同服务
医疗卫生信息共享和协同服务基于健康档案存储服务，提供医疗卫生机构之间的信息共享服务和业务协同服务。
根据健康档案信息的分类和服务需要，医疗卫生信息共享和协同服务分为七个域：个人基本信息域、主要疾病和健康问题摘要域、儿童保健域、妇女保健域、疾病控制域、疾病管理域以及医疗服务域。这些域又可以进一步细分为若干个子域，例如医疗服务域可以分为诊断信息域、药品处方域、临床检验域、医学影像域。
（一）个人基本信息域
个人基本信息域对外提供个人基本信息共享服务。
（二）主要疾病和健康问题摘要域
主要疾病和健康问题摘要域是区域卫生信息平台中的一个核心部件，它将所有与个人健康相关基础摘要信息进行汇集、存储、并对外提供服务。主要疾病和健康问题摘要域在区域卫生信息平台中主要包含以下内容：血型、过敏史、慢病信息等，这些的摘要信息汇集不是从某个基础业务系统中单独获取，而是从众多的基础业务系统中抽取汇集而成。摘要域的主要服务方式是为医疗卫生人员提供一种通用的、及时的、可信的调阅服务，为医疗卫生人员在进行医疗卫生服务时能够及时、快捷的了解患者、居民基础健康信息提供一种技术支撑。
（三）儿童保健域
儿童保健域用于维护及管理区域妇幼机构、社区卫生服务中心、儿童医院、幼托机构、计生委、民政局等机构所产生的儿童保健数据及提供的儿童保健服务。数据主要包括出生医学证明、新生儿疾病筛查、出生缺陷监测、体弱儿童管理、儿童健康体检、儿童死亡管理等数据。
儿童保健域数据体现了数据间的联动性，如根据出生医学证明可以触发新生儿访视和儿童计划免疫服务。
（四）妇女保健域
妇女保健域用于维护及管理区域妇幼机构、社区卫生服务中心、助产医院、计生委、民政局等机构所产生的妇女保健数据及提供的妇幼保健服务。数据主要包括妇女婚前保健、计划生育、妇女病普查、孕产妇保健服务及高危管理、产前筛查与诊断、孕产妇死亡报告等数据。
妇女保健数据体现了数据间的联动性，如妇女在三级医院发现自己怀孕后，需要三级医院将怀孕数据及时传送到妇女所在的社区卫生服务中心及区妇幼保健所，由社区卫生服务中心的防保医生提供产前保健服务，社区服务中心也需将此产前保健数据传送给妇女生产医院，生产医院将妇女产前检查、分娩数据传送回社区卫生服务中心，社区卫生服务可获知妇女分娩并及时上门进行产后访视服务。
（五）疾病控制域
疾病预防控制域用于维护和管理区县CDC、社区卫生服务中心、二三级医院、地市CDC所产生的突发公共卫生事件应急处置和日常业务管理（人群健康的疾病预防控制级监测、干预、评估）数据及各种服务。突发公共卫生事件应急处置数据是针对事件处置的全过程管理数据，日常业务管理数据是针对人群的疾病健康预防和控制的数据。
数据主要包括免疫接种、传染病报告、结核病防治、艾滋病综合防治、血吸虫病病人管理、职业病报告、职业性健康监护、伤害监测报告、中毒报告、行为危险因素监测、死亡医学登记。
数据着重体现了过程性及联动性，即区域内各个医疗机构（CDC、医院、社区卫生服务中心）形成紧密的卫生业务联动，如某社区的居民在市级三级医院发现传染病，需要市级三级医院形成传染病管理报告卡，并将报告卡数据传送到居民所在的社区卫生服务中心及区CDC，区CDC负责审核报告卡，社区卫生服务中心的防保医生进行上门确认及随访，区CDC审核随访数据。
（六）疾病管理域
疾病管理域用于维护和管理区县CDC、社区卫生服务中心、二三级医院、地市CDC所产生的疾病管理数据及各种服务。
数据主要包括高血压病例管理、糖尿病病例管理、肿瘤病例管理、精神分裂症病例管理、老年人健康管理、成人健康体检。
数据着重体现了过程性及联动性，即区域内各个医疗机构（CDC、医院、社区卫生服务中心）形成紧密的卫生业务联动，如某社区居民在市级三级医院发现糖尿病，需要市级三级医院马上形成糖尿病管理报告卡，并将报告卡数据传送到居民所在的社区卫生服务中心及区CDC，区CDC负责审核报告卡，社区卫生服务中心的防保医生进行上门确认及随访，区CDC审核随访数据。
（七）医疗服务域
医疗服务域是用于临床信息共享和医疗业务协同的，包括诊断信息域、药品处方域、临床检验域、临床检查域和医学影像域。
1. 诊断信息域
药品处方域系统--也被称为药物信息系统（DIS）。DIS 系统记录处方和药物治疗信息，提供完整的患者用药记录，并为医师开处方和调配药物提供决策支持服务。区域卫生信息平台药品处方域服务支持用户通过药品处方域存储服务提取患者临床数据并显示。
2. 药品处方信息域
药品处方域系统--也被称为药物信息系统。药物信息系统记录处方和药物治疗信息，提供完整的患者用药记录，并为医师开处方和调配药物提供决策支持服务。区域卫生信息平台药品处方域服务支持用户通过药品处方域存储服务提取患者临床数据并显示。
3. 临床检验信息域
临床检验信息域系统--也被称为区域实验室信息系统，是一个管理患者检验申请单和向临床医师发布患者检验结果的区域系统。在不同的卫生管理区域，实验室域系统可采取各种不同的形式和规模。关键在于要将浏览检验结果的解决方案与为了获得结果而涉及的与医嘱信息相关的一系列支持数据的解决方案的区别开来。
可以汇总化验结果及伴随数据（如之前的医嘱），这样可以向医疗卫生人员提供结果汇总信息视图。在最简单的状态下，检验域系统会自动从源系统中采集检验相关事件，如申请、标本、检验结果，并且允许基于标准消息查询这些数据以提取其中的任何信息。更先进的解决方案除提供这些基本功能外，也将支持流程自动化和申请及结果生成状态的管理，同时也会以一个更加积极的方式与源系统交互，生成警告和通知，以加快处理。
检验信息域服务通过基于标准的消息与产生和管理申请的实验室系统进行交互，同时也与系统中用以产生结果的采样和检测机构进行交互。换句话说，实验室机构内的医师用户和实验技师用户使用其本地信息系统解决方案进行其工作。这些应用系统，通过与信息平台相连接，能把关键相关结果数据发布或提升到患者的电子健康记录中。
4. 医学影像域（扩展）
医学影像域用于维护和管理医学影像的医嘱和结果信息，医学影像检查是健康档案的一个重要组成部分。大容量图像和其他二进制文件的管理和高效传输的技术要求是使得这部分服务独立成域的原因。
该服务允许集中获取和共享大型分布式网络中符合DICOM 的对象。这些网络包括在医院或诊断中心实施的图像归档及通讯系统（PACS）以及产生图像的诊断设备。通常情况下，与医学影像检查相关的数据有两部分，一份用于说明概要结论的书面报告和影像。影像可以采取不同的形式，如视频或声音，但多数时候会采取一张或多张影像的形式。无论是书面报告，还是用来达成结论的关键影像都可从数据中心服务中获得。
这里讨论的影像图像是典型的业务流程的最终结果，这些业务流程都开始于创建一个由临床医师为进行某一类型检查开立的医嘱。在数据中心域中，医嘱将被表现为一套支持某一图像诊断结果的数据，因此，可作为客户电子健康记录的一部分。
其他类型的二进制对象也可由数据中心域处理。实际例子包括：来自一个远距离会议的与临床有关的患者健康记录视频流剪辑，或任何来自不同设备（心电图，呼吸监视器等等）的数字流数据。
提供快捷、方便以满足存取大型图片或其他类型流对象的功能是一个挑战。区域卫生信息平台数据中心域服务支持用户查询数据中心域存储库中患者的临床数据并显示出来。集中管理的索引服务，作为全程健康档案服务的一部分，在记录患者接受医疗服务的场所和类型的数据中心信息上发挥了重要作用。当最终用户访问一个影像（或其他对象）以供浏览时，这个索引机制是DI域服务工作的核心。
四、全程健康档案服务
全程健康档案服务用于处理区域卫生信息平台内与数据定位和管理相关的复杂任务。该服务包括相关的索引信息，这些索引链接不同存储服务所保存的数据到一个特定的个人、医疗卫生人员、医疗卫生机构或者可以实时获取这些数据的服务点。全程健康档案服务负责分析来自外部资源的信息，并恰当地保存这些数据到存储库中，可以反向地响应外部医疗卫生服务点的检索、汇聚和返回数据。全程健康档案服务也知道其他区域卫生信息平台可能在客户端保存的附加数据，也能够对那些区域卫生信息平台转发数据请求，并合并返回数据和本地信息。反过来，全程健康档案服务也能响应来自其他区域卫生信息平台的信息请求。全程健康档案服务是平台系统架构的核心组件。该服务负责实现平台互联互通性规范，还可能使用由区域卫生信息平台内提供的组件和服务同其他区域卫生信息平台互动来完成某一项事务。
在某种意义上，全程健康档案服务是区域卫生信息平台的核心。通常，数据更新事务可能需要或不需要使用全程健康档案服务，许多数据更新事务希望能直接分派到特定的注册目录、健康档案存储服务。这样的数据更新事务例子包括：处方药品域系统传来的新药品的调配事件，或者来自实验室检验机构的应用系统发送给区域卫生信息平台的新检验结果，或者来自医院的PACS应用系统发送给区域卫生信息平台的诊断成像结果集。
另一方面，所有到区域卫生信息平台中访问数据的事务希望由全程健康档案服务进行处理。全程健康档案服务是区域卫生信息平台中唯一一个知晓所有的事务和业务逻辑以及数据访问规则的部件，所以它可以围绕任何数据主题汇集出真正的全程和综合的健康档案视图。
（一）索引服务
索引服务全面掌握区域卫生信息平台所有关于居民的健康信息事件，包括居民何时、何地、接受过何种医疗卫生服务，并产生了哪些文档。索引服务主要记录两大类的信息，一是医疗卫生事件信息，另一为文档目录信息。
区域卫生信息平台用户在被授权的情况下，可以通过全程健康档案服务提供的索引服务从基本业务系统查看某居民的健康事件信息，以及事件信息所涉及的文档目录及摘要信息。再结合健康档案数据存储服务可以实现文档信息的即时展示，使用户更多的了解居民（患者）既往的健康情况，为本次医疗服务提供相应的辅助参考作用。
（二）业务服务
这个组件由处理健康档案数据访问事务的服务组成。这些服务被组合在一起建立一个以处理和管理这些健康档案访问事务的场景。这是区域卫生信息平台内协调和执行事务的唯一地点，其中需要涉及区域卫生信息平台里的多个服务和系统、或需要访问其他区域卫生信息平台的事件。这一组件中的服务管理着区域卫生信息平台中事务的全局性表示、编排流、响应组装、业务规则应用以及与区域卫生信息平台的各类其他系统或服务的数据访问。业务联动的众多需求则需要本业务服务组件来配合实现。包括的主要服务组件有：
1. 组装服务
一个平台互联互通规范的执行可能包括调用不同的组件生成多个结果集。组装服务将把这些结果集一起组合成一定输出格式。这些服务将使用组合模板的方式来实现这些功能.
2. 编排服务
这些服务管理注册、存储和提取，更重要的是各类处理流程的编排协同。编排服务是驱动事务执行的引擎。它知道服务产生的步骤，知道怎样为了触发和管理每一步并行或串行实现而调用服务。
3. 业务规则服务
业务规则服务组件是由细颗粒的验证和逻辑处理规则对象的采集器，它在运行期间进行组合以执行适用于正在被处理的特定类型的平台互联互通性事务的业务逻辑。这些业务规则可以被硬编码（指作为程序代码）进入域业务组件或者可以通过业务规则服务动态的使用。
4. 标准化服务
这些服务是在平台互联互通性执行的语境中被调用以转换成不同形式下描述的数据。典型地，这个服务常用于应用标准，把特定的输入串修改成符合标准化基础的编码串。数据的格式和实质含义都可以转换。特殊的逻辑和编码表常用于完成这种转化。
5. 数据质量服务
用于跟踪和监控区域卫生信息平台里的数据质量。因为区域卫生信息平台的数据是用于研究、监测和进行临床决策的，跟踪区域卫生信息平台内部信息质量水平的能力是一个必须的特性。这些服务能用于支持人工数据质量评估处理，将来甚至发展到完全自动的数据质量指标评估。例如：某些指标可以从监控应用业务逻辑算法的结果中得到。
（三）数据服务
这些服务为健康档案业务服务提供功能性的支持，以执行正确的数据访问过程和与不同的注册服务、存储服务、业务管理或辅助决策服务交互所需的转换。通常，全程健康档案服务可以与平台内部组件相互作用。它依赖于基于标准的通信机制，并使用交换层来执行这种相互作用，或者使用更为直接或私有化的接口机制来访问或更新数据到任何一种注册服务、存储服务。数据服务用在两个场景里：记录和获取健康档案数据的在线业务场景，加载和管理健康档案存储库和注册信息的管理功能场景。数据服务所包含的主要服务组件有：
1. 复制服务
在现有的区域卫生信息平台内的系统或数据库之间提供数据复制功能。
2. 数据仓库服务
数据仓库服务管理从不同的存储库中抽取和插入数据，经过抽取、转换和装载等加工处理后，提供生成区域卫生信息平台范围内使用的各种数据分析利用资源。
3. 键值管理服务
当数据访问来自不同数据源时，会出项这样的情况，即某个主索引键或次索引键在源系统间不唯一或不存在。键值管理服务将在健康档案存储库插入和更新操作期间生成和管理这些键值。
4. 数据访问服务
为不同的注册库、电子健康记录系统或辅助服务相关的数据访问过程的正确调用提供支持。它存储着有关数据结构和调用过程的元数据，以在运行I-IPs的语境中或数据维护类型过程中执行存储库的操作。
（四）事务处理
根据对事物的调用和处理，全程健康档案服务将配置成协调处理所有的“列表”和“获取”事务。对于任何这些事务，将建立管理这些事务的语境，将知晓如何调用一个特定的编排流，并指导编排流的执行，允许在实现这些事务时调用适当的服务。典型的调用包括：
1.调用个人、医疗卫生人员和医疗卫生机构注册服务来鉴别每个实体，并且在它们的使用过程中获得区域卫生信息平台内部标识符；
2.通过交换层服务去调用许可、加密、数字签名、访问控制、匿名访问或其他任何服务，这些服务用于对事务的实现施加适当的控制；
3.调用平台定位服务，以确定特定居民的特定事务在不同区域存储服务可能有数据的情况下，需要查询其他哪些区域卫生信息平台；
4.调用存储服务来执行特定平台互联互通规范时访问或获取数据；
5.通过交换层服务将子事务代理调用到存有客户相关数据的其他区域卫生信息平台中；
6.通过交换层服务为正在执行的平台互联互通规范传递一个组合响应。
为了担当处理健康档案数据访问事务的核心，全程健康档案服务必须有能力建立健康档案的完整视图。全程健康档案服务中的索引服务提供这一能力。当全程健康档案服务处理事务时必须依赖索引服务，索引服务可以了解在健康档案里存有哪些数据，并知道这些数据在参与到区域卫生信息平台中的众多系统里的位置。当全程健康档案服务是索引服务所有者时，在索引服务里全程健康档案服务也会提供一套特定的事务来管理、维护和使用索引数据。
集中处理复杂的复合事务时，全程健康档案服务是一个事务处理层，侧重于处理复杂的混合事务，这些事务需要得到一个多域或多平台的信息视图。希望大多数区域卫生信息平台数据访问事务获得这类能力，因为来自于注册服务、访问和同意管理服务、并且常常一个或多个存储服务的数据必须结合在一起才能实现一个请求。本质上，希望到达区域卫生信息平台的更新或“PUT”事件对于单一的域是特定的并被限制在处理该域的一个数据存储服务组件范围内。
五、信息接口服务
信息接口服务包括两大类服务：通信总线服务和平台公共服务。
（一）通信总线服务
通信总线服务支持数据存储服务、业务管理、辅助决策以及与基本业务系统和健康档案浏览器之间的底层通信。主要服务组件包括消息服务和协议服务。
消息服务组件：由处理消息内容的服务所组成，该消息的应用和网络协议的封装已经被协议服务组件所分离。这个组件中的服务包括解析、串行化、加密和解密、编码和解码、转换和路由功能。
协议服务组件：用来处理网络、传输和应用层协议。这些服务支持可热部署模块，以支持各种应用级协议，如Web Services（WS-I）、ebXML、SOAP 和远程调用协议，如RMI、DCOM、.NET等。
（二）平台公共服务
平台公共服务主要是指应用软件系统管理所包含的上下文管理、应用审计、安全管理、隐私保护等服务。
语境管理：语境管理是实现医疗卫生服务机构与区域卫生信息平台之间交互时上下文环境状态的管理，主要提供缓存和会话服务。
缓存服务：这些服务用于管理缓存，并在可被配置设置的基础上提供与缓存响应相关的功能。这些设置可包括生存时间，持久度，缓存循环，基于角色缓存等。
会话管理服务：这些服务管理用户会话。一个用户会话将包含会话ID、功能和角色信息、授权信息、其它信息，该系统可以选择存储这些信息以提供有效的信息访问。
通用服务：这些组件提供审计服务、日志管理和通用错误和异常处理服务：
审计服务：这些服务提供配置信息审计的能力，并为其它服务提供审计支持的接口。审计服务将管理自己的数据源并使用其他服务，如编排、数据服务、日志管理服务、报告等。这些服务用于管理缓存，并在可被配置设置的基础上提供与缓存响应相关的功能。
错误/例外处理服务：这些服务提供了一个接口，以抛出和管理错误及其他业务例外。例外包括系统/应用级例外到发现由损坏或脏数据等导致的例外。错误/例外处理服务将使用日志管理服务来记录出错信息。
日志管理服务：这些服务用来管理应用、系统、安全等日志。各种服务都将产生事件日志。这些事件将根据配置记录在事件日志中。日志可以被保存在平面文件、关系型数据库、系统事件日志库等。其他服务，如警报/通知服务，可以结合日志管理服务，以提供其他增值能力。
集成服务：基础服务主要基于消息代理、映射服务、排队服务和服务目录，提供管理集成功能。
代理服务：这些服务读取结构化的业务信息来理解正在处理的事务类型。基于此，整个事务作为一个单元被代理传递到适当的服务去执行。
映射服务：这些服务帮助创建一个将源文件格式翻译成目标格式的映射文件。这项服务可用于从xml 文件映射到平面文件及其他格式，反之亦然。
排队服务：这些服务提供存储转发能力。他们可以使用消息队列以及其他持久性机制来储存资料。它们可用于异步类型的操作。
服务目录服务：每个由EHR 支持的业务消息注册时使用这项目录服务。这些服务管理服务目录及伴随的服务描述。代理发生器可以利用服务描述创建代理类。
互联互通性：互联互通性组件主要用来处理那些与各种存储库、注册服务交互的搜索/解析功能。该组件还包括提供区域卫生信息平台之间的互联互通性服务，诸如处理与远程区域卫生信息平台相关事务的业务。交换层将使用互联互通性服务触发和管理这些信息平台之间的事务。
互联互通性服务：这些服务用来管理对服务的调用，这些调用从交换层发出，指向区域卫生信息平台内的不同系统（注册、业务管理、电子健康档案服务或辅助决策服务）；或当事务必需向远程区域卫生信息平台发起时。
查询/获取服务：这些服务用来处理与解析服务的交互，类似在居民、医护工作者和机构注册中提供的同类功能。这些服务在使用EHR 定位服务时也将涉及到。
管理服务：该组件提供区域卫生信息平台与交换层的配置管理功能，主要涉及如下几类服务：
配置服务：这些服务用来配置信息平台，包括共享健康档案数据存储库、元数据、服务组件、支持模式、安全、对话和缓存机制等。这些服务提供了这样一个机会，即把影响区域卫生信息平台各独立部分行为参数的配置和管理的机制和过程集中化。
管理服务：这项服务提供了一个通用接口来管理和监控信息平台的各个方面。配置服务处理的是系统级配置，而管理服务处理的是系统的用户配置方面。管理服务还提供监控功能，使得管理员可以跟踪正在进行的健康档案服务的运行性能。
政策管理服务：这项服务管理基于区域卫生管理机构治理政策的政策框架和控制信息平台系统运行的过程。
安全与隐私：安全与隐私服务提供了保护患者隐私和各区域卫生管理机构实施安全与隐私政策所需的功能。
匿名化服务：这些服务保护患者的隐私和安全，确保在信息平台中以及提供正常医疗服务以外的（例如医疗保险、管理、以及某种形式的研究）传递中使用的患者资料不向非授权用户透露患者的身份。
许可指令管理服务：许可指令管理服务转换由立法、政策和个人特定许可指令带来的隐私要求，并将这些需求应用到区域卫生信息平台环境中。在提供访问健康档案或经过区域卫生信息平台传输健康档案之前，这些服务应用于健康档案以确定患者或个人的许可指令是否允许或限制健康档案的公开。这些服务还允许信息平台用户管理患者/居民的特定许可指示，例如根据法律法规的需要和允许，阻止和屏蔽某一医疗服务提供者访问健康档案或者在紧急治疗情况下不经许可直接开放健康档案。
身份保护服务：这项服务将一个患者或居民的身份解释为一个健康档案标识符。患者或客户通常由一个如社保卡号码的通用标识码来标识，这样的卡号关联到每个包含健康档案标识域中的健康档案标识符。健康档案标识符是一个受保护信息，只有交换层之上平台系统才能知道。
数字签名服务：数字签名由医疗卫生应用程序的用户创建，以确保临床数据的不可否认性，这样的临床数据如：数据文件、报告、记录中的字段域、安全声明、XML文档，包括被转换为XML文档的HL7消息或对象中的元素。这项服务在生成签名之前先验证数字证书没有被撤销。
加密服务包括：（1）密钥管理服务：创建和管理数据存储的加密密钥；（2）数据库加密服务：加密和解密数据库表中的数据字段（列）和记录（行）以保护健康档案以及信息平台中处于使用状态的其它保密的关键系统数据；（3）数据存储加密服务：加密和解密文件和其它数据块，用于保护在联机存储、备份或长期归档中的数据。
一般性安全服务包括：（1）扫描恶意程序，保护免受侵害；（2）安全备份/恢复数据；（3）资料归档；（4）数据安全销毁。
身份管理服务：这些是面向更高层次服务提供的基础服务，例如用户注册、认证、授权，其中包括用户的唯一标识、查找用户的标识，挂起/取消用户访问权。
访问控制服务：这些服务确定对信息平台应用功能的基于角色的访问权限。这些服务还提供配置和管理用户及角色访问功能和数据的授权。
安全审计服务：这些服务提供对每个事务所涉及到的系统、用户、医护工作者、患者/居民、健康数据等等的报告功能。这些服务对于满足其他业务需求，如系统管理、事务监控、记录重要的与隐私和安全有关的事件等，也是至关重要的。
用户认证服务：这项服务验证用户的身份。这项服务是在执行医疗卫生应用与区域卫生信息平台之间的事务的场景下被调用，以验证参与事务用户的合法性。
订阅服务：订阅服务提供预订事件和管理警报及通知的功能。
警报/通知服务：警报是用户能指定控制系统或代理行为的参数。当到达警报条件，服务会通知用户。这项服务工作时与下面描述的发布/订阅服务关系非常密切。一个警报例子可以为：“如果血液测试结果超出正常范围，请提示我”。通知服务将发出一个信息，与结果连同其他有关资料发给申请检查医生。
发布/订阅服务：这项服务管理订阅人和发布者。它提供的功能分两个层次。一是在整合层面，按照整合参数所定义的机制为订阅者提供内容。另一种是在一个更高的水平上，用户可以订阅指定内容。当观察到特定的条件或者用户订阅的内容被发布时，信息通知用户。警报和通知由上文所述服务来处理。
六、医疗机构内部信息系统数据交换
医疗机构内部信息系统数据交换主要体现在对医疗机构内部信息系统业务数据的采集、整合以及医疗机构内部信息系统之间业务联动等方面。医疗机构内部信息系统业务数据分布于不同医疗卫生机构的不同信息系统之中，因此数据采集和整合除在信息基础设施（如网络基础设施、服务器等）建设上有保障外，还需建立一个覆盖所有医疗机构数据交换平台，以提供对原有业务数据的采集服务和整合服务，并为机构之间以及业务系统之间的联动提供支持。
通过在医疗卫生机构设置前置机当作与区域平台的接入端代理，来实现辖区内医疗机构与区域平台的互联互通性。前置机作为医疗机构与平台之间的统一的通讯入口和出口，其主要功能包括如下三个方面：
公共基础功能；
信息注册功能；
业务相关功能（包含诊疗和公卫业务）。
（一）公共基础功能
通信传输服务：提供信息传递的功能，为数据传输提供通讯通道。
通用文档展示代理：主要提供代理通用文档的展示服务，所谓代理即在医疗机构内部信息系统数据交换构件中不真正实现通用文档的展示服务，而是调用平台医疗卫生信息共享和协同服务组件中提供的文档展示功能来响应医疗机构内部信息系统层提出的通用文档展示功能需求。
（二）信息注册功能
患者身份注册代理：为医疗机构内部信息系统层提供代理患者身份注册的功能，主要通过患者身份信息的采集、抽取、转换和对平台注册服务构件的软件调用，在平台上完成患者身份的注册。
医疗卫生人员注册代理：为医疗机构内部信息系统层提供代理医疗卫生服务人员注册的功能，主要通过医疗卫生服务人员身份信息的采集、抽取、转换和对平台注册服务构件的软件调用，在平台上完成医疗卫生服务人员的注册。
医疗机构注册代理：为医疗机构内部信息系统层提供代理医疗机构注册的功能，主要通过医疗机构信息的采集、抽取、转换和对平台注册服务构件的软件调用，在平台上完成医疗机构的注册。
（三）业务相关功能
交换共享库：为医疗机构内部信息系统层提供文档交换共享存储库和消息交换共享库，该功能主要是按照互联互通性规范的要求的对医疗机构内部信息系统内部系统中的文档和数据进行采集、抽取、转换并存储到交换共享库中，以便为其它服务使用。
文档注册代理：为医疗机构内部信息系统数据交换构件中交换共享库提供代理诊疗和公卫相关文档注册的功能，主要通过交换共享库中文档元数据的采集、抽取、转换和对平台注册服务构件的软件调用，在平台上完成诊疗和公卫业务文档的注册。
文档展示代理：主要提供代理诊疗和公卫业务文档的展示服务，所谓代理即在医疗机构内部信息系统数据交换构件中不真正实现诊疗和公卫业务文档的展示服务，而是调用平台医疗卫生数据和服务构件中提供的文档展示功能来响应医疗机构内部信息系统层提出的诊疗和公卫业务文档展示功能需求。
互联互通审计追踪：为医疗机构内部信息系统层互联互通提供相关的审计追踪功能，主要体现在权限管理、日志管理、运维管理、行为审核等。
互联互通统计分析：为医疗机构内部信息系统层互联互通提供相关的统计分析功能，主要统计内容包括何人在何时何地做了哪些操作、统计各种类型的业务被医疗卫生人员使用的频率、统计各种业务对医疗机构内部信息系统数据交换构件的资源的利用率等。
工作流控制引擎：为医疗机构内部信息系统层文档和消息流转提供技术和业务上的支撑，有了本功能就可以根据相关的业务规范和规定来制定医疗机构内部信息系统间的业务流转规则，从而可以实现诸如双向转诊、预约会诊、业务协同等各种高级应用。
健康基础信息整合服务：本业务功能主要是针对医疗机构内部信息系统层中与健康档案提供相关的整合服务，从而抽象出健康档案的基础性、概要性的内容，并向共享库提供整合后的健康基础文档。
七、数据仓库
区域卫生平台由多个系统组成，这些系统涵盖了与居民健康相关的所有业务系统，以使辖区内居民拥有完整的健康记录。从所有这些系统中采集活动的、运行中的数据，例如：居民注册、共享的健康记录、实验室检验信息、突发公卫管理等，这些数据最好能采用接近实时的更新方式，并且更为重要的是保持一种快速的数据响应访问。平台中预期的事务规范里面大多数的日常事务是数据访问而不是数据更新，并且随着越来越多的用户意识到并愿意将电子健康档案的使用作为一种工具，将会增长成大量的数据访问事务。
数据仓库主要是对业务数据进行综合统计分析，以辅助进行相关决策。业务统计分析和医疗质量辅助分析均是利用现有数据，实现管理辅助决策，从技术角度这类应用可以基于数据仓库技术来实现。数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，在汇总数据的基础之上，支持数据发掘、多维数据分析等当今尖端技术和传统的查询及表报功能，用于支持管理决策。作为区域卫生信息平台特定的优化读取的性能模型，数据仓库的任务是提供一个独立的平台，数据能被转换成可操作的、可搜索的、可管理的和可获得的，而不影响信息平台系统组件所需的关键性能服务水平。必须支持分析、研究和管理汇集在信息平台内的运行数据相关的价值。
辅助决策利用数据仓库可以为许多不同类型业务做出辅助决策，如：医保/新农合管理辅助决策、临床辅助决策、条线辅助决策和管理辅助决策等。目前，辅助决策除了对以上业务提供支持以外，还可以利用数据仓库平台满足公共卫生监测业务域的需求。公共卫生域需要支持一些处理过程，通过操作研究和分析来发现潜在的传染病爆发或运行其他类型公共卫生程序。
八、健康档案浏览器
健康档案浏览器是为终端用户提供的基于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．业务规则服务
业务规则服务是系统中对具体业务规则进行实现的一类服务组件，它们负责对业务中的逻辑进行处理，通过对数据装载、主键管理、健康档案索引等服务的调用以及对数据中具体指标的判断，执行不同的业务处理。比如说诊断信息的收集中，如果有一定业务要求，需要对某种传染病进行监控，则就在业务规则服务中加载此项服务判断，对此信息进行分段处理。
业务规则服务可以通过两种模型实现，一种是通过标准的过滤服务对其中的一些关键数据域进行抽取后重新启动一个已经被定义业务流程进行处理，另外一种可以在遵循标准接口的前提下，通过硬编码的方式将业务规则注入到系统中。
过滤服务是一种通用的业务规则服务，可以通过配置实现一些简单的数据分离过滤功能，仅仅适用于那些简单的数据过程，对于复杂的逻辑处理都应放在硬编码的业务规则实现上，不宜将过滤服务认为是一个万能服务，通过非常复杂的配置实现某一业务功能。使用硬编码的方式可以实现所有复杂的业务逻辑，硬编码过程中应将尽量通过调用数据装载服务这样的标准组件来实现通用功能，硬编码只做一些逻辑运算为主的工作。
3．索引服务
索引服务是健康档案快速定位目录，通过健康档案索引，能够迅速定位相关的健康信息所在的存储位置，方便数据装载服务能够迅速读取其健康信息。健康档案索引的编目方式主要以时间为维度纵向展开，主要的索引方式为时间和唯一编号，他和健康档案摘要服务共同构成主要查询体系。
健康档案索引的方式是多样的，它独立于健康档案存储存在，在数据进入健康档案存储时即根据制定的一定规则去生成相关的索引。同样的一个数据可能具备多种索引，比如诊断索引，药品索引，健康时间索引等。其不同的索引目的是针对不同的查询能够迅速去定位相关信息，被索引的字段一般为已经能够被确定结构化的信息，如诊断编码、药品编码、健康事件号、健康事件类型等。索引本身仅仅是原数据的关键信息抽取，不作为统计分析使用。也不会因为版本的升级而变化，即使系统建立后仍然可以添加索引，索引系统可以基于健康档案存储数据进行动态的增减。
4．摘要服务
健康档案摘要服务是针对个人健康档案信息的一个概括性快照，它从健康档案信息中抽取关键性指标，生成一个能够描述个人当前健康状况以及主要健康事件的信息文本，包含一定的关键域，客户端能够通过这些关键域同健康档案索引服务关联起来，去定位当前个人健康状况中的关键性问题。健康档案摘要服务提供查找以及生成来两个功能，健康档案摘要的存储是独立健康档案存储的独立系统，客户系统中默认情况，将首先调用该服务去了解个人健康概况，然后再去进一步深入调阅其他信息。
5．健康档案地址服务
在一个区域医疗信息网络中，并非所有的信息都被集中存放在平台中，这些信息可能分布在区域中的一些医疗机构中，也可能分布在另外一个区域医疗信息中。为了解决上述情况的健康信息调运，健康档案地址服务提供每条医疗信息记录的真实存放地址，在数据读取过程中，读取服务会通过健康档案地址服务查询到真实存放地址，地址信息包括：存放服务器地址，存放服务名等信息。这些存放服务器都需要实现统一的基于Web Services的数据存储服务，同时使用非显性认证机制来解决安全问题。数据读取服务可以通过健康档案地址服务直接到远端系统中读取相关数据。如果数据是存放在中心中，可以考虑使用本地服务，快速读取数据。
在存放数据时，存放服务根据上传数据的情况，通过健康档案地址服务插入每条记录的地址信息，以提供将来读取需要。 健康档案地址服务中的地址数据是存放在独立的数据表中，通过外键与健康档案索引联合。针对健康档案索引中的每一条数据，都可以查询到相应存放地址。由于健康档案是通过数据调用服务来使用的，对于系统中的其他服务来说健康档案地址服务是透明的，不需要针对健康档案地址服务进行任何操作。
（五）数据存储服务
健康档案的存储主要分成三种类型，健康档案数据存储（EHR Data Storage）、业务数据存储（Business Data Storage）、数据仓库存储（Data Warehouse）。健康档案的数据存储并不和某一数据库进行绑定，他的存储模式有文件系统存储和数据库存储两种模式。
1．数据元管理服务
数据元管理服务的功能是提供医疗数据的格式定义，管理和激活验证等活动，保证中心中保存的电子健康信息的数据一致性和长期的可用性。为了保证医疗数据的统一完整，每个国家都在制定电子健康信息数据格式。在中国，各个医疗域的医疗数据格式标准正在制定完善中。基于此现状，此平台产品将提供以下功能：
（1）元数据定义工具来导入、创建中国医疗信息数据元数据集标准；
（2）元数据定义的多版本定义功能，支持对数据元数据集的升级；
（3）元数据到XML Schema的映射定义，直接生成XML Schema文件；
（4）元数据定义和XML Schema在Metadata Repository Server上集中保存；
（5）元数据上载、卸载至全程健康档案服务服务；
（6）元数据和电子医疗数据的映射和激活使用。
2．数据装载服务
数据装载服务是从健康档案数据存储中攥取数据以及存储数据的底层数据服务，它负责将业务服务分离出来的实际数据保存入最后的物理存储（数据库或者文件方式存储）中，同时也负责从物理存储中读取数据为各业务提供所需的素材。它对实际读取和存储的内容并不敏感，只负责根据确定的指令进行读取和存储，其作用是隔断业务操作和实际存储中的紧密耦合，使得存储环境的变化不影响到原来的业务操作。ELs是一种逻辑接口服务，它有两类实现组件，一种为File_ELs（文件系统EL服务），一种为DB_ELs（数据库EL服务）。
File_ELs针对文件存储类型的数据进行读取和装载操作，它根据操作的不同分别调用File_Extract Svc（文件攥取服务）和File_Loader Svc（文件装载服务）。File_Extract Svc负责从文件系统中读取已经指定位置的文件，同时将文件的二进制流分装入一个带有文件名称、文件类型、长度等基本信息的XML回应包中，传送回调用方；File_Loader Svc服务则负责将请求包中的文件信息从XML中分离出来，遵照请求包中的位置信息，将文件存储到文件系统中。
DB_ELs针对数据库存储类型的数据进行读取和转载操作，其工作原理和File_ELs类似，只是DB_ELs对象为数据库系统。DB_ELs使用Hibernate进行封装，实现系统和数据库类型无关性。
3．主键管理服务
主键管理服务是负责管理存储中的主键值，它负责生成全系统唯一的编号或是序号，保证系统中某数据具备唯一的标识值，可以被迅速定位和获取。比如健康档案个人唯一码、健康事件唯一编号等。主键管理服务可以通过配置使生成的主键值具有一定的逻辑规则，能够生成二级索引，被更快的定位和跟踪。主键管理服务和数据装载一样，是一个基础的技术组件，并不和具体业务相关。
主键管理服务生成如健康档案个人唯一号，健康事件唯一号等，在健康档案存储中，需要对某些特定的巨大型的表（如用药情况表这些有着几千万条甚至上亿条数据记录的表）进行分表操作，在进行分表时就需通过主键管理服务生成的唯一号生成表头后缀，在业务逻辑中，根据这样的表头后缀可以非常迅速的定位到相应的唯一表，再从分表后的数据中查找相应数据，而通过主键管理服务生成的序号又能动态的去平衡各个分表的存储大小，实现一定意义的负载均衡。
4．健康档案数据存储服务
健康档案数据存储主要存放健康档案相关的原始数据信息，主要是以健康档案未经过进一步加工的数据为主。其主要分为文件存储和数据库中的文档存储两种类型。文档存储按照一定的健康档案信息类型进行分类，实际存储中采用数据库和XML文档混合存储的模式，它并不对健康档案信息中的明细项进行结构化，即使同一类型的数据，其存储的文档格式也可能因为版本的原因具体结构有所区别。
健康档案数据的存储模型以一次健康事件为基本单位，在存储上不对健康事件进行合并和加工。在存储时系统抽取健康事件的类型、健康事件存储时间，发生时间，事件唯一号，以及健康事件的版本信息作为基础索引。
5．数据仓库存储服务
数据仓库由三个部分组成：数据仓库数据库、数据抽取工具和数据挖掘工具。
数据仓库数据库：是整个数据仓库环境的核心，是数据存放的地方和提供对数据检索的支持。相对于操纵型数据库来说其突出的特点是对海量数据的支持和快速的检索技术。
数据抽取工具：把数据从全程健康档案服务存储中拿出来，进行必要的转化、整理，再存放到数据仓库内。数据转换都包括：删除对决策应用没有意义的数据段；转换到统一的数据名称和定义；计算统计和衍生数据；给缺值数据赋给缺省值；把不同的数据定义方式统一。
数据挖掘工具： 数据挖掘工具利用数据仓库中的大量数据获取有效的、新颖的、潜在有用的、最终可理解的模式的过程。
平台的数据仓库模块可通过第三方成熟产品实现，只需要定制数据抽取工具的接口。通过他们读取所需的数据，通过数据抽取工具的整理之后，存入数据仓库数据库。对于数据的分析将直接面向数据仓库数据库中的数据，对中心其他服务的运行没有影响。对于数据的挖掘功能，开发运营人员可以使用成熟产品中数据挖掘工具，制定相应分析模型，通过数据挖掘工具的报表和图形功能来读取结果，或者继续调整模型来得到更准确的结果。
四、运行监控管理
（一）主题管理
在发布订阅模式中，各医疗机构或业务科室可对数据中心中流转的相关业务信息进行订阅，对该部分内容进行主题式的管理，在数据中心将根据业务需要，设置树状分层的主题节点，通过交换平台，当相关机构产生主题消息后，信息自动向主题发布，则订阅该主题的机构或业务科室就可以收到该条消息，如卫生局关心甲类传染病信息，对该主题节点进行订阅，则将来发生任何甲类传染病报告事件，信息都会发布到卫生局应用节点。主题管理包含以下几个部分：
（1）主题维护（对主题进行增加、修改、删除活动）；
（2）主题订阅管理（对机构申请订阅主题进行权限审核）；
（3）主题发布管理（对要发布主题信息的机构或应用系统进行准入管理）；
（4）主题消息负载管理（对各主题内消息流量进行统计分析）。
（二）节点管理
由于数据共享与交换平台是一个复杂的、分布式网络结构，单靠人工进行管理各个传输节点是很困难的一件事。当前的网络系统中都有哪些节点，它们运行状态如何，有哪些是新增加的节点，是否有非法节点加入，这些都是难以解决的问题。
因此，系统必须引入节点管理功能。它通过配置各个节点的参数和属性，构建整个数据交换环境。在监控端，以图形方式显示所有的网络段和节点并自动检测各个节点的状态，使管理人员能够一目了然地发现问题节点。
（三）密钥管理
在数据交换过程中，数据文件发送和接收双方都需要对对方的密钥进行认证，以保证数据的防抵赖、防否认和防篡改。安全、周密、有效的对密钥进行管理是数据交换安全设计的一个重要方面，通过对各种密钥进行管理，能够确保整个数据交换系统的安全。
（四）日志审计
为了更好的使系统管理人员了解和掌握系统的运行和使用情况，我们基于日志管理，通过对特定事件的定义和对各类系统检测数据阀值的设定，达到监控系统运行状态的目的。日志记录日常用户使用的情况，跟踪每一笔数据交换过程后进行的所有操作。如操作流水号、院区、系统名称、发送时间、接收时间、模块名称等，用以提高系统的安全性，跟踪非法操作与越权操作，统计接口的执行频度。日志审计反映了每个服务的生命周期的痕迹。它记录了从消息代理、服务解析，到服务排队、服务路由每个检查点的状态。并通过预先设定阈值，检查服务的即时状态，来判断服务有效性。此外，因为数据交换平台第三方地位的特殊性，日志服务可作为不同系统之间交换发生故障时的凭据，可作为来诊断发生的问题以及设计处理的仲裁者。
（五）数据备份与恢复
数据交换平台的中心共享性数据（如病人基本信息、健康档案）处于非常重要的位置，确保数据中心数据的安全是系统必备的功能。通过数据备份和恢复管理，根据设定的数据备份策略，定期备份指定范围的数据，可以在需要的时候将备份的数据恢复。并且能够通过设定，利用系统提供的自动通知功能，提醒系统管理人员备份数据。
五、平台配置管理
（一）用户管理
通过机构/用户管理可以规范用户对集成平台的使用行为，可以根据用户的组织机构设置相应的用户组和对应的用户。用户管理应该能够对用户进行全面的管理，包括用户组的增加、修改和删除；用户的增加、修改和删除；用户与用户组之间的对应；以及其余角色的权限管理安全可靠的密码管理功能。
（二）权限管理
在数据共享交换平台中权限管理至关重要，不同的用户具有不同的权限，使用不同的信息路由路径，对各应用节点的接口调用进行身份验证。这样保证了系统的安全性、可靠性和稳定性。系统应从不同的角度进行相应的权限管理，功能权限指对接入平台的各个应用以及功能服务的访问权限；数据集权限即数据项权限，是指用户对传输中的信息各数据项的访问权限；管理范围及记录权限，是作为共享数据信息内容的访问权限。当用户所具有的信息，符合通过管理范围设定出的特殊匹配条件时，允许用户访问相应管理范围所规定信息内容；权限方案允许用户导出和导入。便于权限管理信息的分发和设定；用户还可对自己相应的权限信息进行打印。
（三）系统配置
由于数据共享与交换平台是一个复杂、庞大的系统。软件系统需要不断地维护和更新，如果每修改一次都需要到用户终端进行一次程序更新，系统的维护的工作量是无法想象的，为了解决这一矛盾，系统对各接口组件实行智能维护，提供功能服务组件版本自动更新功能、系统参数设置功能和提供个性化服务功能等。对于数据集和流程定义配置文件的更新，也应通过分发机制保证各节点的统一性。
六、技术方案选型
（一）数据交换技术选型
产品比较项目
接口模式
总线模式
开发难度
网状，复杂，技术不统一
总线，技术统一
但前期有技术培训成本
维护成本
Win32操作系统
35种主流操作系统
开发API支持
牵一发而动全身（耦合高）
各自为政，互不影响（耦合低）
标准化
低
对开发人员要求高，需掌握其他系统技术或数据库细节
高
对开发人员要求低，只需满足集成平台标准即可
性能
不稳定
数据库争抢，死锁
稳定
消息队列技术、服务组件池
安全
无法控制
统一日志，统一监控，统一管理
实施
结构复杂，实施难度大
即插即用，支持热部署
（二）消息中间件技术选型
产品比较项目
Microsoft
BizTalk/MSMQ
IBM
Webshpere MQ
TIBCO
稳定性、可靠性
可靠性较好
可靠性高
可靠性高
操作系统支持
Win32操作系统
35种主流操作系统
主流操作系统
开发API支持
VC，VB
C＋＋，JAVA
C＋＋，JAVA
配套产品支持
BizTalk，MS .NET
一整套专致与企业级消息整合的产品WBI系列
专业与应用集成
负载均衡能力支持
支持
支持
支持
成熟性
Win32系统有一定应用认同
全球范围内广泛认同
全球范围内广泛认同
消息通道支持方式
MessageQueue
Queue
Subject
点对点通讯支持
支持
支持
分布式Subject支持
发布订阅支持
不支持
支持
支持Subject
消息工作流
无
通过WBI支持，强大的工作流可视化编辑
无
XML与工作流支持
支持
支持
支持
价格
与操作系统集成
按接入点购买，较高
按解决方案购买，较高
第三节 数据存储技术方案
一、数据存储结构
根据对健康档案信息架构的分析及对开放式电子健康档案的定义，我们将健康档案的设计模型归纳为个人主索引、健康档案索引、健康档案数据三个层次，健康档案索引好比信息架构模型中的文件夹，能够用来构建多维的健康档案模型，健康档案数据好比信息架构模型中的文件，每个文件都是由众多的各种条目和数据元构成的，这些组成关系均可通过XML进行定义成不同版本的标准模板。为了保证对健康档案的快速检索和定位，还保存定义健康档案的摘要信息和地址信息（即文件定位器），整个健康档案的计算机技术结构如下图所示：
图5-2 健康档案存储技术结构图（略）
区域卫生信息平台的数据中心还应用该存储各种标准数据和注册数据，以满足平台运行的需要。同时为了区域卫生管理需要还需要建立各种数据仓库。因此根据以上分析，整个基于健康档案的区域卫生信息平台数据中心应该包括的数据内容及相应的存储模式如下表：
数据类型
存储模式
MPI
关系数据库Table
EHR索引
关系数据库Table
健康档案摘要
关系数据库Table
健康档案地址
XML
健康档案实体
XML，文件，文档（包括XML，HTML，DICOM，PDF，DOC，…….）
标准数据
关系数据库Table，XML
注册数据
关系数据库Table
数据仓库
关系数据库
（一）标准数据
标准数据是区域卫生信息平台运行的数据基础。标准数据包括区域卫生业务数据的所有数据标准规范，通过这个库和数据校验机制对数据中心的数据进行标准化保障，主要的数据标准包括整个定义电子健康档案的数据集和数据元（具体可参考卫生部发布的中国健康档案数据标准），还有各种代码标准。由于数据标准存在着时效性，因此针对有时效性的数据进行版本控制，不同的版本有各自的生命周期，不同生命周期中的业务数据对应不同版本的数据。
（二）注册数据
1．个人注册数据
个人注册数据即个人主索引MPI（Mask Patient Index），是指在特定域范围内，用以标识该域内每个病人实例并保持其唯一性的编码。病人唯一标识是指用于临床实际业务并且能够辅助进行病人信息唯一性识别，在该域或跨域各涉众均可见的病人唯一编码。病人主索引服务是指为保持在多域或跨域中用以标识病人实例所涉及的所有域中病人实例的唯一性，所提供的一种跨域的系统服务。各地可采用社保卡（市民卡）加补充的健康卡来进行唯一标识的加载与识别。
2．医师注册数据
医师注册数据包括区域内需要访问区域卫生信息平台医生资料。包括医生的基本信息，医师等级，业务权限，数字证书等内容。
3．机构注册数据
机构注册数据包括区域内连接到区域卫生信息平台的全部医疗卫生机构资料。包括机构的基本信息，机构等级，业务权限，数字证书等内容。
4．医学术语注册数据
医学术语注册数据主要是各种定义健康档案需要的各种标准的统一的医学术语，其是健康档案某数据元的元数据。
（三）健康档案索引
健康档案索引服务是健康档案快速定位目录，通过健康档案索引，能够迅速定位相关的健康信息所在的存储位置，方便ELs能够迅速读取其健康信息。健康档案索引的编目方式主要以时间为维度纵向展开，主要的索引方式为时间和唯一编号，它和健康档案摘要服务共同构成健康档案的主要查询体系。健康档案索引的方式是多样的，它独立于健康档案存储存在，在数据进入健康档案存储时即根据制定的一定规则去生成相关的索引。同样的一个数据可能具备多种索引，比如诊断索引，药品索引，健康事件索引等。其不同的索引目的是针对不同的查询能够迅速去定位相关信息，被索引的字段一般为已经能够被确定结构化的信息，如诊断编码、药品编码、健康事件号、健康事件类型等。索引本身仅仅是原数据的关键信息抽取，不作为统计分析使用。也不会因为版本的升级而变化，即使系统建立后仍然可以添加索引，索引系统可以基于健康档案实体动态的增减。健康档案索引目前分为健康事件索引集、健康业务索引集。
健康事件索引集：健康事件索引集主要根据健康事件类型、所处生命周期、发生时间进行索引，通过对健康事件的分类跟踪，追踪生命周期中关键健康信息。理论上所有的上传个人信息记录都将在此索引中都将有其记录索引，此索引本身以时间方式组织，和具体的业务流程和关联无关，生命周期阶段：新生儿期、婴儿期、幼儿期、学龄前期、学龄期、青春期、青年期、中年期、老年期。
健康业务索引集：根据不同的业务类型对健康事件进行组合形成索引表，其组织形式和具体发生的业务相关。业务索引为扩展索引，可以根据业务的变化和扩大而发生相应变化。业务索引和健康事件并不是一一对应的，统一健康事情可能被多个索引同时引用，也不是所有的健康事件都一定要归到某一业务索引上，比如某次检查无法和门诊或住院挂钩，则此检查就在检查索引中存在即可，并不需要强制挂到某个医疗过程中。
（四）健康档案摘要
健康档案摘要服务是针对健康档案的一个概括性快照，它从健康档案信息中抽取关键性指标，生成一个能够描述个人当前健康状况以及主要健康事件的信息文本，他包含一定的关键域，客户端能够通过这些关键域同健康档案索引服务关联起来，去定位当前个人健康状况中的关键性问题。健康档案摘要服务提供查找以及生成两个功能，健康档案摘要的存储是独立健康档案存储的独立系统，客户系统中默认情况，将首先调用该服务去了解个人健康概况，然后再去进一步深入调阅其他信息。
（五）健康档案地址
在一个区域医疗信息网络中，并非所有的信息都被集中存放在健康档案数据中心中，这些信息可能分布在区域中的一些医疗机构中，也可能分布在另外一个区域医疗信息中。为了解决上述情况的健康信息调运，健康档案地址服务提供每条医疗信息记录的真实存放地址，在数据读取过程中，读取服务会通过健康档案地址服务查询到真实存放地址，地址信息包括：存放服务器地址，存放服务名等信息。这些存放服务器都需要实现统一的基于Web Services的数据存储服务，同时使用非显性认证机制来解决安全问题。数据读取服务可以通过健康档案地址服务直接到远端系统中读取相关数据。如果数据是存放在中心，可以考虑使用本地服务，快速读取数据。在存放数据时，存放服务根据上传数据的情况，通过健康档案地址服务插入每条记录的地址信息，以提供将来读取需要。 健康档案地址服务中的地址数据是存放在独立的数据表中，通过外键与健康档案索引联合。针对健康档案索引中的每一条数据，都可以查询到相应存放地址。由于健康档案是通过数据调用服务来使用的，对于系统中的其他服务来说健康档案地址服务是透明的，不需要针对健康档案地址服务进行任何操作。
（六）健康档案数据
健康档案数据存储主要存放健康档案相关的原始实体数据信息，主要是以健康档案未经过进一步加工的数据为主。实体的主要表现形式为文件存储和数据库中的文档存储两种类型。文档存储按照一定的健康档案信息类型进行分类，实际存储中采用数据库和XML文档混合存储的模式，它并不对健康档案信息中的明细项进行结构化，即使同一类型的数据，其存储的文档格式也可能因为版本的原因具体结构有所区别。健康档案数据的存储模型以一次健康事件为基本单位，在存储上不对健康事件进行合并和加工。在存储时系统抽取健康事件的类型、健康事件存储时间，发生时间，事件唯一号，以及健康事件的版本信息作为基础索引。
（七）数据仓库
数据仓库是为了区域卫生管理建立的数据库，其用来对区域卫生业务进行统计分析、业务监督、绩效考核、应急指挥及决策支持等。其是通过从健康档案数据和各医疗卫生机构信息系统的业务数据中抽取归纳出来的，主要包括卫生资源数据库和主题数据库。
卫生资源数据库主要通过卫生统计途径获得，包括区域的人口构成、面积等本底数据，区域内医疗机构的信息，在册医生、护士、医疗技术人员相关信息，各种医疗设备、医疗设施，医学情报、数字图书馆等知识资源，以及配合电子地图系统的区域地理信息等。卫生资源数据主要通过采集方式获得并共享给各个系统使用，采集方式可以分为自动采集和手工采集两种，已经存在信息系统或者很方便构建信息系统的相关资源数据通过自动方式采集，对于无法通过自动方式获得的信息通过手工录入方式维护到数据中心。相关已经存在的系统包括卫生部卫生统计系统，医疗机构注册管理系统，执业医生、护士系统，外部采购医学情报、数字图书馆（包括自编辑内容）、电子地图等。
主题数据库是配合公共卫生系统和应急指挥系统以及决策分析的需要，数据仓库的方式根据不同的卫生主题组织主题数据库。主题数据库的内容按照主题数据集的要求从各个业务系统的表单型数据中清洗后获得。
二、技术方案选型
（一）存储方式选型
产品比较项目
优点
缺点
文件存储
针对读写直接操作，节省多余开销，能够针对文件结构做专门优化，获得更高的读写性能效果
维护复杂，开发成本高，不利于统计和查询
数据库存储
主流数据库都支持，已经支持XML结构的数据存储，统计查询方便，维护成本低，技术成熟稳定
需要更多的额外开销处理实体的读写
混合存储
可针对专门的读写进行优化，既保留文件存储的高性能，又能保留数据库存储的方便查询
开发成本高，业务分析复杂
（一）平台数据库选型
比较项目
Oracle
IBM DB2
Sybase ASE
开放性
能在所有主流平台上运行（包括 windows）。完全支持所有的工业标准。采用完全开放策略。可以使客户选择最适合的解决方案。对开发商全力支持。
支持从PC到UNIX，从中小型机到大型机；从IBM到非IBM（HP及SUN等UNIX系统）各种操作系统平台。总体来说，在IBM平台上性能表现要比其它平台要好，因此对IBM平台存在一定的依赖性。
能在所有主流平台上运行（包括 windows）。 但由于早期Sybase与OS集成度不高，因此VERSION 11.9.2以下版本需要较多OS和DB级补丁。在多平台的混合环境中，会有一定问题。
高可用性、稳定性与可靠性
采用多进程多线索体系结构，确保高并发访问的稳定性；支持对称紧耦合SMP、集群Cluster以及海量并行处理MPP等新型的硬件体系结构；Oracle数据库10g提供了人为错误修正技术（Flashback）；提供Oracle Data Guard，为维护备用系统提供监控、告警和控制功能，从而减少了计划停机；提供对数据库的一致性作持续检查的机制。
采用多进程多线索体系结构，确保高并发访问的稳定性；可以为每个备用数据库定制作业，提供HADR技术，实现故障快速自动切换，实现自动客户端重新路由连接，确保系统持续可用。
采用多进程多线索体系结构，确保高并发访问的稳定性；对数据库的一致性作持续检查的机制有所欠缺，为了检测数据库一致性问题需要运行DBCC。在DBCC操作过程中，数据库必须保持脱机状态。
可伸缩性、并行性
支持当前扩展能力最强的64 位对称多处理（SMP）系统和非统一存储器访问（NUMA）系统；支持大规模并行处理（MPP）系统；Oracle 真正应用集群（RAC）可以动态添加或删除数据库实例；支持分区间的并行处理
采用ESE（以前称EEE）设计的MPP 平台，支持散列分区技术；具有很好的并行性。DB2把数据库管据库的一部分，包含自己的数据、索引、或数据库节点。
采用页级封锁机制来解决读/写冲突，支持数据页锁，数据行锁，所有页锁，从而提高并发性。能够在SMP系统中配置生成多个引擎，甚至允许在所有引擎之间进行分布式的客户连接。引擎也处理自己的磁盘访问，对增加的用户数提供了近似线性的伸缩性。
性能（OLTP、OLAP）
性能最高， 保持开放平台下的TPC-D和TPC-C的世界记录
性能较高适用于数据仓库和在线事务处理
在大型数据库环境下，性能相对欠缺
安全性
达到C2级安全认证，提供“虚拟专用数据库”（Virtual Private Database）和“标签安全”（Label Security）的功能。
达到C2级安全认证
达到C2级安全认证
兼容性
具有25年长时间的开发经验，完全向下兼容，得到广泛的应用。
在巨型企业得到广泛的应用，向下兼容性好。风险小。
向下兼容， 但是后来引入的应用程 序接口（API） CT- Lib与以前版本（DB-Lib）不兼容，ct-library 程序不易移植。
标准的支持
支持所有的相关标准。 Oracle数据库开放的标准的体系结构使能够支持自身及其他数据源与第三方厂家的工具及应用的集成。
支持所有的相关标准。
支持所有的相关标准。
超大型（TB级）数据库的支持
Oracle数据库10g的最大数据库尺寸为8艾字节（1018字节），可以存储检索最高128 TB 的LOB
DB2 UDB的最大尺寸为8太字节（1012字节）
最大尺寸为4太字节（1012字节）
数据复制、备份及恢复能力
具有联机和脱机备份、增量备份与恢复功能，支持分割镜像备份，支持块级介质备份、恢复功能，提供脚本化备份恢复管理工具，提供数据库实时异步复制功能。
支持实时异步数据表、事务日志复制，具有联机和脱机备份、增量备份与恢复功能。
内构了一个备份服务器（Backup Server）以实现数据库的联机备份，但由于与其他用户 共享进程，在一定程度上影响了其他用户的工作效率。
数据仓库支持
提供包括提取、转换和装载（ETL），在线分析处理（OLAP）和数据挖掘等工具。支持同时访问ROLAP和MOLAP 数据源。
支持数据仓库建模和元数据管理，支持数据抽取、转换、装载和调度。支持“维”的定义和数据装载。
支持数据仓库的建模、数据抽取与转换、数据存储与管理、元数据管理以及可视化数据分析等工具。
客户端支持及应用模式支持
支持ODBC、JDBC、OCI等协议连接，支持J2EE和.NET架构开发，数据库内嵌jvm支持，支持java存储过程。
支持ODBC、JDBC等协议连接，支持J2EE和.NET架构开发，数据库内嵌jvm支持，支持java存储过程。
支持ODBC、JDBC、Ct-library等协议连接，支持J2EE和.NET架构开发，数据库内嵌jvm支持，支持java存储过程。
部署管理简便性
提供基于命令行、gui、web browser等多种管理模式，灵活方便，支持网格控制管理，支持脚本管理。
提供基于命令行、gui、web browser等多种管理模式，灵活方便，支持脚本管理，提供了通用和集成的成套工具，用于管理跨越不同软件和客户机硬件平台的本地及远程数据库。
提供基于命令行、gui等多种管理模式，但GUI较差，支持脚本管理。
SMP支持及集群体系架构
支持当前扩展能力最强的64 位对称多处理（SMP）系统和非统一存储器访问（NUMA）系统；Oracle 真正应用集群（RAC）可以动态添加或删除数据库实例，具有良好的伸缩性且无需停机。
支持当前扩展能力最强的64 位对称多处理（SMP），采用IBM HACMP技术实现集群架构，支持动态添加或删除数据库实例。
可以和多个厂家的硬件/操作系统协同工作：
Sun - Sun Cluster
IBM - HACMP
HP - ServiceGuard
Compaq - TruCluster
Windows NT - MSCS
投资保护
可在所有主要的操作系统上运行，而且在不同的操作系统环境下具有相同的功能，因为Oracle采用单一代码库。即使转换操作系统，应用依然可以正常运行，有力地保护应用投资。Oracle 真正应用集群（RAC）可以动态添加或删除数据库实例，可以方便地把以前的主机加入到集群系统中提高系统处理能力，有力地保护以前的硬件投资。
支持从PC到UNIX，从中小型机到大型机；支持异构硬件平台的集群，但主要是在IBM平台上性能表现优秀，因此对IBM平台存在一定的依赖性。
能在所有主流平台上运行（包括 windows）。 但由于早期Sybase与OS集成度不高，因此VERSION 11.9.2以下版本需要较多OS和DB级补丁。在多平台的混合环境中，会有一定问题。
技术支持
提供7X24技术支持服务，有完备的技术认证体系。
提供7X24技术支持服务，有完备的技术认证体系。
提供7X24技术支持服务。
用户群
广泛
主要集中在巨型企业用户
集中在中小型企业用户
第四节 数据展示技术方案
一、健康档案浏览器
区域卫生信息平台可能需要为一个医疗卫生人员提供不同医疗卫生域的服务，需要支持不同类型数据的显示方式，比如说HTML页面，图片或扫描文档。EHR的通用的需求包括：
（1）健康档案浏览器的显示窗口可以被嵌入Windows平台的应用程序。
（2）健康档案浏览器可以引用所被嵌入的应用程序的验证机制，直接通过Provider Registry的映射完成验证。
（3）健康档案浏览器的认证和Consent是直接通过中心的服务完成，与所嵌入的应用程序的配置无关。
（4）健康档案浏览器可以引用所被嵌入的应用程序的当前病人信息，通过Client Registry读取相关记录。
（5）可以通过区域卫生信息平台来搜索、访问病人的全面的医疗记录。
（6）健康档案浏览器可以对病人医疗记录进行重新排序、归类等工作，但不能直接更新医疗记录。
（7）所有调阅信息是通过中心的服务得到，不能直接调阅所嵌入的应用程序的本地数据。
健康档案浏览器的实现直接是通过一个Windows平台的IE控件实现。在启动时，用户的认证信息和所调阅病人的信息等都是通过HTTP Metadata的方式传送至中心服务器。中心服务器将协调View的HTTP调用到中心所对应的Web Service服务。
对于健康档案浏览器中浏览信息的流转都将通过标准HTML/Javascript来实现，对于扫描文档等非HTML信息的显示也是通过标准HTML MIME控件的嵌入显示方式。由于目标客户机内所附带的IE控件的版本的不同，健康档案浏览器应兼容IE 5.0到8.0的IE版本。由于健康档案浏览器所显示的数据都来自服务器，相应的授权、日志和认证等功能全部在中心端实现，对于客户端的健康档案浏览器完全透明。
二、技术方案选型
健康档案浏览器的设计面向终端用户，以人读为主要目标，应用获取数据可通过交换平台进行，而不是通过健康档案浏览器，但可考虑提供本地化功能（另存为PDF/DOC），可通过浏览器控件方式嵌入到其他C/S系统。整体页面框架应具备Portal模式，具备动态扩展特性，以适应实体索引字段的变化以及实体模板的变化；能完成身份验证、显示内容控制等权限控制；通过集成ActiveX方式实现DICOM等其他协议的支持。健康档案浏览器的实现涉及总页面框架展现，索引列表模板展现，表单模板展现，图表模板展现等几个方面的技术方案。
（一）总页面框架设计实现
健康档案浏览器总体框架符合门户模式，能适应显示内容的动态变化；
支持数据的Grid，Form，Chart等不同方式的显示；
各显示模块允许简单的人机交互查询（条件查询，双击记录显示、图表简单攥取功能）；
能拖拽门户模块，并能定义显示位置，可为不同病人提供不同的视图模式。
（二）索引列表模块技术实现
图5-3 索引列表模块技术实现图（略）
GRID列表显示模块负责针对实体索引信息的显示（实体数据库索引字段部分），假定前提条件为，实体索引字段都已标准化（字段类型，长度，引用字典）；
通过实体索引字段定义配置文件来支持Grid表头与索引字段的扩展，能自适应实体索引字段变化后列表组件的正常显示；
能定义可查询字段，列表组件支持自动查询条件输入以及分页等显示功能。
可采用的技术
优点
缺点
EXT AJAX
大量现成组件，美观的界面风格。
由于库文件较大加载速度慢，对浏览器版本比较严格。
纯HTML
不受框架约束，开发灵活，速度快。
对开发人员美工、DHTML基础要求高。
FLEX技术
基于Flash技术，对浏览器要求低，能够开发出效果多样。
商业化程度低，组件少，技术较新涉及培训成本较高。
（三）表单模板模块设计
图5-4 表单显示组件图（略）
表单显示组件负责针对实体XML信息的显示（实体XML部分）；
同一实体显示模板支持版本管理，通过实体显示模板定义配置文件来支持同一实体不同记录能有不同的显示方式（假定条件为实体索引表应保存对应模版版本字段，建议实体XML头信息里也应保存模板版本属性）；
初期设计支持3种模板实现：XSLT，Freemarker，自定义JAVACLASS；
通过HTML信息里包含ActiveX控件信息实现对DICOM等其他协议的支持。
可采用的技术
优点
缺点
XSLT
W3C标准，各种开发语言都有支持，和XML结构匹配度高。
性能一般，内存使用大，学习曲线高。
Freemarker

快速，效率高，容易学习。
比JSP和静态页面稍慢。
JSF
J2EE主流厂商支持较好。
速度慢，开发困难。
JSP
快速，容易学习。
非框架模板，后期开发维护工作量大。
（四）图表列表模版技术实现
图5-5 图表列表模版技术实现图（略）
CHART显示组件负责针对同一病人相关专题统计信息的图表显示，假定前提条件为eHR View所支持的病人相关专题统计已预先定义；
CHART支持模板方式扩展病人统计专题图表显示，每一种专题统计对应一个ChartID，在模板里定义获取该Chart数据所需要的参数列表以及获取方式、图表显示类型和样式信息等。
CHART数据的获取方式有两种：
（1）一种为直接在模板里定义相关需要获取数据的实体表或视图源，以及需要统计的字段，聚合函数等信息，系统直接根据这些定义来从数据库获取数据。
（2）通过定义获取数据的JAVACLASS来实现该类专题统计数据的获取。
某一种专题图针对某病人的图标模板实例（包含获取数据和模板定义），应能进行缓存处理（内存缓存或持久化），可通过定时或手动的方式刷新缓存图表信息。
可采用的技术
优点
缺点
jFreeChart
后台生成图片方式，交互性差
ActiveX
需下载控件，非IE不支持
Flash Chart
基于Flash的图标工具，大多数浏览器默认安装
第五节 硬件网络支撑平台
一、网络总体结构
基于健康档案的区域卫生信息平台网络基础设施平台由内、外两大网络部分组成。外部网络对外收集和提供信息（向下级部门采集与提供信息，向上级数据中心报送信息），内部网进行信息管理和系统开发，两网之间用防火墙分隔。外部对内部网络的访问则需要通过地址映射，身份查询等一系列安全检查机制才能进行，访问策略的制定是灵活的，可根据具体情况随机配置。内部网络再分子网，依据功能、性质划分，子网间的访问也是受控的。外部网络的安全性主要依靠“虚拟专用网”的功能和路由器上的访问控制表来保障。
对于实时多媒体应用本着中央控制的原则对有条件的用户开放，运维管理中心应具备监视和控制的手段，避免网络拥塞和信息流的非必要的重复性传输。整个平台应采用先进的网络管理和网络安全措施与策略，网络管理及安全策略应从系统管理的角度出发，实现网络、应用系统、数据库与主机系统以及安全防护措施和策略的一体化管理，选择适当的防火墙和数据加密技术。
图5-6 网络总体结构图（略）
二、硬件平台要求
网络基础设施平台的硬件系统一般包括：数据库服务器、备份服务器、应用服务器等；交换机、路由器、防火墙、VPN等网络设备；存储设备如磁盘阵列、磁带库等。网络基础设施平台的硬件系统配置，应根据当地实际业务需求、网络覆盖范围和规模以及经济条件，本着经济、实用、高效和分步实施的原则，选择适当的建设方案。本指南书按初级、中级、高级分别列出网络基础设施平台硬件系统配置的三种建议方案。
（一）初级配置方案
初级配置方案包括建立一个较规范的、安全的市级网络基础设施平台所必需的各项基本设备设施，包括：数据库服务器、应用服务器；交换机、路由器、防火墙、VPN设备；磁盘阵列等。
1．适用条件
（1）康档案的区域卫生信息平台建设的初期阶段；
（2）数量在100万以下的市级或区县级区域卫生信息平台；
（3）医疗机构数和业务系统数比较少的区域卫生信息平台。
2．性能要求
（1）服务器：
高性能PC服务器，各服务器均独立配置；
要求1～2个处理器、4GB以上内存。
（2）磁盘阵列：
磁盘阵列系统1套；
按区域数据估算存储容量；
支持分区、快照、克隆等基本功能；
支持在线扩容，无须停机。
（3）交换机、路由器：
企业级路由式核心交换机。
（4）防火墙、VPN设备：
企业级硬件防火墙，具备VPN功能。
（5）网络防病毒系统：
针对运行Windows系统的服务器、数据库系统进行网络防病毒监控；
对连接到专网的各接入点前置服务器的网络病毒防范；
要求采用中央集中控制和管理。
图5-7 初级配置方案网络基础设施平台图（略）
（二）中级配置方案
中级配置方案是在初级配置方案基础上，通过增加关键服务器系统的双机热备或集群模式，强化了服务器系统的运行稳定性和可靠性。并增加了离线备份系统，加强数据安全保障。此外还提升了磁盘阵列、VPN设备等系统性能指标。
1．适用条件：
基于健康档案的区域卫生信息平台建设的发展阶段；
人口数量在600万以下的市级单位区域卫生信息平台；
基于健康档案的区域卫生信息平台建设初期阶段的省级平台。
2．性能要求：
（1）服务器：
高性能PC服务器，各服务器均独立配置；
要求1～2个处理器、4GB以上内存；
集群模式。
（2）磁盘阵列：
全或半光纤磁盘阵列系统1套；
按区域数据估算存储容量；
支持分区、快照、克隆等基本功能；
支持在线扩容，无须停机。
（3）网络备份系统：
磁带库1套；
网络备份软件1套；
独立的备份服务器。
（4）交换机、路由器：
企业级路由式核心交换机。
（5）防火墙、VPN设备：
企业级硬件防火墙；
独立的硬件VPN设备。
（6）网络防病毒系统：
针对运行Windows系统的服务器、数据库系统进行网络防病毒监控；
对连接到专网的各接入点前置服务器的网络病毒防范；
要求采用中央集中控制和管理。
图5-8 中级配置方案网络基础设施平台图（略）
（三）高级配置方案
高级配置方案是在中级配置方案基础上，将数据库服务器主机由PC服务器更换为小型机系统，进一步增强了数据库系统的运行稳定性和负载能力。并将主要的网络设备改造为的双机负载均衡模式，极大地提高了网络交换性能和网络安全保障能力。
1．适用条件：
基于健康档案的区域卫生信息平台建设的高级阶段；
人口数量在600万以上的市级单位区域卫生信息平台；
完善阶段的省级区域卫生信息平台。
2．性能要求：
（1）服务器：
UNIX小型机，各服务器均独立配置；
要求1～2个处理器、4GB以上内存；
集群模式。
（2）磁盘阵列：
全或半光纤磁盘阵列系统1套；
按区域数据估算存储容量；
支持分区、快照、克隆等基本功能；
支持在线扩容，无须停机。
（3）网络备份系统：
磁带库1套；
网络备份软件1套；
独立的备份服务器。
（4）交换机、路由器：
企业级路由式核心交换机；
双机负载均衡模式。
（5）防火墙、VPN设备：
企业级硬件防火墙；
独立的硬件VPN设备；
双机负载均衡模式。
（6）网络防病毒系统：
针对运行Windows系统的服务器、数据库系统进行网络防病毒监控；
对连接到专网的各接入点前置服务器的网络病毒防范；
要求采用中央集中控制和管理。
图5-9高级配置方案网络网络基础设施平台图（略）
三、几种组网方式
基于健康档案的区域卫生信息平台的建设和推广应用需要要建立一个覆盖国家、省、市、区（县）、镇、村的统一的互联互通的卫生信息网络基础设施； 在链路的选择上采用以太网专线（100M/1000M）为主，对于长距离的考虑2M数字专线，对于乡村等偏远地区选择用ADSL 虚拟专网的方式接入，同时考虑到链路的可靠性及系统的延展，可考虑部分主要会聚中心在专线接入的基础上工，另外配置Internet 虚拟网络接入；为了保证系统的可靠性，在各级汇聚中心要设置防火墙、IPS、IDS等安全设备；在实际的建网过程中，从建设的速度及节约的角度考虑，在部分地区，可以考虑和现有的医保网、政务网等合并。基于健康档案的区域卫生信息平台的网络系统应满足以下要求：
（1）尽量利用现有的基础网络平台和医疗卫生系统的网络平台，减少投资。
（2）形成综合的，多层次的，多方位的网络平台，构建统一的基于健康档案的区域卫生信息平台，提供全面的区域卫生服务网络体系。
（3）网络管理系统应具有同时支持网络监视和控制二方面的能力。提供不同层次上的虚网划分手段。
（4）医疗卫生业务的相关职能部门和业务单位分布范围广，实行的是多级管理，比如医政的管理是二级管理，而社区站的管理是三级管理，业务和系统的层次多、跨度大。并且医疗卫生业务与其它的业务相比，其业务庞杂，有必要在物理网络中为多种应用搭建一个通用的逻辑网络平台，以便于建立各种业务处理系统。
（5）建设基于健康档案的区域卫生信息平台网络平台时，应首先考虑采用VPN技术来建设逻辑业务网。利用VPN网的主干交换机完成底层安全措施，既可防止其他业务系统用户未经授权进入和使用妇幼保健信息网络平台的信息资源，也可防止本系统用户进入其他的业务逻辑网络。
本指南分别列出目前通用、成熟的三种组网建议方案。
（一）专线组网方案
主要是指分组交换网、DDN、FR、ATM等专线连接方案。分组交换网的速率较低、租用费较高；DDN速率较高、租用费高；帧中继（FR）速率较高、租用费较低；ATM速率较高、费用最高。除费用和速率方面外，还需考虑接入的可靠性。
性能要求：
应主要依托卫生行业现有主干网络平台（如公共卫生网、医保网等），组建区域卫生信息平台VPN专网；
区域卫生信息平台数据中心网络接入带宽：10M或以上；
各接入点的网络带宽：2M或以上；
移动接点或单机接点可采用拨号方式通过Internet建立与区域卫生信息平台的VPN连接。
图5-9 专线组网网络结构图（略）
（二）公网宽带组网方案
全国各大城市已经建立了一个结构完整、技术先进、门类齐全、适度超前的基础通信网络体系。互联网宽带的普及，使能接入公网的各业务机构可方便地利用宽带连接与数据中心建立VPN网络。
性能要求：
公网宽带网络；
通过ADSL等宽带方式接入Internet，在公网上建立与区域卫生信息平台的VPN连接；
区域卫生信息平台数据中心网络接入带宽：1M或以上；
各接入点的网络带宽：512K或以上；
移动接点或单机接点可采用拨号方式通过Internet建立与区域卫生信息平台的VPN连接。
图5-10 公网宽带组网网络结构图（略）
（三）电话拨号组网方案
拨号连接的方式主要有两种：一种是PSTN，即公用电话网；另一种是N-ISDN，即窄带综合业务数字网。前者的速率低，使用的是模拟语音信道，覆盖面广，费用低；后者的速率居中，使用的是数字信道，覆盖面居中，费用中等。
性能要求：
公用电话网或窄带综合业务数字网；
各接入点通过电话线拨入到妇幼保健数据中心的Modem池，建立数据链路；
区域卫生信息平台数据中心网络接入带宽：128K或以上；
和各接入点的网络接入带宽：56K或以上；
移动接点或单机接点可采用拨号方式通过Internet建立与区域卫生信息平台的VPN连接。
图5-11 电话拨号组网网络结构图（略）第六节 安全保障体系方案
基于健康档案的区域卫生信息平台的可靠安全的运行不仅关系到数据中心本身的运行，还关系其他业务部门相关系统的运行，因此它的网络，主机，存储备份设备，系统软件，应用软件等部分应该具有极高的可靠性；同时为保守企业和用户秘密，维护企业和用户的合法权益，数据中心应具备良好的安全策略，安全手段，安全环境及安全管理措施。
众所周知，信息系统完整的安全体系包括以下四个层次，最底层的是物理级安全，其包括计算机安全，硬件安全等，其次是网络级安全，主要包括链路冗余，防火墙等等，再次是系统级安全包括数据灾备，病毒防范等，最后是应用级安全包括统一身份认证，统一权限管理等，而贯穿整个体系的是安全管理制度和安全标准，以实现非法用户进不来，无权用户看不到，重要内容改不了，数据操作赖不掉。整个平台的安全体系如下图：
图5-12 平台安全体系结构图（略）
一、安全等级
基于健康档案的区域卫生信息平台所涉及信息包括：病人的基本健康信息，病人的诊疗数据，卫生资源数据等等。这些业务信息遭到破坏后，所侵害的客体是公民、法人和其他组织的合法权益。一旦业务信息遭到非法入侵、修改、增加、删除等不明侵害（形式可以包括丢失、破坏、损坏等），会对公民、法人和其他组织的合法权益造成影响和损害，可以表现为：影响正常工作的开展，导致业务能力下降，造成不良影响，引起法律纠纷等。程度表现为严重损害，即工作职能收到严重影响，业务能力显著下降，出现较严重的法律问题，较大范围的不良影响等。根据以上描述我们可以确定基于健康档案的区域卫生信息平台业务信息安全保护等级为第二级。
业务信息安全被破坏时所侵害的客体
对相应客体的侵害程度
一般损害
严重损害
特别严重损害
公民、法人和其他组织的合法权益
第一级
第二级
第二级
社会秩序、公共利益
第二级
第三级
第四级
国家安全
第三级
第四级
第五级
基于健康档案的区域卫生信息平台属于为国计民生、经济建设等提供服务的信息系统，其服务范围为区域范围内的普通公民、医疗机构等。该业务信息遭到破坏后，所侵害的客体是公民、法人和其他组织的合法权益，同时也侵害社会秩序和公共利益但不损害国家安全。客观方面表现的侵害结果为：（1）可以对公民、法人和其他组织的合法权益造成侵害（影响正常工作的开展，导致业务能力下降，造成不良影响，引起法律纠纷等）；（2）可以对社会秩序公共利益造成侵害（造成社会不良影响，引起公共利益的损害等）。根据《定级指南》的要求，出现上述两个侵害客体时，优先考虑社会秩序和公共利益，另外一个不做考虑。上述结果的程度表现为：对社会秩序和公共利益造成严重损害，即会出现较大范围的社会不良影响和较大程度的公共利益的损害等。由于侵害的客体有两个，侵害的程度也有两个，则业务信息安全保护等级为第二级。
系统服务被破坏时所侵害的客体
对相应客体的侵害程度
一般损害
严重损害
特别严重损害
公民、法人和其他组织的合法权益
第一级
第二级
第二级
社会秩序、公共利益
第二级
第三级
第四级
国家安全
第三级
第四级
第五级
信息系统的安全保护等级由业务信息安全等级和系统服务安全等级的较高者决定。所以，基于健康档案的区域卫生信息平台安全保护等级为第三级。
信息系统名称
安全保护等级
业务信息安全等级
系统服务安全等级
医疗便民服务一卡通
第三级
第二级
第三级
二、物理安全
卫生数据中心是整个基于健康档案的区域卫生信息平台的关键节点，是系统运行的基础，因此必须保证物理环境的安全，主要包括以下几个方面：
信息基础设备应安置在专用的机房，具有良好的电磁兼容工作环境，包括防磁、防尘、防水、防火、防静电、防雷保护，抑制和防止电磁泄漏；
机房环境应达到国家相关标准；
关键设备应有冗余后备系统；
具有足够容量的UPS后备电源；电源要有良好的接地。
三、系统安全
基于健康档案的区域卫生信息平台应具备性能完善的系统安全基础设备。包括网络防火墙、入侵检测、病毒防范、用户识别等信息安全软硬件系统，并设专人进行日常监督管理与更新。
利用防火墙在网络入口点检查网络通讯，根据客户设定的安全规则，在保护内部网络安全的前提下，提供内外网络通讯。
如何防范来自广域网上的安全威胁是本系统安全设计的重点所在。我们采取网络、单机相结合的方式来避免系统遭受计算机病毒的危害。一方面，利用网络防病毒软件来保护服务器，同时实现对网络病毒的监控、报警和实时清除；另一方面，定期使用单机版防病毒软件对工作站进行扫描、杀毒，以消除病毒隐患。防病毒系统的关键在于提高内部工作人员对计算机病毒的认识，不使用盗版软件，对于外来磁盘、软件、文件在使用前及时进行扫描、杀毒，从根本上切断计算机病毒的来源。
通过对主客体进行正确的标识和标注，执行自主访问控制和强制访问控制混合的访问控制机制，保证授权访问的可控性。
四、数据安全
基于健康档案的区域卫生信息平台数据中心的数据是卫生应用关键性数据，必须保证数据的安全和隐私，因此平台的建设必须考虑以下安全措施：
数据库应设置预定的备份策略进行本地备份，有条件的可做异地备份；
严格按照用户级别来授权用户对数据和资料的访问；
关键数据的修改记录应记录详细的操作日志，以备追查；
数据的传输与关键敏感的数据的存放需进行一定的加密处理。
制订数据库系统备份和恢复方案时，必须将重点放在防范用户失误和介质失效而造成的数据损失。基于健康档案的区域卫生信息平台应采用专业的备份软件为整个网络中的服务器和工作站提供高速、可靠的备份和恢复能力。
五、应用安全
基于健康档案的区域卫生信息平台应用级安全包括统一身份认证，统一权限管理等，其包括系统软件和应用软件应具有访问控制功能，包括用户登录访问控制、角色权限控制、目录级安全控制、文件属性安全控制等；系统软件（包括操作系统，数据库等）和应用软件等应定期进行完全备份，系统软件配置修改和应用软件的修改应及时备份，并做好相应的记录文档；及时了解系统软件和应用软件厂家公布的软件漏洞并进行更新修正；应用软件的开发应有完整的技术文档，源代码应有详尽的注释；使用基于PKI-CA体系的数字证书实现各业务应用系统的用户身份验证、数字签名等功能。
基于健康档案的区域卫生信息平台应用安全体系的架构如图所示，整个平台分为三个部分；身份认证基础设施，应用安全管理系统，应用安全中间件。
身份认证基础设施是整个系统的基础，平台整合了数字证书，用户密码模式，动态口令卡，手机动态密码，指纹等多种身份认证模式，并支持接入各地的CA机构。
应用安全管理平台是基于多种身份认证模式对涉及区域医疗卫生安全要素的统一管理，要包括统一身份管理，医疗卫生角色管理，卫生信息资源管理，医疗卫生授权管理等。
应用安全中间件是基于身份认证基础设施和应用安全管理平台，将医疗卫生安全应用以独立中间件服务的方式提供给医院，社区等医疗卫生信息系统使用，从而完成统一的电子健康信息网络安全应用平台的构建.这些中间件主要包括关于身份认证服务的中间件，关于数据安全服务的中间件，关于医疗行为审计服务的中间件。
（一）统一身份认证
数字证书认证中心（Certificate Authority， CA）主要负责产生、分配并管理所有参与网上交易的个体所需的身份认证数字证书。每一个数字证书都与上一级的数字签名相关联，最终通过一个安全链追溯到一个已知的并被广泛认为安全、权威、足以信赖的机构。电子交易的各方都必须拥有合法的身份，即由CA中心签发的数字证书，在交易的各个环节，交易的各方都需检验对方数字证书的有效性，从而解决用户的信任问题。在本系统建设中，可直接利用苏州市数字认证中心已有的CA中心的身份识别基础设施。通过卫生数据中心平台，各应用系统调用各种中间件，方便地实现区域卫生网络系统统一的身份管理与授权管理。
（二）采用PKI加密
基于健康档案的区域卫生信息平台采用加密技术来保护敏感信息的传输，保证信息传输中的安全性。在一个加密系统中，信息使用加密密钥加密后，得到的密文传送给接收方，接收方使用解密密钥对密文解密得到原文。目前主要有两种加密体系：秘密密钥加密和公开密钥加密。
（三）数字签名的应用
在基于健康档案的区域卫生信息平台建设过程中涉及到电子健康档案和电子病历的传输和共享，因此我们需要采用电子签名技术来保证电子健康档案系统的安全性和不可抵赖性。通过区域卫生数据中心平台平台，医院的医生可通过调用身份认证（可采用数字证书或指纹模式），数字签名，数据加密等服务将电子病历上载到卫生数据中心中共享，卫生数据中心可对电子病历信息资源共享的机制进行设置与管理，其他医院医生则通过调用身份认证（可采用数字证书或指纹模式），方问控制，数据解密等服务对电子病历进行调阅，病人也可通过卫生服务网站调用身份认证（可采用手机动态密码方式），访问控制，数据解密等服务对自己的电子病历进行远程查询，从而实现区域内电子病历的安全共享和访问，为电子病历法律化奠定技术基础。
图5-13 平台数字签名系统结构图（略）
（四）隐私与权限管理
为了保证电子健康信息共享的同时实现对居民隐私的保护，平台必须对电子健康信息提供权限管理机制。电子健康信息的权限管理根据医生，管理者，市民等不同的角色进行权限管理，权限管理按等级实现个人级，文件类别级，文件级，市民自定义保护级四级保护机制。
六、安全管理
1．对涉密网的环境因素实施监控和警卫，预防人为威胁；
2．集中建设网络支撑平台监控中心，进行统一安全监控；
3．建立健全相关网络安全管理责任制度；
4．建立严格的机房安全管理制度。非工作人员未经许可不准进入机房，任何人不准将有关资料泄密、任意抄录或复制；
5．禁止在生产系统中使用未经批准的应用程序，禁止在生产系统上加载无关软件，严禁擅自修改系统的有关参数；用于开发、测试的系统必须与生产系统严格分开；
6．监视系统运行记录，及时审查日志文件，认真分析告警信息，及时掌握运行状况，对系统可能发生的故障做好应急方案；
7．软件程序的修改或增加功能时，须提出修改理由、方案、实施时间，报上级主管部门批准；程序修改后，须在测试系统上进行调试，确认无误经批准后方可投入生产应用；
8．软件修改、升级前后的程序版本须存档备查，软件修改、升级时须有应急补救方案；
9．制定各项访问控制措施，包括对网络、主机、数据库等的访问。对所有路由器、交换机的密码及配置应由网络管理员掌握，统一进行配置；对各类主机的管理和对用户以及文件系统的分配、访问权限设置等工作统一由主机管理员执行；对所有数据库的管理和对表、视图、记录和域的授权工作统一由数据库管理员执行。第七节 标准规范管理方案
一、标准规范建设原则
1．有国家（行业）标准的，优先遵循国家（行业）标准；
2．即将形成国家（行业）标准的，争取在标准基本成熟时，将该标准率先引入试用；
3．无国家（行业）标准，等效采用或约束使用国际标准；
4．无参照标准，按标准制定规范，自行进行研制；
5．在编写卫生信息交换标准时，需特别考虑到未来的发展和变化；
6．在此基础上形成区域医疗卫生信息交换标准。
二、遵循与参考的标准
1．国家与行业标准
（1）卫生部《健康档案基本架构和标准》（试行）；
（2）卫生部医院信息系统（HIS）基本功能规范；
（3）疾病分类代码标准 （ICD-10）；
（4）卫生部标准WS/T102-1998，临床检验项目分类与代码；
（5）医药行业标准YY0252-1997，化学药品（原料、制剂）分类与代码。
2．国际标准和国外标准
（1）HL7（美国医疗服务信息网络通讯协议）3.0/2.4版；
（2）SNOMED《国际系统医学术语全集》3.5版；
（3）ICPC（国际初级保健信息标准）；
（5）CPT（美国医院临床操作服务分类编码和术语标准）；
（6）X12N（美国医疗保险业电子数据交换标准）；
（7）LOINC、HHCC、ICIDH等标准。
三、标准规范体系管理
基于健康档案的区域卫生信息平台的标准规范由一系列的规范、机制、制度组成。标准规范体系包含数据标准规范、技术标准规范、管理标准规范、业务标准四个部分。
1．数据标准规范：公共数据元标准、公共代码标准、公共数据存取规范、数据交换规范。
2．技术标准规范：通过技术标准规范支持医院、业务部门系统和信息平台之间的数据级和应用级整合，并提高业务系统之间的应用集成、互联互通的能力。
3．管理标准规范：标准管理、安全管理、数据管理、项目管理，用于指导信息平台日常运行管理、数据维护管理。
4．业务标准：独立业务标准由业务部门制定，关联业务标准由信息平台统筹，协调各业务部门联合制定。
数据标准包括业务数据采集标准，健康档案标准，统计数据标准，共享数据标准，交换数据标准及医疗信息国际标准。卫生信息平台是各个业务部门的基础平台，主要为各应用软件提供接口服务，提供统一的标准。因此要针对不同机构的不同业务，制定统一的应用服务接口标准体系，该标准体系是数据交换的保证。所有接入该平台的应用软件系统，都必须遵循这个统一的接口标准。同时建立标准管理制度，保证标准持续性的升级与完善。
第六章 区域卫生信息平台部署模式
第一节 平台应用架构
基于健康档案的区域卫生信息平台是区域卫生信息化的核心和基础，是整个区域医疗卫生机构实现信息共享与交换，流程整合与协作，资源管理和配置，业务监督与考核的支撑平台，是构建整个区域居民统一的电子健康档案乃至全国统一的居民健康档案，推动和支持医疗卫生体制改革的支撑平台。
整个区域卫生信息化建设是在目前各医疗卫生机构信息系统的基础上构建一个医疗卫生信息集成应用开发以及日常运营的基于健康档案的区域卫生信息平台，同时建设电子健康信息数据中心，制定统一的标准，有效整合各个医疗卫生业务应用系统，形成一个互联互通的医疗卫生业务协作网络，从而实现市民在各医疗机构间（医院与医院之间，医院与社区中心之间，社区中心与社区中心之间）诊疗资料全面共享和交换，包括电子处方，电子申请单，电子报告，电子医疗文书等等；实现双向转诊和双向服务，形成区域居民的电子健康档案EHR数据库，采集、提炼各种医疗卫生管理数据，采用数据挖掘技术等手段，辅助决策支持和应急指挥，在此基础建立统一的服务平台，开展一站式的医疗卫生信息服务等等。
基于健康档案的区域卫生信息平台在技术上实现各医院之间的业务流程整合、跨系统的医疗信息共享与交换，并实现跨医疗机构的预约与转诊，基本病历资料的信息共享和医生处方、检验结果的互认机制和信息共享，实现医疗卫生服务共同体的数字化、自动化、智能化和交互性运营。整个平台系统的总体框架规划如下图：
图6-1 平台应用架构图（略）
如上图所示，整个区域卫生信息化主要包括区域卫生健康档案数据中心，基于健康档案的区域卫生信息平台，电子健康档案EHR管理系统，公共医疗信息服务平台，各种基础业务信息系统等几大部分。整个平台建立在各卫生服务机构现有基础业务信息系统的基础上，通过基于健康档案的区域卫生信息平台的标准化接口群完成各系统之间的健康档案数据交换与共享，实现整个区域的个人健康数据整合和业务整合，每一个业务系统在整个规划中既是一个数据服务的提供者，同时也是数据服务的消费者。
各个系统向整个区域内的卫生业务系统提供自身的业务数据，也可以发出数据请求消息，由基于健康档案的区域卫生信息平台找到能提供这个请求的最佳服务对象，并把请求结果准确的返回给请求者。在此基础上形成卫生健康档案数据中心，在基于健康档案的区域卫生信息平台的基础上建立电子健康档案EHR管理系统，公共信息服务平台等等，通过应用门户使整个信息系统采用统一的入口进行使用和管理。同时通过数据共享与交换平台还可以方便地实现与外部其他信息系统的健康个人信息的共享与交换。第二节 纵向分级部署模式
基于健康档案的区域卫生信息平台支持多级平台纵向部署的架构模型，即通过平台之间的相互配置，能够实现两个平台之间的数据交换，或者是通过逐级交换，实现全国从国家，省 ，市，区（县）四级平台架构，如下图示意：
图6-2 平台纵向分级部署模式图（略）
通过多级信息平台实现数据在各级医疗卫生机构间的信息交换和共享，可以在各级内各个业务信息系统间的数据交换和共享，通过统一的数据标准和数据集进行，各个业务系统间并不直接发生接口关系，所有的接口只针对各级平台统一制订，而下级平台同时是上级卫生交换平台的支撑，各个业务系统数据通过各级平台的梳理传递给上级平台，实现上级平台接口的进一步专业化，避免重复接口的实现风险。同时下级平台又是上级平台的补充，通过下一级平台的建设，分担了上级平台的极高负荷，通过下一级数据的归属化管理，近一步减轻了上一级平台的无效负载，有效改善系统反应速度和开发负责度，通过上一级平台的传递和过滤同时能够实现和下级平台与周边区域的信息共速度交流，减轻了下级平台的接口实现难度，最大限度保留原有投资的不浪费。第三节 横向扩展布署模式
基于健康档案的区域卫生信息平台通过横向部署连接本级的各种医疗卫生机构，能够构建一个十分庞大的区域卫生信息系统，这种部署其涉及的机构众多，条件参差不齐，所以应该针对不同的应用和具体情况对各应用进行合理的部署，才能使系统更加有效推广和应用。区域卫生信息平台横向总体部署参考模型如下：
图6-3 平台横向分级部署模式图（略）
如上图所示，整个系统部署卫生局管辖范围的所有医疗卫生机构，网络以网络服务提供商如电信、广电等ISP提供的专用VPN网络为基础，以卫生信息中心为中心节点，各医疗卫生机构为分支的星型结构。
社区卫生服务机构包括社区卫生服务中心和社区卫生服务站点，这些接入点有条件可以拉专线实现，可以通过ADSL宽带使用VPN接入设备转接。
医保专线接入到中心，所有社区卫生服务机构共用。
数据中心主要部署交换平台等公用类和管理类的系统，数据中心还将部署网站，短信平台等公共应用平台。
各医院部署内嵌省、市、区医保险接口的HIS系统，电子病历系统，PACS系统等等，通过交换平台实现与数据中心和其他系统的联网。
各社区服务中心部署内嵌省、市、区医保险接口的社区HIS系统，社区医生工作站，健康档案等等。社区服务中心通过交换平台实现与数据中心和其他系统的联网。各社区服务站原则上不部署任何系统不存放任何数据，其通过VPN网络只是作为所属社区卫生服务中心的一个应用终端，不部署任何应用，通过直接连接数据库使用专门为社区服务站开发的集成收费、诊疗、取药、健康档案等功能为一体的全科医生工作站。第四节 其他应用模式
通过基于健康档案的区域卫生信息平台还可以构建各种专项的业务信息系统，如全地区的妇幼保健信息系统，新型农村合作医疗信息系统，计划免疫信息系统，血液管理信息系统，干部保健信息系统等等，这些应用都是对健康档案数据和业务体系应用的子集。
在基于健康档案的区域卫生信息平台建设的基础上还可以实现各种增值业务服务，在健康档案的基础上建立远程挂号系统，远程医疗咨询系统，远程会诊系统，远程医学护理系统等等，通过这些应用的开发和使用，更加充分地发挥基于健康档案的区域卫生信息平台的作用，从而构建现代化的医疗卫生健康服务体系。第七章 附录
第一节 缩写
（1）EHR：Electronic Health Records，居民电子健康档案
（2）EMR：Electronic Medical Record，电子病历记录
（3）PHR：Personal Health record，个人健康记录
（4）CHIS：Community Health Information System，社区卫生服务信息系统
（5）CHSS：Community Health Service System 社区卫生服务系统
（6）HIS：Hospital Information System，医院信息系统
（7）CIS：Clinical Information System，临床信息系统
（8）LIS：Laborary Information System，实验室信息系统
（9）PACS：Picture Archiving And Communication Systems，医学影像存档与通讯系统
（10）RIS：Radioiogy Information System，放射信息管理系统
（11）POS：Point of Service，基本业务信息系统
第二节 主要参考文献
（1）卫生部《全国卫生信息化发展规划纲要（2003-2010年）》2002年10月
（2）卫生部《医院信息系统基本功能规范》2002年4月
（3）卫生部《社区卫生信息系统功能规范》2006年11月
（4）卫生部《妇幼保健信息系统基本功能规范》2006年12月
（5）国家卫生信息标准基本理论框架
（6）卫生部《健康档案基本架构和标准》（试行），2009年5月
（7）《新型农村合作医疗信息系统基本规范》（试行），中华人民共和国卫生部办公厅，2005年5月
（8）《妇幼保健信息系统基本功能规范》（试行），卫生部信息化工作领导小组办公室，2008年2月
（9）《妇幼保健信息系统网络支撑平台技术指南》（试行），卫生部信息化工作领导小组办公室，2008年2月