单一来源谈判邀请函

　　南通市政府采购中心（下称采购中心）对以下项目拟用单一来源方式组织采购。现邀请单一来源供应商东华软件股份公司对项目进行谈判。

　　一、项目名称：南通市个人健康管理信息系统项目

　　二、项目编号：NTZC********（DY076）

　　三、项目预算：60万元

　　四、项目需求：见附件。请下载。

　　五、供应商资格要求

　　1、须为南通政府采购会员供应商。请供应商谈判前在南通政府采购网“供应商注册”，并按要求提供相关资料办理会员供应商登记。

　　2、采购单位项目需求中对供应商的资格要求。

　　六、时间、地点和联系人信息

　　1、谈判文件接收截止及谈判开始时间：2014年12月31日9：30

　　2、谈判地点：南通市工农南路150号政务中心5楼第三开标室，如有变动，另行通知。

　　3、谈判联系人：葛天平电话：(0513)********

　　4、采购单位联系人：张晨电话：(0513) ********

　　七、供应商谈判时需携带的材料

　　1、填写的报名登记表（请在南通政府采购网下载中心下载）；

　　2、法人委托书，授权人身份证复印件（带原件备查）；

　　3、项目需求中对供应商资格要求的相关证明材料 (复印件加盖公章，并带原件备查);

　　4、供货进度与售后服务承诺(加盖公章);

　　5、详细的报价依据和清单(加盖公章)。

　　请将上述材料按顺序自编目录牢固装订成册，正本1份，副本2份，均需采用A4纸（图纸等除外），不允许活页或拉杆夹装订，否则不予接收。谈判文件上要明确标注供应商全称及“正本”或“副本”字样，一旦正本和副本有差异以正本为准。谈判文件正本须打印并由法定代表人或其授权人签字并加盖公章。副本可复印，但须加盖公章。

　　八、谈判原则

　　1、供应商参加谈判时，不按本邀请函第七点要求提供齐全谈判材料的，将被拒绝进行单一来源谈判采购。

　　2、谈判小组查验参加谈判的供应商代表身份证明，谈判文件响应采购需求程度及偏差程度。谈判小组应遵循物有所值和价格合理的原则商定洽谈方案的价格承受上限，然后集中与供应商就价格问题进行谈判，供应商第一次报价超项目预算的不予接收，谈判报价原则上不超过3次，超出商定的洽谈方案的价格承受上限，本次谈判予以终止。

　　3、谈判成功后由谈判小组出具成交报告。

　　九、发出成交通知书　

　　采购中心向采购单位和成交供应商发出成交通知书。成交通知书发出后，采购单位改变成交结果，或者成交供应商放弃成交的，应当承担相应的法律责任。

　　十、合同签订与验收付款

　　1、成交供应商和采购单位在接到《成交通知书》后30日内签订合同。签订采购合同一式四份（采购单位、供应商、财政局采购处、采购中心各一份）。所签合同不得对采购文件作实质性修改。采购单位不得向成交供应商提出不合理的要求作为签订合同的条件，不得与成交供应商私下订立背离采购文件实质性内容的协议。

　　2、采购单位按合同约定积极配合成交供应商履约，成交供应商履约到位后，请以书面形式向采购单位提出验收申请，采购单位接到申请后原则上在5个工作日内及时组织相关专业技术人员，必要时邀请采购中心、质检等部门共同参与验收，并出具验收报告，验收合格的原则上5个工作日内支付相应款项。

　　3、采购单位故意推迟项目验收时间的，与成交供应商串通或要求成交供应商通过减少货物数量或降低服务标准的，在履行合同中采取更改配置、调换物品等手段的，要求成交供应商出具虚假发票或任意更改销售发票的，谋取不正当利益的，承担相应的法律责任。

　　4、成交供应商出现违约情形，应当及时纠正或补偿；造成损失的，按合同约定追究违约责任；发现有假冒、伪劣、走私产品、商业贿赂等违法情形的，应由采购单位移交工商、质监、公安等行政执法部门依法查处。

　　5、付款方式：按采购需求中的付款方式。款项由采购单位按相关财务支付规定办理支付手续。

　　十一、费用

　　供应商承担所有与准备和参加单一来源谈判可能发生的全部费用，采购中心在任何情况下均无义务和责任承担这些费用。

　南通市政府采购中心

　　2014年12月25日

附件：

项目需求

一、背景概述、实现功能要求

　　卫生信息化是全面推进社会公共服务领域信息化的重要组成部分。加强卫生信息化建设，既是深化医药卫生体制改革的迫切需要，也是卫生服务与管理现代化的必然选择，对于提高卫生行政效率和医疗服务质量、有效整合社会医疗服务资源、转变卫生事业发展模式、促进卫生事业又好又快发展、更好地为群众健康服务具有重要的意义。

　　南通市区域卫生信息平台，通过对南通市医院信息平台和南通市社区平台的数据进行采集，已实现南通市卫生数据的集中存储、互联互通、实时共享。

　　南通市个人健康管理信息系统从南通市区域卫生信息平台中抽取个人健康相关信息，进行必要的数据封装和整理，通过开发包对外提供统一的健康信息共享服务。

　　南通市个人健康管理信息系统应遵循医改，须实现个人检验检查结果的互联互通。

　　二、投标供应商资格要求

　　1、具有“软件企业认定证书”；

　　2、投标人应具有一个地级市以上得CACHE数据库、ENSEMBLE集成软件的区域卫生信息化应用案例 (提供标书、合同及用户证明等相关证明材料) ;

　　三、付款时间和条件（请详细写明付款承诺）

　　签订合同后10天内支付50%，项目验收完成后支付30%，服务期满后支付20%。

　　四、项目需求

1.总体要求

　　采用行业内主流的技术架构，并以国家相关标准为指导，通过进行关键需求分析，构建我市个人健康管理信息系统分层功能架构。

　　系统设计基本要求如下：

　　系统总体构架。采用面向服务架构（SOA），松耦合的设计分析方法，基于多层构架，保证系统的灵活性、可扩展性和良好的维护性。

　　采用标准和开放的技术。系统设计要遵循国家卫生技术标准和规范以及国家电子政务标准化指南及相关标准，采用先进、开放的技术，支持主流厂商的硬件和操作系统平台。在数据库方面考虑支持当前最流行的数据库技术标准。通过这样的考虑降低技术风险以及特定供应商的依赖性，有利于保持系统的向后兼容性、可集成性和可扩展性。

　　数据标准化：遵循国家卫生部《基于健康档案的区域卫生信息平台建设技术解决方案（试行）》、《基于电子病历的医院信息平台建设技术解决方案（1.0版）》、《健康档案基本架构与数据标准》、江苏省及我市区域卫生信息平台标准规范，为区域内各应用系统提供统一的个人健康信息服务，以保证信息的一致性、身份识别唯一性、个人隐私的安全性、数据共享和交换的可定义性，最终保证系统建成后健康信息在区域内的共享。

　　系统的通用性。系统设计要充分考虑对医院信息系统、基层医疗卫生机构综合管理信息系统、公众健康服务平台、电信运营商以及未来可能对外提供健康服务的各类系统实现信息的提供和信息服务，系统应能提供多种技术实现方式供应用系统选择，如Web Service（Java、.NET实现）、C#的DLL、C的DLL，数据库对数据库等，以满足各类系统的个人健康数据需求，保证本系统的可用性和推广性。

　　各需求单位部署方式：各单位必须架构前置机，实现开发包的下载及部署。

　　1.1建设原则
　　规范化原则

　　系统设计和开发应符合国家及医疗卫生行业的相关信息化和数据标准或规范，需参考和借鉴医改以来中国卫生信息标准最新研究成果。功能必须符合国家、省、市等各级医疗卫生相关管理规范要求。

　　稳定性原则

　　采用成熟稳定的操作系统和数据库平台，同时在系统的结构体系和应用部分各模块的设计中都以此原则约束，从而确保系统的稳定可靠。

　　开放和扩展性原则

　　注重系统的开放性，以适应系统扩充的需要。系统的设计在满足现有需求基础上，充分考虑系统的可扩展性，以满足业务的不断发展，形成一个易于管理、可持续发展的体系结构。要充分考虑国家医疗制度改革对卫生信息系统带来的业务流程变动，具有强大的扩展性，除卫生机构间，还能够提供与其他应用系统(如公安、社保、民政、电信运营商等)的数据交换和共享。

　　安全性原则

　　个人健康信息涉及居民的隐私和健康相关信息的安全，系统设计应保证系统的运行和数据传输，在软件的组织和设计方法的选择、数据的安全性和完整性以及系统的运行和管理等方面采取必要的防范措施，防止和能够恢复由内在因素和危机环境造成的错误和灾难性故障，以保证系统的可靠性。

　　高效性原则

　　在现有的条件下，系统应该确定适当的数据部署和数据访问机制，对于不断增长的数据负荷和一定用户数量，确保系统响应的高效性；系统应该考虑大数据量的访问和传输，保证响应时间处于可接受的程度。

　　易用性原则

　　系统应具有友好的用户接口，界面设置应该与业务相吻合，不同功能的界面风格尽可能统一，使用户易于掌握和操作。

　　经济性原则

　　系统的建设是一项复杂的、长期的系统，因此在规划建设过程中，必须遵循长远规划和逐步建设的指导方针，根据实际需要和经济条件，采用灵活的、能不断适应业务发展的框架，确保阶段性投资的最大收益。

　　1.2性能要求
　　能稳定、高效的支持市属医院及基层医疗机构的同时联网运行；

　　软件系统维护及更新升级不能影响业务工作的开展；

　　能够及时捕捉系统在运行时的错误信息，并给出相应的提示，系统应有一定的容错能力；

　　系统运行时峰值并发处理能力400个并发数以上。

　　1.3安全要求
　　南通市个人健康服务信息系统应用安全性应按照《卫生部办公厅关于印发2010年基于电子健康档案、电子病历、门诊统筹管理的基层医疗卫生信息系统试点项目技术方案的通知》（卫办综函〔2011〕105 号）有关平台安全等级的要求，并提供相应的安全性解决方案。

　　1.4需遵循的标准和规范
　　本项目需遵循以下规范：

　　1.《中华人民共和国电子签名法》（主席令第十八号）；

　　2.公安部《信息安全等级保护管理办法》（公通字〔2007〕43号）；

　　3.卫生部《医院管理评价指南2008年版》（卫医发〔2008〕27号）；

　　4.《中共中央、国务院关于深化医药卫生体制改革的意见》（中发〔2009〕6号）；

　　5.《国务院医药卫生体制改革近期重点实施方案（2009—2011年）》（国发〔2009〕12号）；

　　6.卫生部《健康档案基本架构与数据标准（试行）》（卫办发〔2009〕46号）；

　　7.卫生部《基于健康档案的区域卫生信息平台建设指南（试行）》（卫办综发〔2009〕89号 ）；

　　8.卫生部《卫生系统电子认证服务管理办法（试行）》（卫办发〔2009〕125号）；

　　9.卫生部《电子病历基本架构与数据标准（试行）》（卫办发〔2009〕130号）；

　　10.卫生部《基于健康档案的区域卫生信息平台建设技术解决方案（试行）》（卫办综发〔2009〕230号 ）；

　　11.国家中医药管理局《中医电子病历基本规范（试行）》（国中医药发〔2010〕18号）；

　　12.卫生部、中央编办、国家发展改革委、财政部、人力资源社会保障部《关于公立医院改革试点的指导意见》（卫医管发〔2010〕20号）；

　　13. 国务院办公厅《关于印发医药卫生体制五项重点改革2011年度主要工作安排的通知》（国办发〔2011〕8号）；

　　14.卫生部《电子病历系统功能规范（试行）》（卫医政发〔2010〕114号）；

　　15.卫生部《基于电子病历的医院信息平台建设技术解决方案（1.0版）》（卫办综发〔2011〕39号）；

　　16.卫生部《县级医院及乡镇卫生院院务公开考核标准（试行）》（卫医政发〔2011〕39号）；

　　17.卫生部《三级综合医院医疗质量管理与控制指标(2011年版）》（卫办医政函〔2011〕54号）；

　　18.卫生部《卫生综合管理信息平台建设指南（试行）》（卫办综函〔2011〕350 号）；

　　19. 卫生部《2010年公立医院改革国家联系试点城市医院管理信息系统建设项目管理方案》（卫办综函〔2010〕1044号）

　　20. 卫生部《2010年公立医院改革国家联系试点城市医院管理信息系统建设项目技术方案》（卫办综函〔2011〕101 号）

　　21．《南通市区域卫生数据标准规范》

　　同时为了保证系统的开放性，以及集成的实现，系统需遵从以下标准：

　　1. 支持UNICODE编码

　　2. 支持TCP/IP协议、HTTP、HTTPS

　　3. 对数据库的访问支持ODBC，COM和JDBC

　　4. 支持XML、 Web Service

　　5. 支持HL7

　　6. 支持ICD-10、SNOMED

　　7. ASTM协议等国际信息交换标准

　　8. DICOM标准

　　2.个人健康信息库建设要求

　　建立以个人健康信息为核心的个人健康信息库，该数据库须以居民身份证号为主索引，抽取南通市区域卫生信息平台数据库中与个人健康信息相关的所有数据，为个人健康管理信息系统提供数据支撑。

　　个人健康信息库汇集了全市居民的个人健康相关信息（包括个人基本信息、个人健康信息、个人就诊信息等），通过个人健康管理信息系统对外提供健康信息服务。个人健康信息库作为南通市卫生局提供健康服务的统一出口，为医疗卫生单位、各相关政府行政部门、金融、电信运营商等其他相关机构提供统一的健康信息服务。

2.1 数据架构要求
　　在区域医疗信息中业务复杂多变，又需高效反应，即使在一个城市这样域中，数据也将是海量级的，同时因为使用的对象不同需要用不同方式快速的展现这些，而这些数据又无法笼统的认为都存在一个数据库中，所以系统必须具备一种机制能够在满足业务系统平滑开展的过程中又能将这些数据拼装成以居民为主体的健康档案。

　　这样的系统既要求有一定的业务灵活性，能够将各个服务通过工作流引擎的模式连接起来，无需和传统模式下那样每次业务改变都需要进行大量的代码改变。

　　个人健康管理信息系统的构架设计的目标是建立一个能够容纳管理居民健康信息的可扩充的构架，这里的扩充性包括以下方面：

　　管理业务的扩充：能够围绕电子健康信息建立扩展新的管理业务，从人群健康的角度来看可以建立不同的疾病监控系统；从医疗服务者的角度看，可以查询、调用以不同组织方式呈现的居民电子健康档案。

　　存储健康信息的扩充：能够在系统中增加新的健康信息种类的存储，比如新的医疗影像或检验结果。能够根据每种存储信息的特点对信息内容进行优化，但可以通过统一的接口对新的健康信息可以和已有的健康信息进行查询、调阅。

　　接入方式的扩充：区域电子健康信息中心面对的数据源和用户是各个医疗机构及居民用户，所以能够接纳各种现有的和未来的应用系统的数据上传及使用相当重要。中心构架需要能够扩充对各种接入方式的支持。

　　系统容量的扩充：区域电子健康信息中心是一个数据量庞大的信息系统，在设计时需要考虑对数据存储容量的横向扩充。

　　系统处理能力的扩充：随着区域电子健康信息中心使用者的增加，系统将承受大量的服务请求压力。系统将使用分布式服务和集群等方式实现系统处理能力的扩充。

2.1.1 数据类型要求
　　在存储架构的设计中，我们需要同时考虑健康档案的数据存储和区域卫生信息平台的数据存储。

　　健康档案的存储主要分成五种类型：健康档案数据存储（EHR Data Storage）、业务文档数据存储(Business Document Storage)、ODS数据存储（Operational Data Store）、业务平台数据存储（Business Data Storage）、数据仓库存储（Data Warehouse）。

　　平台运行所涉及的支撑数据包括：标准数据、注册数据、来自各POS的数据等。

　　1)健康档案数据

　　健康档案数据(EHR Data Store)是区域卫生信息平台的基础。健康档案数据不限定以关系型数据库或文档的存储方式进行存储，在存储架构设计中应重点考虑健康档案数据中不同数据存储方式下的存储、归档、检索的效率，以及所涉及的数据备份恢复。

　　根据健康档案信息的分类，健康档案存储服务分为七个存储库：居民基本信息存储库、主要疾病和健康问题摘要存储库、儿童保健存储库、妇女保健存储库、疾病控制存储库、疾病管理存储库以及医疗服务存储库。

　　2)业务文档数据库

　　业务文档数据库指的是医疗活动产生的与EHR相关的文档，这些文档通过区域信息交换层（HIAL）传送到区域卫生信息平台。它需要平台的专门服务解析和

　　映射（Parser/Map/Rebuilder），才能转换成EHR文档。平台必须有一个永久存储业务文档库的数据库。

　　业务文档以XML方式进行组织，与电子签名相结合，在文档库中进行注册。

　　3)ODS数据库

　　从业务支持的角度来看，我们需要建立ODS数据库，来实现对业务的更好支持。为了完成某些特定业务上的流程要求，可能产生很多中间数据，而这些中间数据都有赖ODS数据库实现其存储方式。

　　4)业务平台数据库

　　除健康档案数据(EHR Data Store)之外，区域卫生信息平台需要存储一些相关的业务数据，并实现对这些数据的插入、更新、查询和统计功能。业务数据主要包括以文档形式存储的结果数据，以及操作型数据。

　　文档数据：以文档形式存在于平台中的临床和预防保健业务数据，例如检验报告、处方、传染病报告卡等。这些数据是结果数据。

　　操作型数据：从多个医疗机构内部信息系统中采集上来，并加以汇总处理后的数据，主要服务于统一的实时查询和实时的统计。

　　5)标准数据

　　标准数据是平台运行的数据基础。标准数据包括区域卫生业务数据的所有数据标准规范，通过这个库和数据校验机制对数据中心的数据进行标准化保障，主要的数据标准包括整个定义电子健康档案的数据集和数据元（具体可参考卫生部发布的中国健康档案数据标准），还有各种代码标准。由于数据标准存在着时效性，因此针对有时效性的数据进行版本控制，不同的版本有各自的生命周期，不同生命周期中的业务数据对应不同版本的数据。

　　在系统实现中，标准数据以XML template的形式或关系型数据的形式进行存储。

　　6)注册数据

　　注册数据是满足注册服务所需的数据及存储。包括居民、医疗卫生人员、医疗卫生机构、医疗卫生术语的注册管理数据。

　　7)区域信息交换层（HIAL）临时存储的交换数据

　　区域信息交换层（HIAL）将来自于POS的数据/文档接入到平台中进行处理。区域信息交换层（HIAL）将EHR数据/文档发送到POS或其他数据消费方。这些数据/文档在处理前将临时存放在数据交换（HIAL）应用服务器或其他服务器。这部分数据的存储要求有较高的I/O速度。

2.1.2 存储构成要求
　　EHR 数据存储主要存放EHR 相关的业务数据信息，主要是以EHR 的未经过进一步加工的数据为主。其主要文件存储和数据库中的文档存储两种类型。

　　业务文档存储按照一定的 EHR 信息类型进行分类，实际存储中采用数据库和XML 文档混合存储的模式，他并不对EHR 信息中的明细项进行结构化，即使同一类型的数据，其存储的文档格式也可能因为版本的原因具体结构有所区别。

　　EHR 数据的存储模型以一次健康事件为基本单位，在存储上不对健康事件进行合并和加工。在存储时系统抽取健康事件的类型、健康事件存储时间，发生时间，事件唯一号，以及健康事件的版本信息作为基础索引。

　　在一个区域内中，并非所有的信息都被集中存放在一个物理存储中，这些信息可能分布在区域中的一些医疗机构中，也可能分布在另外一个区域医疗信息中。

　　为了解决上述情况的健康信息调运，EHR 地址服务提供每条医疗信息记录的真实存放地址，在数据读取过程中，读取服务会通过EHR 地址服务查询到真实存放地址，地址信息包括：存放服务器地址，存放服务名等信息。这些存放服务器都需要实现统一的基于Web Services 的数据存储服务，同时使用非显性认证机制来解决安全问题。数据读取服务可以通过EHR 地址服务直接到远端系统中读取相关数据。如果数据是存放在中心中，可以考虑使用本地服务，快速读取数据。

　　在存放数据时，存放服务根据上传数据的情况，通过 EHR 地址服务插入每条记录的地址信息，以提供将来读取需要。

　　EHR 地址服务中的地址数据是存放在独立的数据表中，通过外键与EHR-Index联合。针对EHR-Index 中的每一条数据，都可以查询到相应存放地址。由于EHR是通过数据调用服务来使用的，对于系统中的其他服务来说EHR 地址服务是透明的，不需要针对EHR 地址服务进行任何操作。

2.1.3EHR存储处理流程要求
　　EHR 数据库存储处理有集中存储和分布存储两种模式，集中存储是在统一的EHR 中心对EHR 范围内的数据进行统一存放，此方式主要以文档性数据为主；分布存储是在EHR 中心考虑其存储容量以及网络带宽情况，对大文件内容以及无法结构化且调用频度很低的健康档案内容采用的存储方式，中心对这些文件的位置以及主要属性信息进行索引存储，而不在EHR 中心存储其实体数据，需方在进行调用时，通过数据中心索引寻找其文件位置，然后加载到EHR 中心，再提供给内容需求方使用，影像数据、语音数据等大容量文件建议采取此种存储方式。

　　1)集中存储处理流程

　　集中存储的模式是在 EHR 库中对数据实体进行统一存储的方式，所有的数据实体除了在POS 端有其数据实体外，在EHR 库也保存其一份备份信息，此模式适合单体数据较小的数据存储，如诊疗过程中的门诊诊断、门诊医嘱等文字性描述信息。这些数据通过POS 系统，推送到EHR 平台中，EHR 平台对其进行初步的加工后（对其进行数据格式转换和人员定位），将其存入EHR 存储中，按照其EHR的要求建立索引存储和文档存储，如果数据是以无格式的文档形式报送的，EHR存储原则上按照文件存储的模式进行存放，如果是以有格式的文档形式报送的，EHR 存储采用结构化的数据库存储方式进行存放。这些数据都存放在HER 存储本地，以后其他的POS 调用，平台只需要从EHR 本地存储中获取这些文档实体，无需依赖报送POS 进行路由调用。

　　2)分布存储处理流程

　　分布存储的模式是在 EHR 库中对只对数据实体分布的地址信息以及关键字段信息进行索引存储，不在中心对数据实体数据再次存储。当需求POS 端需要调用其实体数据时，首先由寻址服务通过其地址存储得到其实际存储的物理位置，通过HIAL 从实际物理存储的POS 中将数据拉到EHR 中心，再推送给需求POS 方。

　　需求POS 方在整个过程中并不需要知道其实际的物理存储地址，所有的操作都在EHR 中心完成，其形式同集中存储一样。这种存储方式依赖于数据物理存储的POS端，如果在物理存储的POS 端对其数据进行删除或变更后将无法保证这些数据能够一定被调用。

　　分布存储的存储模式适合如影像文件、语音文件等并不需要被频繁调或需参加到业务处理的大容量数据，同时一些如病程录等主观信息也可以采用此种方式存储。这些数据将在EHR 存储中保留其索引信息、地址信息等关键信息，这样的存储方式可以让系统减少网络的要求以及中心存储空间的要求，降低EHR 中心的造价。

2.1.4 数据仓库：二次应用要求
　　数据仓库是一个环境，而不是一件产品，提供用户用于决策支持的当前和历史数据，这些数据在传统的操作型数据库中很难或不能得到。数据仓库技术是为了有效的把操作形数据集成到统一的环境中以提供决策型数据访问，的各种技术和模块的总称。所做的一切都是为了让用户更快更方便查询所需要的信息，提供决策支持。

　　数据仓库由三个部分组成：数据仓库数据库、数据抽取工具和数据挖掘工具。

　　数据仓库数据库：是整个数据仓库环境的核心，是数据存放的地方和提供对数据检索的支持。相对于操纵型数据库来说其突出的特点是对海量数据的支持和快速的检索技术。

　　数据抽取工具：把数据从 LRS 存储中拿出来，进行必要的转化、整理，再存放到数据仓库内。数据转换都包括，删除对决策应用没有意义的数据段；转换到统一的数据名称和定义；计算统计和衍生数据；给缺值数据赋给缺省值；把不同的数据定义方式统一。

　　数据挖掘工具： 数据挖掘工具利用数据仓库中的大量数据中获取有效的、新颖的、潜在有用的、最终可理解的模式的过程。

　　此平台的数据仓库模块将会通过第三方成熟产品实现，只需要定制数据抽取工具的接口。数据抽取工具将会直接使用Data Service、LDS 和Registry Service 的Web Service 接口，通过他们读取所需的数据，通过数据抽取工具的整理之后，存入数据仓库数据库。对于数据的分析将直接面向数据仓库数据库中的数据，对中心其他服务的运行没有影响。

　　对于数据的挖掘功能，开发运营人员可以使用成熟产品中数据挖掘工具，制定相应分析模型，通过数据挖掘工具的报表和图形功能来读取结果，或者继续调整模型来得到更准确的结果。

　　1)数据仓库的类型

　　数据仓库的类型根据数据仓库所管理的数据类型和它们所解决的企业问题范围，一般可将数据仓库分为下列３种类型：企业数据仓库（Enterprise DataWare ，EDW）、操作型数据库（Operational Data Store , ODS）和数据市集（DataMart）。

　　企业数据仓库为通用数据仓库，它既含有大量详细的数据，也含有大量累赘的或聚集的数据，这些数据具有不易改变性和面向历史性。此种数据仓库被用来进行涵盖多种企业领域上的战略或战术上的决策。

　　操作型数据库既可以被用来针对工作数据做决策支持，又可用做将数据加载到数据仓库时的过渡区域。与EDW 相比较，ODS 有下列特点：ODS 是面向主题和面向综合的；ODS 是易变的；ODS 仅仅含有目前的、详细的数据，不含有累计的、历史性的数据。

　　数据市集是数据仓库的一种具体化，它可以包含轻度累计、历史的部门数据，适合特定企业中某个部门的需要。几组数据市集可以组成一个EDW。随着数据仓库发展的需求，软件工具升级相当快，新产品也层出不穷。为了便于追踪其技术发展和更好地选择相关的工具，数据仓库的构造者应该广泛地收集这方面的文件和数据，以便做出最佳的选择。

　　为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据（subject area）。在数据仓库的实施过程中往往可以从一个业务的数据集市着手，以后再用几个数据集市组成一个完整的数据仓库。需要注意的就是再实施不同的数据集市时，同一含义的字段定义一定要相容，这样再以后实施数据仓库时才不会造成大麻烦。

　　2)数据仓库处理方法

　　ETL 是从EHR-Storage 中攥取数据以及存储数据的底层数据服务，他负责按照一定频度将EHR 的物理存储中的实际数据保存入最后的数据仓库中的多维数据模型中，这些源存储可能是文件存储、数据库存储也可能是索引存储中。其转储频度根据数据仓库的实际需求而定，原则上以不影响EHR 存储的正常操作为底线。

2.2个人健康信息库主题库建立要求
　　一、个人健康管理数据库

　　根据健康档案的基本概念架构，健康档案的内容主要由个人基本信息和主要卫生服务记录两部分组成。

　　1、个人基本信息

　　个人基本信息主要在建档过程中产生。

　　个人基本信息包括人口学和社会经济学等基础信息以及基本健康信息。其中一些基本信息反映了个人固有特征，贯穿整个生命过程，内容相对稳定、客观性强。主要有：

　　1）人口学信息：如姓名、性别、出生日期、出生地、国籍、民族、身份证件、文化程度、婚姻状况等。

　　2）社会经济学信息：如户籍性质、联系地址、联系方式、职业类别、工作单位等。

　　3）亲属信息：如子女数、父母亲姓名等。

　　4）社会保障信息：如医疗保险类别、医疗保险号码、残疾证号码等。

　　5）基本健康信息：如血型、过敏史、预防接种史、既往疾病史、家族遗传病史、健康危险因素、残疾情况、亲属健康情况等。

　　6）建档信息：如建档日期、档案管理机构等。

　　2、主要卫生服务记录

　　健康档案与卫生服务活动的记录内容密切关联。主要卫生服务记录是从居民个人一生中所发生的重要卫生事件的详细记录中动态抽取的重要信息。卫生服务记录信息主要在居民接受保健和医疗服务中产生。

　　卫生服务记录，按照业务领域划分，其主要卫生服务记录有：

　　1）儿童保健：出生医学证明信息、新生儿疾病筛查信息、儿童健康体检信息、体弱儿童管理信息等。

　　2）妇女保健：婚前保健服务信息、妇女病普查信息、计划生育技术服务信息、孕产期保健服务与高危管理信息、产前筛查与诊断信息、出生缺陷监测信息等。

　　3）疾病预防：预防接种信息、传染病报告信息、结核病防治信息、艾滋病防治信息、寄生虫病信息、职业病信息、伤害中毒信息、行为危险因素监测信息、死亡医学证明信息等。

　　4）疾病管理：高血压、糖尿病、肿瘤、重症精神疾病等病例管理信息，老年人健康管理信息等。

　　5）医疗服务：门诊诊疗信息、住院诊疗信息、住院病案首页信息、成人健康体检信息等。

　　二、电子病历数据库

　　电子病历是医疗机构对门诊、住院患者（或保健对象）临床诊疗和指导干预的、数字化的医疗服务工作记录。是居民个人在医疗机构历次就诊过程中产生和被记录的完整、详细的临床信息资源。

　　电子病历的主要内容由：病历概要、门（急）诊病历记录、住院病历记录、健康体检记录、转诊记录、法定医学证明及报告、医疗机构信息等七个业务域的基本医疗服务活动记录构成。列举如下：

　　1、病历概要

　　病历概要的主要记录内容包括：

　　1）患者基本信息

　　包括人口学信息、社会经济学信息、亲属（联系人）信息、社会保障信息和个体生物学标识等。

　　2）基本健康信息

　　包括现病史、既往病史（如疾病史、手术史、输血史、免疫史、过敏史、用药史）、月经史、生育史、家族史、危险因素暴露史等。

　　3）卫生事件摘要

　　指在医疗机构历次就诊所发生的医疗服务活动（卫生事件）摘要信息，包括卫生事件名称、类别、时间、地点、结局等信息。

　　4）医疗费用记录

　　指在医疗机构历次就诊所发生的医疗费用摘要信息。

　　2、病历记录

　　按照医疗机构中医疗服务活动的职能域划分，病历记录可分为：门（急）诊病历记录、住院病历记录和健康体检记录等三个业务域。

　　1）门（急）诊病历记录

　　主要包括门（急）诊病历、门（急）诊处方、门（急）诊治疗处置记录、门（急）诊护理记录、检查检验记录、知情告知信息等六项基本内容。其中包括的子记录分别为：

　　门（急）诊病历：分为门（急）诊病历、急诊留观病历。

　　门（急）诊处方：分为西医处方和中医处方。

　　门（急）诊治疗处置记录：指一般治疗处置记录，包括治疗记录、手术记录、麻醉记录、输血记录等。

　　门（急）诊护理记录：指护理操作记录，包括一般护理记录、特殊护理记录、手术护理记录、体温记录、出入量记录、注射输液巡视记录等。

　　检查检验记录：分为检查记录和检验记录。检查记录包括超声、放射、核医学、内窥镜、病理、心电图、脑电图、肌电、胃肠动力、肺功能、睡眠呼吸监测等各类医学检查记录；检验记录包括临床血液、体液、生化、免疫、微生物、分子生物学等各类医学检验记录。

　　知情告知信息：指医疗机构需主动告知患者和/或其亲属，或需要患者（或患者亲属）签署的各种知情同意书，包括手术同意书、特殊检查及治疗同意书、特殊药品及材料使用同意书、输血同意书、病危（重）通知书等。

　　2）住院病历记录

　　主要包括住院病案首页、住院志、住院病程记录、住院医嘱、住院治疗处置记录、住院护理记录、检查检验记录、出院记录、转院记录、知情告知信息等十项基本内容。其中包括的子记录分别为：

　　住院志：包括入院记录、24小时内入出院记录、24小时内入院死亡记录等。

　　住院病程记录：包括首次病程记录、日常病程记录、上级查房记录、疑难病例讨论、交接班记录、转科记录、阶段小结、抢救记录、会诊记录、术前小结、术前讨论、术后首次病程记录、出院小结、死亡医学记录、死亡病例讨论记录等。

　　住院医嘱：分为长期医嘱和临时医嘱。

　　住院治疗处置记录：包括一般治疗处置记录和助产记录两部分。一般治疗处置记录，住院与门诊相同；助产记录包括待产记录、剖宫产纪录和自然分娩记录等。

　　住院护理记录：包括护理操作记录和护理评估与计划两部分。护理操作记录，住院与门诊相同；护理评估与计划包括入院评估记录、护理计划、出院评估及指导记录、一次性卫生耗材使用记录等。

　　检查检验记录和知情告知信息，住院与门诊相同。

　　3）健康体检记录

　　指医疗机构开展的，以健康监测、预防保健为主要目的（非因病就诊）的一般常规健康体检记录。

　　3、转诊记录

　　指医疗机构之间进行患者转诊（转入或转出）的主要工作记录。

　　4、法定医学证明及报告

　　指医疗机构负责向服务对象签发的各类法定医学证明信息，或必须依法向有关业务部门上报的各类法定医学报告信息。主要包括：出生医学证明、死亡医学证明、传染病报告、出生缺陷儿登记等。

　　5、医疗机构信息

　　主要指负责创建、使用和保存电子病历的医疗机构法人信息。

　　三、健康档案及电子病历索引库

　　索引库用于存储健康档案的索引，从ODS在向业务分类库中ETL过程中及业务分类库向主数据库ETL过程中形成。形成后的索引直接存放在索引库中，索引分为健康事件索引集、健康业务索引集。索引信息需要与个人健康档案进行关联，即与数据中心主数据关联，易于查询。

　　健康事件索引集：健康事件索引集主要根据健康事件类型、所处生命周期、发生时间进行索引，通过对健康事件的分类跟踪，追踪生命周期中关键健康信息。理论上所有上传个人信息记录都将在此索引中都将有其记录索引，此索引本身以时间方式组织，和具体的业务流程和关联无关,生命周期阶段：新生儿期、婴儿期、幼儿期、学龄前期、学龄期、青春期、青年期、中年期、老年期。

　　健康业务索引集：根据不同的业务类型对健康事件进行组合形成索引表，其组织形式和具体发生的业务相关。业务索引为扩展索引，可以根据业务的变化和扩大而发生相应变化。业务索引和健康事件并不是一一对应的，统一健康事件可能被多个索引同时引用，也不是所有的健康事件都一定要归到某一业务索引上，比如某次检查无法和门诊或住院挂钩，则此检查就在检查索引中存在即可，并不需要强制挂到某个医疗过程中。

　　健康档案索引服务中主要记录两大类的信息：

　　1、健康事件信息：包括时间、地点、健康事件名称等；

　　2、文档目录信息：包括临床文档、预防保健文档等。

　　四、公共卫生数据库

　　公共卫生数据库主要是作为资源中心的业务需求的补充，是各个业务条线业务数据在数据中心的落地数据并整理形成，作为后续数据的处理及数据仓库数据的数据来源。

　　内容包括：疾病控制、妇幼保健、卫生监督、新农合和药品监管等。

　　五、平台管理数据库

　　平台管理数据库用于满足个人健康信息管理系统的日常数据管理、用户管理、系统或业务管理以及制定的业务标准、规范和指标体系等信息。

　　内容包括：用户信息、注册信息、权限信息、标准规范、指标体系、流程信息、日志信息、数据字典等。

　　3.个人健康服务开发包建设要求

　　开发商应基于个人健康信息库提供个人健康服务开发包，通过开发包对个人健康信息服务进行封装，对外统一提供健康信息服务。各相关信息需求系统（如HIS）可根据自身需求，针对该开发包进行二次开发，实现定制化的健康信息查询需求。

3.1个人健康服务开发包功能要求3.1.1 主索引服务要求
　　主索引服务用于处理区域卫生信息平台内与数据定位和管理相关的复杂任务，包括相关的索引信息。这些索引链接到产生不同存储服务的服务点，这些服务点产生了特定的居民、医疗卫生人员或者医疗卫生机构，以及实时的业务数据。索引服务负责分析来自外部资源的信息，并恰当地保存这些数据到存储库中，可以反向地响应外部医疗卫生服务点的检索、汇聚和返回数据。主索引服务也知道其他区域卫生信息平台可能在客户端保存的附加数据，也能够对那些区域卫生信息平台转发数据请求，并合并返回数据和本地信息。反过来，主索引服务也能响应来自其他区域卫生信息平台的信息请求。

　　索引服务是平台系统架构的核心组件。该服务负责实现平台互联互通性规范，还可能使用由区域卫生信息平台内提供的组件和服务同其他区域卫生信息平台互动来完成某一项事务。所有到区域卫生信息平台中访问数据的事务希望由索引服务进行处理。索引服务是区域卫生信息平台中唯一一个知晓所有的事务和业务逻辑以及数据访问规则的部件，所以它可以围绕任何数据主题汇集出真正的全程和综合的信息视图。

　　在各级、各类医疗或者医院信息系统中作为医疗服务以及信息系统中信息发生源的主体――病人（Patient）的信息保持正确性与唯一性体现的越来越重要，随之产生了MPI(Master PatientIndex，病人主索引)的概念。

　　为了实现自然人数据的采集，以及和其他子系统、区域公共卫生信息系统网络之外的系统的联系，简化行政管理手段，提高系统效率，降低系统费用，就需要实施统一的居民唯一标识EMPI，并根据这个统一标识实现EHR 的归并和整合。

　　由于在每个系统中每个自然人的计算机标识不一样，如：在医院住院采用住院号，在门诊采用门诊号，在医保系统中有医保号，在与其他系统进行数据交换时，还可能涉及身份证号码等等，诸多的标识系统导致了要在其他系统中识别一个确定的自然人需要花费大量的人力和时间，增加了不必要的成本和时间。通过采用统一标识，将可以快速确定一个个体，并通过此号码在最小数据标准集中获得其基本信息，以及相关在其他系统中所存储的数据信息，可以以此查找到其所有的相关信息，如：临床病历、社区健康档案、血液记录等等。

　　系统通过市民卡或其他卡作为居民唯一标识的介质，而内部唯一标识号可按照系统规则自由定义，每个系统完成居民唯一编码后由数据中心给予验证，如果重复则给予回退，如果发现统一个体采用了不同标识，则系统通过模糊检索如姓名，性别，年龄等信息找出类似个体如果确认则将新个体与原标识进行唯一匹配（这种方法即是居民唯一标识交叉索引PIX），从而保证居民标识的唯一性和延续性。EMPI 与卡、健康档案EHR 的关系如下图：

　　因此本系统需要为每个居民建立一个唯一标识 EMPI，因此需要对EMPI 进行注册，更新、合并和管理，也可以通过外部系统如市民卡系统采集居民信息，进行这些操作时离不开PIX 机制，它可以基本保证系统中居民标识的唯一性。

　　为了保证快速识别某居民，一般都对一居民发放一种或多种卡介质，我们将这种卡介质称为MPI 卡，市民卡只是卡介质的一种，系统也需要针对每个MPI 提供卡的登记、挂失、解挂、更换、注销等多种操作，也可通过接口由外部的某个系统（如市民卡系统）来实现这些操作，也可两者并存。MPI 的建立可以和MPI 卡的建立相互独立，但可以同时完成两项操作，但MPI 卡必须建立在具体的MPI 之上。

　　但随着区域级多信息系统的大量集成、信息共享以及信息交换的大量应用，病人主索引的应用已经由单层次简单应用扩展到多层次跨域的复杂应用。随之便产生了跨域MPI 协同的概念。

3.1.2 数据抽取服务要求
　　数据抽取服务提供开发包通过医疗机构前置系统从个人健康信息库采集健康档案信息，并对数据交换和数据采集行为进行规范化。

　　主要功能包括：数据抽取、数据转换、数据封装、代码解析、数据导入。

　　数据抽取服务是一个以提供对原有健康数据的抽取服务和整合服务，并为机构及业务系统的健康信息调用提供支持。

　　3.1.3数据交换共享服务要求
　　医疗信息服务总线 （HSB）是整个数据共享交换平台的技术核心，通常采用面向服务的体系结构。该服务保证在一个异构的环境中实现信息稳定、可靠的传输，屏蔽掉用户实际中的硬件层、操作系统层、网络层等相对复杂、烦琐的界面，为用户提供一个统一、标准的信息通道，保证用户的逻辑应用和这些底层平台没有任何关系，最大限度地提高用户应用的可移植性、可扩充性和可靠性。提供一个基于应用总线的先进应用整合理念，最大限度地减少应用系统互联所面临的复杂性。系统的实现维护都相对简单，保证每一个应用系统的更新和修改都能够实时地实现；同时当新的应用系统出现时能够简便的纳入到整个IT环境当中，与其它的应用系统相互协作，共同为用户提供服务。

　　一、业务组件服务要求

　　1.公共服务

　　1）监控日志服务

　　监控日志服务用来记录系统中所处理的业务和系统事件，用户可以通过统一界面配置和浏览所记录的事件。平台中将设计一系列事件体系，包括业务事件和系统事件。各个模块都可以定义各自的所产生的事件，并且通过平台统一的接口进行记录。监控日志服务将根据用户对监控日志服务的配置对事件进行记录。系统同时将提供一个集中式监控日志浏览接口，此接口将分析所有事件记录文件，用网页界面方式供用户查询和浏览。

　　2）标准转换服务

　　标准转换服务是用来将一种XML格式的文件通过XSLT转换成另一种格式。一种典型的应用是当用户调用某个病人的记录时，系统将记录从XML格式转换为健康档案浏览器可以显示的HTML格式。标准转换服务可以将原始医疗记录转换为系统标准医疗信息数据结构。

　　标准转换服务是保证数据长期有效的根本服务。在系统中随着应用的升级，系统中会积累各种历史格式的数据，只用通过变形在使用中转换历史数据，才可以保证数据的可用性和统一性。

　　3）权限验证服务

　　权限验证服务用来根据已认证用户的角色来决定是否用户有权限执行指定的操作。权限验证服务提供验证和认证两方面的功能。验证功能有两种方式：显示认证和隐式认证。显示认证需要用户主动输入用户名和相应的用户密码或其他认证方式。在权限验证服务通过密码认证了此用户后，用户才可以用此认证用户的身份来调用他能够调用的服务。隐式认证是指用户或其系统使用以配置好的非对称密钥等系统直接认证其身份，不需要主动输入用户名和密码。系统可以根据其配置直接赋予其所对应的验证用户的身份。认证功能将基于用户的角色定义，赋予某种角色的用户可以拥有与角色相应的权限。

　　用户的验证和认证管理将被实现为Web Service的一种服务，具体的用户信息和角色信息的存储将被存入LDAP服务器。用户信息将和居民, 医师和机构绑定。每个服务被调用前，如果需要对调用者进行验证和认证，会先调用验证服务确定调用者的身份，然后调用认证服务确认调用者的权限是否能够调用此服务。

　　4）隐私管理服务

　　隐私管理服务用来制定从法律，制度和居民要求等几个方面对居民医疗信息的访问进行限制和授权。系统将会指定一个通用的授权制度，比如说允许急救室访问所有病人的医疗信息，或者允许病人访问过的医院里的医师访问此病人的所有信息。系统也可以允许病人自定义授权条件，允许某些医师或某些医疗机构访问自己的医疗信息记录。

　　隐私管理服务将被实现成Web Service服务。系统中将医疗信息记录按照种类或者条目制定记录ID，在实现时，将为每个用户建立一个授权映射表，指出某些医师或机构已经被授权访问哪些信息。

　　5）数据加密服务

　　数据加密服务实现对系统中的关键数据加密保护，其子功能包括密钥管理功能、字段加密功能和WS-Security加密功能。可能加密的数据包括电子健康信息(使用居民、医师或医疗机构密钥)，传输信息包和密码等信息。加密所用的非对称密钥由注册服务保存，最终存放在LDAP服务器中。

　　6）数字签名服务

　　数字签名服务实现对系统中的信息包进行数字签名，保证数据的完整性和不可抵赖性，其子功能包括针对字段的电子签名和针对XML的电子签名。可能加密的数据包括电子健康信息(使用居民、医师或医疗机构密钥)等信息。加密所用的非对称密钥由注册服务保存，最终存放在LDAP服务器中。

　　7）目录管理服务

　　目录管理服务是提供系统内外所用到的服务信息格式的注册服务。在注册信息格式的同时，目录管理服务还保存与此服务相关的描述信息。

　　8）集成服务

　　l平台支持业务系统开发开发与运行，具备统一的分析、设计、编码、测试、部署、运行、维护功能，保证各个系统技术架构的一致性，有助于解决众多应用系统的集成、服务共享和界面、操作风格的一致性问题，方便最终用户的使用，提高工作效率；

　　l平台需要支持集中式和分布式、混合式部署，具备组件库、BPM工具及统一的IDE集成开发平台，提高开发及维护效率。

　　l平台同时需要具备定制开发系统的标准、规范、方法；其中集成标准包括但不限于应用集成、通讯（IM、手机短信、邮件等）集成、界面集成、流程集成等方面，便于多个系统集成。

　　2.通讯服务

　　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服务器上删除或者改名作为处理完的标记。

　　3.数据存储服务

　　健康档案的存储主要分成三种类型，健康档案数据存储（EHR Data Storage）、业务数据存储（Business Data Storage）、数据仓库存储（Data Warehouse）。健康档案的数据存储并不和某一数据库进行绑定，他的存储模式有文件系统存储和数据库存储两种模式。

　　根据对健康档案信息架构的分析及对开放式电子健康挡案的定义，我们将健康档案的设计模型归纳为居民主索引、健康档案索引、健康档案数据三个层次，健康档案索引好比信息架构模型中的文件夹，能够用来构建多维的健康档案模型，健康档案数据好比信息架构模型中的文件，每个文件都是由众多的各种条目和数据元构成的，这些组成关系均可通过XML进行定义成不同版本的标准模板。为了保证对健康档案的快速检索和定位，还保存定义健康档案的摘要信息和地址信息(即文件定位器)，整个健康档案的计算机技术结构如下图所示:

　　区域卫生信息平台的数据中心还应用该存储各种标准数据和注册数据，以满足平台运行的需要。同时为了区域卫生管理需要还需要建立各种数据仓库。因此根据以上分析，整个基于健康档案的区域卫生信息平台数据中心应该包括的数据内容及相应的存储模式如下表:

数据类型
存储模式

MPI
关系数据库Table

EHR索引
关系数据库Table

健康档案摘要
关系数据库Table

健康档案地址
XML

健康档案实体
XML,文件,文档(包括XML,HTML,DICOM,PDF,DOC,…….)

标准数据
关系数据库Table，XML

注册数据
关系数据库Table

数据仓库
关系数据库

　　1)标准数据

　　标准数据是区域卫生信息平台运行的数据基础。标准数据包括区域卫生业务数据的所有数据标准规范，通过这个库和数据校验机制对数据中心的数据进行标准化保障，主要的数据标准包括整个定义电子健康档案的数据集和数据元（具体可参考卫生部发布的中国健康档案数据标准），还有各种代码标准。由于数据标准存在着时效性，因此针对有时效性的数据进行版本控制，不同的版本有各自的生命周期，不同生命周期中的业务数据对应不同版本的数据。

　　2)注册数据

　　居民注册数据：居民注册数据即居民主索引MPI(Mask Patient Index)，是指在特定域范围内，用以标识该域内每个病人实例并保持其唯一性的编码。病人唯一标识是指用于临床实际业务并且能够辅助进行病人信息唯一性识别，在该域或跨域各涉众均可见的病人唯一编码。病人主索引服务是指为保持在多域或跨域中用以标识病人实例所涉及的所有域中病人实例的唯一性，所提供的一种跨域的系统服务。各地可采用社保卡（居民卡）加补充的健康卡来进行唯一标识的加载与识别。

　　医师注册数据：医师注册数据包括区域内需要访问区域卫生信息平台医生资料。包括医生的基本信息，医师等级，业务权限，数字证书等内容。

　　机构注册数据：机构注册数据包括区域内连接到区域卫生信息平台的全部医疗卫生机构资料。包括机构的基本信息，机构等级，业务权限，数字证书等内容。

　　医学术语注册数据：医学术语注册数据主要是各种定义健康档案需要的各种标准的统一的医学术语，其是健康档案某数据元的元数据。

　　3）健康档案索引

　　健康档案索引服务是健康档案快速定位目录，通过健康档案索引，能够迅速定位相关的健康信息所在的存储位置，方便ELs能够迅速读取其健康信息。健康档案索引的编目方式主要以时间为维度纵向展开，主要的索引方式为时间和唯一编号，它和健康档案摘要服务共同构成健康档案的主要查询体系。健康档案索引的方式是多样的，它独立于健康档案存储存在，在数据进入健康档案存储时即根据制定的一定规则去生成相关的索引。同样的一个数据可能具备多种索引，比如诊断索引，药品索引，健康事件索引等。其不同的索引目的是针对不同的查询能够迅速去定位相关信息，被索引的字段一般为已经能够被确定结构化的信息，如诊断编码、药品编码、健康事件号、健康事件类型等。索引本身仅仅是原数据的关键信息抽取，不作为统计分析使用。也不会因为版本的升级而变化，即使系统建立后仍然可以添加索引，索引系统可以基于健康档案实体动态的增减。健康档案索引目前分为健康事件索引集、健康业务索引集。

　　健康事件索引集：健康事件索引集主要根据健康事件类型、所处生命周期、发生时间进行索引，通过对健康事件的分类跟踪，追踪生命周期中关键健康信息。理论上所有的上传居民信息记录都将在此索引中都将有其记录索引，此索引本身以时间方式组织，和具体的业务流程和关联无关,生命周期阶段：新生儿期、婴儿期、幼儿期、学龄前期、学龄期、青春期、青年期、中年期、老年期。

　　健康业务索引集：根据不同的业务类型对健康事件进行组合形成索引表，其组织形式和具体发生的业务相关。业务索引为扩展索引，可以根据业务的变化和扩大而发生相应变化。业务索引和健康事件并不是一一对应的，统一健康事情可能被多个索引同时引用，也不是所有的健康事件都一定要归到某一业务索引上，比如某次检查无法和门诊或住院挂钩，则此检查就在检查索引中存在即可，并不需要强制挂到某个医疗过程中。

　　4）健康档案摘要

　　健康档案摘要服务是针对健康档案的一个概括性快照，它从健康档案信息中抽取关键性指标，生成一个能够描述居民当前健康状况以及主要健康事件的信息文本，他包含一定的关键域，客户端能够通过这些关键域同健康档案索引服务关联起来，去定位当前居民健康状况中的关键性问题。健康档摘要服务提供查找以及生成两个功能，健康档案摘要的存储是独立健康档案存储的独立系统，客户系统中默认情况，将首先调用该服务去了解居民健康概况，然后再去进一步深入调阅其他信息。

　　5）健康档案地址

　　在一个区域医疗信息网络中，并非所有的信息都被集中存放在健康档案数据中心中，这些信息可能分布在区域中的一些医疗机构中，也可能分布在另外一个区域医疗信息中。为了解决上述情况的健康信息调运，健康档案地址服务提供每条医疗信息记录的真实存放地址，在数据读取过程中，读取服务会通过健康档案地址服务查询到真实存放地址，地址信息包括：存放服务器地址，存放服务名等信息。这些存放服务器都需要实现统一的基于Web Services的数据存储服务，同时使用非显性认证机制来解决安全问题。数据读取服务可以通过健康档案地址服务直接到远端系统中读取相关数据。如果数据是存放在中心，可以考虑使用本地服务，快速读取数据。在存放数据时，存放服务根据上传数据的情况，通过健康档案地址服务插入每条记录的地址信息，以提供将来读取需要。健康档案地址服务中的地址数据是存放在独立的数据表中，通过外键与健康档案索引联合。针对健康档案索引中的每一条数据，都可以查询到相应存放地址。由于健康档案是通过数据调用服务来使用的，对于系统中的其他服务来说健康档案地址服务是透明的，不需要针对健康档案地址服务进行任何操作。

　　6）健康档案数据

　　健康档案数据存储主要存放健康档案相关的原始实体数据信息，主要是以健康档案未经过进一步加工的数据为主。实体的主要表现形式为文件存储和数据库中的文档存储两种类型。文档存储按照一定的健康档案信息类型进行分类，实际存储中采用数据库和XML文档混合存储的模式，它并不对健康档案信息中的明细项进行结构化，即使同一类型的数据，其存储的文档格式也可能因为版本的原因具体结构有所区别。健康档案数据的存储模型以一次健康事件为基本单位，在存储上不对健康事件进行合并和加工。在存储时系统抽取健康事件的类型、健康事件存储时间，发生时间，事件唯一号，以及健康事件的版本信息作为基础索引。

　　7）数据仓库

　　数据仓库是为了区域卫生管理建立的数据库,其用来对区域卫生业务进行统计分析、业务监督、绩效考核、应急指挥及决策支持等。其是通过从健康档案数据和各医疗卫生机构信息系统的业务数据中抽取归纳出来的，主要包括卫生资源数据库和主题数据库。

　　卫生资源数据库主要通过卫生统计途径获得，包括区域的人口构成、面积等本底数据，区域内医疗机构的信息，在册医生、护士、医疗技术人员相关信息，各种医疗设备、医疗设施，医学情报、数字图书馆等知识资源，以及配合电子地图系统的区域地理信息等。卫生资源数据主要通过采集方式获得并共享给各个系统使用，采集方式可以分为自动采集和手工采集两种，已经存在信息系统或者很方便构建信息系统的相关资源数据通过自动方式采集，对于无法通过自动方式获得的信息通过手工录入方式维护到数据中心。相关已经存在的系统包括卫生部卫生统计系统，医疗机构注册管理系统，执业医生、护士系统，外部采购医学情报、数字图书馆（包括自编辑内容）、电子地图等。

　　主题数据库是配合公共卫生系统和应急指挥系统以及决策分析的需要，数据仓库的方式根据不同的卫生主题组织主题数据库。主题数据库的内容按照主题数据集的要求从各个业务系统的表单型数据中清洗后获得。

　　二、运行监控管理要求

　　1.主题管理

　　在发布订阅模式中，各医疗机构或业务科室可对数据中心中流转的相关业务信息进行订阅，对该部分内容进行主题式的管理，在数据中心将根据业务需要，设置树状分层的主题节点，通过交换平台，当相关机构产生主题消息后，信息自动向主题发布，则订阅该主题的机构或业务科室就可以收到该条消息，如卫生局关心甲类传染病信息，对该主题节点进行订阅，则将来发生任何甲类传染病报告事件，信息都会发布到卫生局应用节点。主题管理包含以下几个部分：

　　l主题维护（对主题进行增加、修改、删除活动）；

　　l主题订阅管理（对机构申请订阅主题进行权限审核）；

　　l主题发布管理（对要发布主题信息的机构或应用系统进行准入管理）；

　　l主题消息负载管理（对各主题内消息流量进行统计分析）。

　　2.节点管理

　　由于数据共享与交换平台是一个复杂的、分布式网络结构，单靠人工进行管理各个传输节点是很困难的一件事。当前的网络系统中都有哪些节点，它们运行状态如何，有哪些是新增加的节点，是否有非法节点加入，这些都是难以解决的问题。

　　因此，系统必须引入节点管理功能。通过配置各个节点的参数和属性，构建整个数据交换环境。在监控端，以图形方式显示所有的网络段和节点并自动检测各个节点的状态，使管理人员能够一目了然地发现问题节点。

　　3.密钥管理

　　在数据交换过程中，数据文件发送和接收双方都需要对对方的密钥进行认证，以保证数据的防抵赖、防否认和防篡改。安全、周密、有效的对密钥进行管理是数据交换安全设计的一个重要方面，通过对各种密钥进行管理，能够确保整个数据交换系统的安全。

　　4.日志审计

　　为了更好的使系统管理人员了解和掌握系统的运行和使用情况，我们基于日志管理，通过对特定事件的定义和对各类系统检测数据阀值的设定，达到监控系统运行状态的目的。日志记录日常用户使用的情况，跟踪每一笔数据交换过程后进行的所有操作。如操作流水号、院区、系统名称、发送时间、接收时间、模块名称等，用以提高系统的安全性，跟踪非法操作与越权操作，统计接口的执行频度。日志审计反映了每个服务的生命周期的痕迹。它记录了从消息代理、服务解析，到服务排队、服务路由每个检查点的状态。并通过预先设定阈值，检查服务的即时状态，来判断服务有效性。此外，因为数据交换平台第三方地位的特殊性，日志服务可作为不同系统之间交换发生故障时的凭据，可作为来诊断发生的问题以及设计处理的仲裁者。

　　5.数据备份与恢复

　　数据交换平台的中心共享性数据（如病人基本信息、健康档案）处于非常重要的位置，确保数据中心数据的安全是系统必备的功能。通过数据备份和恢复管理，根据设定的数据备份策略，定期备份指定范围的数据，可以在需要的时候将备份的数据恢复。并且能够通过设定，利用系统提供的自动通知功能，提醒系统管理人员备份数据。

　　三、平台配置管理要求

　　1．用户管理

　　通过机构/用户管理可以规范用户对集成平台的使用行为，可以根据用户的组织机构设置相应的用户组和对应的用户。用户管理应该能够对用户进行全面的管理，包括用户组的增加、修改和删除；用户的增加、修改和删除；用户与用户组之间的对应；以及其余角色的权限管理安全可靠的密码管理功能。

　　2．权限管理

　　在数据共享交换平台中权限管理至关重要，不同的用户具有不同的权限，使用不同的信息路由路径，对各应用节点的接口调用进行身份验证。这样保证了系统的安全性、可靠性和稳定性。系统应从不同的角度进行相应的权限管理，功能权限指对接入平台的各个应用以及功能服务的访问权限；数据集权限即数据项权限，是指用户对传输中的信息各数据项的访问权限；管理范围及记录权限，是作为共享数据信息内容的访问权限。当用户所具有的信息，符合通过管理范围设定出的特殊匹配条件时，允许用户访问相应管理范围所规定信息内容；权限方案允许用户导出和导入。便于权限管理信息的分发和设定；用户还可对自己相应的权限信息进行打印。

　　3．系统配置

　　由于数据共享与交换平台是一个复杂、庞大的系统。软件系统需要不断地维护和更新，如果每修改一次都需要到用户终端进行一次程序更新，系统的维护的工作量是无法想象的，为了解决这一矛盾，系统对各接口组件实行智能维护，提供功能服务组件版本自动更新功能、系统参数设置功能和提供个性化服务功能等。对于数据集和流程定义配置文件的更新，也应通过分发机制保证各节点的统一性。

3.1.3 数据集成服务
　　提供对个人健康信息集成，为上层应用系统的建设提供一个标准的、统一的数据视图和业务服务操作界面。

　　个人健康服务开发包是为区域卫生信息化提供一个以个人健康数据为核心的开发和运行平台，把不同来源、格式、特点性质的数据在逻辑上或物理上有机地集中, 为上层应用系统的建设提供一个标准的、统一的数据视图和业务服务操作界面。

3.1.4 数据元管理服务
　　数据元管理服务的功能是提供医疗数据的格式定义，管理和激活验证等活动，保证中心中保存的电子健康信息的数据一致性和长期的可用性。基于此现状，本系统将提供以下功能：

　　l将南通市区域卫生信息平台元数据导入；

　　l元数据定义的多版本定义功能，支持对数据元数据集的升级；

　　l元数据到XML Schema的映射定义，直接生成XML Schema文件；

　　l元数据定义和XML Schema在Metadata Repository Server上集中保存；

　　l元数据上载、卸载至全程健康档案服务服务；

　　l元数据和电子医疗数据的映射和激活使用。

3.1.5 数据映射
　　数据映射服务是指从业务数据源中挑选出与某项业务相关的信息，并对其进行重新分类及命名。它将同数据库及查询语言的技术细节隔离开来，而使用熟悉的业务用语重新管理和命名数据库里的数据。它可以将数据库中的表及字段改为有意义的业务术语，从而使最终用户可轻松构建查询和报表；能按用户习惯，对数据库信息进行分类管理；预建表关联（以后做查询、报表不必再建）；将复杂统计表达式作为单个对象，象使用字段一样方便查询和做报表；实现单点更新，修改一处，更新全部等功能。

3.2个人健康服务开发包数据需求
　　个人健康服务开发包提供共享的数据应至少包括：个人健康信息、患者基本信息、门诊信息、处方信息、住院信息、医学影像检查报告信息、检验报告信息、病案首页信息、健康体检信息等。详细数据需求见附件。

3.3个人健康信息浏览器建设要求3.3.1设计要求
　　根据国家卫生部的《基于健康档案的区域卫生信息平台建设指南》（试行）有关健康档案浏览器的要求，结合南通市区域卫生信息平台健康信息调阅的实际要求，南通市区域卫生信息平台的健康档案浏览器应该满足以下要求：

　　1. 能够为一个医疗卫生人员提供不同医疗卫生域的信息服务，即在浏览器上应该显示出医疗、儿童保健、妇女保健、疾病管理（慢性病管理）、疾病控制、医学报告等相关信息，可以通过区卫生信息平台（数据中心）来搜索、访问病人的全面的健康和医疗记录。且方便、易学、易用；

　　2. 应能支持不同类型数据的显示方式，比如说HTML页面，图片或扫描文档；

　　3. 健康档案浏览器的显示窗口可以被嵌入Windows平台的应用程序，并能引用所被嵌入的应用程序的验证机制，以便集成到原来的社区系统和医院系统中；

　　4. 健康档案浏览器所显示的数据都来自中心服务器，相应的授权、日志和认证等功能全部在中心端实现，对于客户端的健康档案浏览器完全透明；健康档案浏览器的认证和Consent是直接通过中心的服务完成，与所嵌入的应用程序的配置无关；

　　5. 健康档案浏览器可以对病人医疗记录进行重新排序、归类等工作，但不能直接更新医疗记录；

　　6. 对于健康档案浏览器中浏览信息的流转都将通过标准HTML/JavaScript来实现，对于扫描文档等非HTML信息的显示也是通过标准HTML MIME控件的嵌入显示方式。由于目标客户机内所附带的IE控件的版本的不同，健康档案浏览器应兼容IE 5.0到8.0的IE版本。

3.3.2栏目设置要求
　　（1）导航功能区

　　设计目的：方便使用者快速根据其关注的内容查看居民健康档案。

　　设计理念：可以根据不同地区使用习惯进行组合排列；本页面这里分为两个方面的考虑，一方面按照卫生服务分类，可以关注六位一体以及全生命周期过程中不同服务领域提供的卫生服务的过程记录，组织展示有利于按照不同服务查看服务过程；另一方面按照居民健康档案中较为关注的医疗业务活动进行分类，聚合相同类别的数据，提供使用者直观的，连续的相同类别业务活动记录。

　　设计依据：参考卫生部颁布的《基于健康档案的区域卫生信息平台建设指南（试行）》。

　　设计特点：根据不同地区管理需求，导航可以重新编排、归类组合。

　　功能特性：

　　1）根据不同地区管理需求，导航可以重新编排、归类组合；

　　2）导航栏目特性说明：

　　l个人摘要：提供居民健康的整体概括，使用者比较方便的了解居民的健康状况，主要提供以主页面汇集形式将基本信息、疾病管理、服药情况、诊疗记录、生理指标、监控指标体现在个人摘要中；

　　l服务分类：按照健康服务业务分类来展示居民健康信息；方便医疗服务人员以及卫生管理人员从各自业务角度查阅完整的健康服务过程。具体内容划分：

　　n儿童保健:包含出生登记、访视记录、儿童保健、体弱儿登记、死亡记录等信息；

　　n妇幼保健：包括建卡信息、产前检查、分娩信息、访视信息以及高危、死亡登记；

　　n疾病专项：慢病建卡信息、随访信息、病情流程信息、功能评估信息；

　　n医疗服务：包括门诊诊疗信息、住院诊疗信息、家庭病床信息、转诊诊疗信息；

　　l医技诊疗：由于医技诊疗出现在各个业务条线中，同时又是各业务条线的评估、治疗、干预的基础，所以将医技诊疗按照服务项目进行汇集分类；具体内容分类：

　　n医学影像：主要包括放射、核共振、CT类医学影像的报告信息，同时支持导入图片；

　　n超声检查：主要包括彩色、黑白类超声影像的报告信息，同时支持导入图片；

　　n病理检查：主要包括病理报告、同时支持病理切片图片导入；

　　n检验：主要包括各类实验室检验项目以及报告；

　　l临床诊疗：提供健康档案使用者临床接收各种类别的诊疗记录；具体内容分类：

　　n诊疗：主要包括临床各系统诊疗、经血管介入诊疗；

　　n手术治疗：包括各类手术治疗记录以及麻醉记录信息；

　　n其他治疗：主要包括康复治疗以及物理治疗信息；

　　（2）基本信息区

　　设计目的：方便查看个人基本信息。

　　设计理念：按照个人基本信息的相关内容分类显示，从人口学、生物学、社会学角度展示个人摘要信息；能够给予健康档案使用者一个直观的认识。

　　设计依据：参考卫生部颁布的《基于健康档案的区域卫生信息平台建设指南（试行）》。

　　功能特点：方便直观的体现个人摘要。提供查看个人疾病史、家族史、药物过敏史、婚育史信息。

　　（3）疾病信息区

　　设计目的：方便查看长期影响居民健康的疾病信息。

　　设计理念：在卫生服务过程中，对于居民来说过去影响以及一直会影响居民健康的疾病（或问题）将会是整个生命周期中的卫生服务需求的侧重点，所以列出这些信息，能够有效的提高卫生服务的效率和质量。

　　功能特点：按照管理时间进行展示主要疾病（活问题）。

　　（4）长期用药区

　　设计目的：方便查看长期用药情况。

　　设计理念：对于患有慢性病、精神类疾病的居民，需要长期服务药物才能得到有效的控制，了解用药情况，在接收服务时，有利于提供服务人员治疗和调整计划的依据，为更好的控制疾病发展做好支持；

　　功能特点：根据需要显示长期、主要用药名称、用量、用法、开始用药时间、变更情况，同时支持在社区系统开立医嘱的时候纳入长期用药。

　　（5）诊疗服务区

　　设计目的：方便查看最近3-5次的就诊或者住院情况。

　　设计理念：提供健康档案使用者获取最近的门诊或者住院的就诊情况；能够有效的获取疾病的变化情况，以及治疗情况，适时的调整治疗计划。

　　功能特点：提供索引信息，按照时间获取健康档案数据中的住院以及门诊索引。

　　（6）生理指标区

　　设计目的：提供连续的生理指标记录。

　　设计理念：生理指标散落在不同的服务记录中，将各自散落的进行聚合形成曲线，为服务人员更好的了解居民生理指标提供了方便。

　　功能特点：聚合所有记录中的生理指标，提供连续的变化曲线。

　　（7）监控指标区

　　设计目的：提供列为监控的指标曲线变化。

　　设计理念：记录慢性病或者传染病的病情变化是卫生人员提供服务的基础，而不同疾病和不同居民需要监控的项目并不相同，所以根据不同疾病，提供了不同的病情流程表，依据病情流程表中的监测指标绘制监控指标曲线。

　　设计特点：可以根据不同疾病，不同居民按照监控的要求形成监控指标区显示；同时也能够利用此系统，进行重点疾病、重点病人的回顾性以及前瞻性的医学科研数据的采集与分析工作。

　　（8）查询区：

　　设计目的：提供多种介质开启健康档案查询的需求。

　　设计理念：由于目前健康档案管理是长期的动态的管理模式，而长期动态模式需要界定居民唯一性，因此系统引进了居民主索引的管理；居民主索引是整个健康档案的基础，主索引无疑可以帮助管理居民的唯一性，而主索引需要使用介质来关联，正是由于现实生活中存在多种介质卡的模式，因此提供了多“卡”通的模式，即居民主索引信息可以关联多把“钥匙”，多把“钥匙”使用都可以开启居民的健康档案。

　　功能特点：根据我市情况，可以满足市民卡等其他多种类型卡片的管理需求。

　　4.安全及隐私要求

　　个人健康信息系统安全体系包括安全管理、安全服务和安全技术三个方面。三者互为关联，只有从整体上发挥共同作用，才能保证个人健康信息系统长期处于一个较高的安全水平和稳定的安全状态，进而确保基层卫生机构各项工作的顺利开展。

　　信息系统完整的安全体系包括以下四个层次，最底层的是物理级安全，其包括计算机安全，硬件安全等,其次是网络级安全，主要包括链路冗余，防火墙等等，再次是系统级安全包括数据灾备，病毒防范等，最后是应用级安全包括统一身份认证，统一权限管理等，而贯穿整个体系的是安全管理制度和安全标准，以实现非法用户进不来，无权用户看不到，重要内容改不了，数据操作赖不掉。

　　一、物理安全

　　物理安全是指信息平台中信息资产所处的物理环境的安全。物理安全是计算机与网络的设备硬件自身的安全和信息系统硬件的稳定性运行状态。虽然物理安全在信息安全控制中相对简单容易理解，但物理安全往往是内部人员恶意入侵的攻击链中很重要的一个起始环节，是内部安全控制中不可或失的重要方面之一。

　　二、网络安全

　　在网络安全建设中，应该考虑如下几个方面的安全保护措施：

　　1、网络基础架构安全

　　该部分包括网络结构的设计和容量，网络设备和关键设施的安全保护和使用审计等。网络结构设计和容量考虑主要应对网络按照重要性进行合理分区，并且确保关键网络设备的业务处理能力具备冗余空间，满足业务高峰期需要，以及保证接入网络和核心网络的带宽满足业务高峰期需要。网络设备安全主要应考虑对网络设备访问的安全性控制以及网络设备本身的安全考虑，比如及时发现网络设备存在的安全漏洞，并且防范攻击等等。尤其是当网络中存在无线接入设备的时候，一定要对无线接入设备的安全性进行评估和控制。

　　2、网络安全控制

　　该部分包括网络访问控制，网络入侵防御等主要控制措施，即首先保证网络访问行为合理可控，然后再对网络中的一些非法行为进行识别和阻挡。

　　网络访问行为合理可控包括：能够根据用户、网络会话状态对通过网络对资源的访问行为进行明确的允许和拒绝；能够对内部用户未经允许私自连接到外部网络的行为进行识别等。能够对内部服务器和计算机由于感染蠕虫、或被种植木马后门程序而导致的向外非法连接进行识别和阻断。

　　网络非法行为识别和阻拦包括对针对网络和系统的蠕虫木马攻击、拒绝 服务攻击、入侵行为等进行识别和拦截，保障业务的安全稳定运行。

　　三、系统安全

　　在系统安全建设中，应该考虑如下几个方面的安全保护措施：

　　1、系统漏洞管理

　　系统漏洞管理和本文网络安全部分中所述的漏洞管理的目的相同，重点在于IT资产的发现和管理、漏洞评估、补救管理和策略评估结果。发现资产并评估资产的重要性，并且能够前瞻性地处理和识别漏洞；并实施基于资产的补救措施，评估并报告安全策略的符合性。

　　2、系统安全保护

　　系统安全保护重点在于通过附加于被保护系统之上的安全软件或补丁程序，对系统已知及未知的弱点进行保护，对蠕虫、病毒、木马等恶意代码进行防范。当由于某些关键系统之上应用软件兼容性或变更管理的原因导致无法应用补丁程序的时候，也需要考虑对关键系统的安全保障措施。

　　3、身份鉴别和安全审计

　　应对登录系统的用户进行身份标识和鉴别，并且其身份标识应具有不易被冒用的特点。登录失败时，可采取结束会话、限制非法登录次数和自动退出等措施；同时应该对系统操作进行审计，内容包括重要用户行为、系统资源的异常使用和重要系统命令的使用等系统内重要的安全相关事件；审计记录应包括事件的日期、时间、类型、主体标识、客体标识和结果等；应保护审计记录，避免受到未预期的删除、修改或覆盖等。

　　四、应用安全

　　个人健康管理信息系统应用级安全包括统一身份认证,统一权限管理等,系统软件和应用软件应具有访问控制功能，包括用户登录访问控制、角色权限控制、目录级安全控制、文件属性安全控制等；系统软件(包括操作系统，数据库等)和应用软件等应定期进行完全备份，系统软件配置修改和应用软件的修改应及时备份，并做好相应的记录文档；及时了解系统软件和应用软件厂家公布的软件漏洞并进行更新修正；应用软件的开发应有完整的技术文档，源代码应有详尽的注释。

　　个人健康管理系统使用系统应用安全体系的架构分为三个部分：身份认证基础设施，应用安全管理系统，应用安全中间件。

　　身份认证基础设施是整个系统的基础,平台整合了数字证书，用户密码模式，动态口令卡，手机动态密码等多种身份认证模式，并支持接入广东省卫生厅准入的CA机构。

　　应用安全管理平台是基于多种身份认证模式对涉及医疗卫生安全要素的统一管理，要包括统一身份管理,医疗卫生角色管理，卫生信息资源管理，医疗卫生授权管理等。

　　应用安全中间件是基于身份认证基础设施和应用安全管理平台，将医疗卫生安全应用以独立中间件服务的方式提供给医院，社区等医疗卫生信息系统使用，从而完成统一的电子健康信息网络安全应用平台的构建.这些中间件主要包括关于身份认证服务的中间件,关于数据安全服务的中间件，关于医疗行为审计服务的中间件。

　　五、数据安全

　　在数据安全层面，主要需要考虑数据丢失和数据泄漏两个方面的威胁。数据丢失防范主要依靠数据备份等机制完成，数据库应设置预定的备份策略进行本地备份，有条件的可做异地备份。制订数据库系统备份和恢复方案时，必须将重点放在防范用户失误和介质失效而造成的数据损失。个人健康管理应用应采用专业的备份软件为整个网络中的服务器和工作站提供高速、可靠的备份和恢复能力。

　　六、安全管理

　　建立安全保密制度，设定有关管理人员调阅、复制、打印使用信息的相应权限，建立信息使用日志，记录使用人员、操作时间和内容。未经授权，任何单位和居民不得擅自调阅、复制相关系统。同时，建立健全信息使用的相关制度和规程，包括人员操作、系统维护和变更的管理流程，出现系统故障时的应急预案等。

　　5.建设周期

　　本项目应于2014年12月31日前完成项目开发及实施工作，实现项目成果，并通过验收。

　　项目成果应包括：

　　1.南通市个人健康管理浏览器及相关项目文档

　　2.南通市个人健康管理服务开发包及相关使用文档（须通过用户方认可的第三方机构的专业化测试）

　　3.至少一家医疗卫生单位实现个人健康管理服务的本地化应用

　　注：开发商必须承诺以下事项：

　　1.开发商需承诺提供软件工程师驻南通市卫生局现场开发、安装、调试等服务；

　　2.开发商须承诺提供至少1人5年的驻南通市卫生局的本地质保、培训、维护、升级，且服务响应时间不得超过20分钟（驻场工程师应至少从事过3年以上南通市医院信息化实施和维护工作）；免费维护期内开发商须对所有用户方授权的相关医疗卫生、政府行政机关、电信运营商、金融等其他单位提供免费的开发包的二次开发技术支持服务；

　　3.开发商须提供南通市区域卫生信息平台Redhat Enterprise Linux Server 6.4版本5年服务，包括操作系统安调、维护、升级等。一切费用或因版权问题造成纠纷，由开发商承担；

　　3.开发商在用户方软件开发工作场所由开发商自行安排；

　　4. 南通市区域卫生交换及协调平台项目是本项目开发的数据基础，开发商可考虑提供或沿用原先提供的数据库软件。但一切费用或因版权问题造成纠纷，由开发商承担；

　　5. 开发商应在软件系统验收前提供完整的软件系统源代码、数据库表结构。开发商如不再承担本软件项目的相关维护工作，且未能提供真实、全面、可用的源代码、数据库表结构给用户方用于软件系统维护、升级或二次开发，须支付甲方标的总价的25%作为违约金，造成用户方损失的，另赔偿用户方由此引起的一切损失；

　　6.开发商应对本软件系统提供南通本地终身培训、维护及升级服务，且服务响应时间不得超过20分钟;

　　7. 投标人必须承诺中标后不得向他人转包中标项目，也不得将中标项目肢解后分别向他人转让；

　　8.投标人需提供本项目的详细的工作量清单；

　　9.本项目经费不做任何形式的追加，开发商应承诺免费承担对本系统的个性化增补或修改工作。

五、其他

　　1．签定合同日期：自采购中心中标（成交）通知书发出之日起5个工作日内签约。

　　2．交货（服务）地点：业主单位指定地点。