招标文件
招标内容及要求
第一章 建设目标
1.1实现信息共享和互联互通、推进医共体的建立和运行
遵循国际国内标准规范，整合永嘉县各医共体内各医院内部信息系统，建立统一的数据中心，实现医疗信息的共享和信息系统互联互通，推进和支撑医共体的建立和运行。辅助建立大医院带基层医院的服务模式，支撑医共体内人员培训互动和技术指导，提高县级医院和社区卫生机构的服务能力，提高医疗服务体系的整体效率。
1.2实现医疗协作和资源共享，提高医疗资源利用率
基于区域卫生健康信息共享平台，实现永嘉县内医疗设备资源、床位资源、专家资源的共享和有效利用。提高基层医疗机构首诊率，实现大病进医院、小病进社区，治疗到医院，康复回社区的目标。
1.3创新医疗服务模式，改善居民就医体验
基于永嘉县区域卫生健康信息共享平台，利用互联网、移动互联网创新服务模式，优化服务流程，不断提高永嘉县整体的服务效率和服务水平，改善居民就医体验，为居民提供安全、有效、方便、优质、价廉、分级、连续的医疗健康服务。
第二章 总体架构需求
供应商需以永嘉县区域卫生健康信息共享及区域卫生信息互联互通的目标和需求为导向，在遵循国际、国家卫健委发布的相关标准和规范基础上，建立统一的区域卫生信息数据中心和区域卫生信息服务平台，完善和整合永嘉县内各级各类医疗机构的信息系统，实现对医疗信息的全面共享、利用、挖掘和信息系统的互联互通，从而辅助和支持开展病人服务、信息共享、资源预约、双向转诊、影像会诊、综合监管等业务，推动和支持永嘉县内各医共体的建立和运行，促进医疗业务的协同和分级诊疗机制的建立健全，促进医疗资源的整合共享和高效利用，加强对医疗服务统一监管和考核，在永嘉县内建立起跨行政隶属关系、跨资产所属关系，层级清晰，布局合理，各级各类医疗机构密切协作的新型医疗服务保障体系，从而提高医疗服务的整体效益。需依托区域内卫生信息专网，建立永嘉县区域卫生健康信息共享平台，采用主动抽取模式技术，通过平台统一的集成引擎，将永嘉县内各机构的对应数据进行集中化管理，以支撑永嘉县内各项业务的开展。加强永嘉县人民医院和永嘉县中医院内部数据的集成能力，提升上传数据的质量。同时基于平台，建立全程医疗数据浏览器、医共体运营监管分析平台及跨平台的数据整合等应用服务，能够实现区域内各家医疗机构的数据和业务层面的联动，更好的支撑永嘉县整体医疗业务的开展。同时需实现区域卫生健康信息共享平台与温州市级平台实现对接，根据市级要求，提供对应数据。
需建立区域卫生信息数据中心（包括全员人口信息库、电子健康档案库、电子病历数据库、卫生计生资源库等四大数据库）和区域卫生基础信息平台，从区域内各医疗机构采集业务数据，提供医疗数据采集、共享、利用、挖掘等服务，实现永嘉县内各级各类医疗机构信息系统的互联互通，并完成与区域卫生信息平台的互联，在此基础上建立面向医院的病人共享、病历共享、双向转诊、资源预约、医技协同等医疗协作应用，建立面向卫生管理部门的运行监控、质量监管、绩效考核等综合管理应用，建立面向病人的互联网、移动互联网的创新服务应用。
第三章 技术架构需求
永嘉县区域卫生健康信息共享平台需在统一电子病历数据标准、互联互通网络环境、以及公用信息资源业务模式的基础上支撑各个医院现有信息系统，为医院各个异构系统提供数据共享、业务协同等应用服务，并为病人、医务人员、管理者提供医疗信息的统计、查询等服务。形成以电子病历为基础，信息共享、互联互通的跨院、跨部门的联动协同服务机制。
永嘉县区域卫生健康信息共享平台需基于SOA(面向服务的体系架构)的技术理念进行搭建。需采用开放的信息技术标准，如SOAP/Http/Http (s), XML/ Http (s)，JMS/MQ等。在医疗服务总线上，院内所有应用需以Services(服务)方式进行统一封装，以此来屏蔽医疗业务系统接口的异构性，达到整个医疗信息系统的规范化。封装后的业务系统需以松耦合的方式接入医院服务总线。单个业务系统既可以是Service Provider（服务提供者），也可以是Service Consumer（服务消费者）。基于SOA架构的医疗信息交换平台需同时能够以标准的数据格式，例如HL7/CDA等向院外暴露业务接口，为今后实现永嘉县内医疗信息的共享提供坚实的基础。
第四章 建设内容清单
|
永嘉县区域卫生健康信息共享平台建设清单 |
|||
|
序号 |
建设任务 |
建设内容 |
建设分项 |
|
1 |
永嘉县区域卫生健康信息共享平台 |
区域卫生信息服务平台 |
|
|
2 |
区域卫生信息数据中心 |
||
|
3 |
业务共享平台 |
注册服务管理 |
|
|
4 |
标准规范管理 |
||
|
5 |
基础服务管理 |
||
|
6 |
运行配置管理 |
||
|
7 |
数据质量控制 |
||
|
8 |
业务分析平台 |
商业智能分析平台 |
|
|
9 |
医疗服务智能分析主题库 |
||
|
10 |
公共卫生智能分析主题库 |
||
|
11 |
数据实时驾驶舱 |
||
|
13 |
业务服务一体化 |
居民健康全程健康浏览器 |
|
|
14 |
单点登录 |
||
|
15 |
|
系统接口 |
各类第三方系统接口 |
第五章 技术参数需求
5.1永嘉县卫生健康数据交换平台
5.1.1区域卫生信息服务平台
区域卫生信息平台需要通过以下组件服务实现数据交互共享，支撑分级诊疗、公共卫生、业务协同、综合管理、便民惠民等各类上层应用。
5.1.1.1数据采集与存储管理
数据采集服务
数据主动获取
由于本系统的业务需要，数据交换系统要访问的数据可能有异构的关系数据库(如Oracle、DB2、Sybase、Foxpro、Access)，还有大量的独立数据（如文件等）。通过分析，数据异构主要体现在两个方面，第一是关系型数据库异构；第二是关系型数据与独立数据异构。根据需要，我们通过实现异构的数据访问接口，制定了灵活的数据访问方案。如下图所示：
数据抽取是数据交换的一个重要部分，它负责从数据存储层抽取数据。对数据的提取范围、类型、条件定义实现的技术解决方案要做到通用化、平台化，这主要由规则配置予以支持。此外，为了满足业务需求和抽取的适应性，要支持多种抽取模式以供选择，如完整抽取、定时抽取、实时抽取等等。
主动抽取模式技术原理是通过数据库日志备份技术主动抽取数据，实时地将业务库中的数据同步到县级数据中心库，同时可以对数据进行转换处理，将转换后的数据写入到专用的数据集市中，以供其他业务系统使用。该系统需要提供可配置的、可调度的和快速部署的管理工具，对数据在同步和转换中的异常要有捕捉和补偿机制，从而确保数据的最终一致性。
根据永嘉县的实际情况，本项目拟采用主动抽取数据，进行准实时的全诊疗业务库数据备份同步（影像数据除外），后通过数据抓取方式将进行数据处理的数据统一采集至县卫建局诊疗数据中心。
数据采集无需任何接口改造，仅在数据库服务器安装基于数据库的原生备份工具插件即可，对于数据库自身性能不造成影响，同时能够保障县级数据中心端的数据与源数据完全一致，确保数据完整性。
1、主动抓取模式总体功能
（1）日志解析：负责读取目标端日志文件中的内容，并将其解析为DML或DDL消息；解析DML/DDL消息。
（2）重传恢复：内部的checkpoint机制，保证进程重新启动后可以从上次记录的位置开始恢复，而无数据损失的风险。
（3）业务逻辑转换：目前，医疗领域的业务数据来源多样化，有的业务系统的数据可能来源于不同的厂商，由于这些客观原因的存在，就需要通过数据转换平台，将异构的和多样化的源数据转换成统一的数据结构，数据实时转换平台，提供人性化的web设计界面、可靠的数据转换和精准的数据监控，保证了业务数据实现准确无误的转换。
（4）消息总线控制：将DML、DDL消息用分布式系统分类保存，高可用性，高吞吐量；消息及时存盘，定时自动销毁，类目删除；提供消费接口供后端转换任务消费。
（5）数据转换与清洗：兼容kettle的转换和任务定义；
（6）B/S架构集群式执行；转换和任务绘制、定制页面；任务定时调度、状态监控、管理。
2、主动抓取模式数据汇集方案
（1）数据库日志解析:通过读取源端生产系统数据库（Oracle、Sybase等主流数据库）中的日志获取变化数据，经过内部解析和转换，再根据TCP/IP协议发送并快速应用到目标端（BDB），完成异构数据的实时同步过程。
数据库日志解析：生产系统数据库（Oracle、Sybase等主流数据库）日志解析。
日志解析存储：将各种数据库日志解析后生成中间统一日志格式存储。
（2）主动异构数据源抽取:在各个医院、基层医疗等生产系统中，实时监控关系数据数据库日志变化，通过数据库事件解析数据库日志，降增量数据转化为XML文件格式的数据以生产者的角色发送到Kafka消息队列之中，供存储端服务进行消费。实现数据实时ETL。
日志抽取：从源端数据库的在线日志或者归档日志捕获源端数据的变化。
分布式消息队列处理:分布式发布订阅消息系统中的分布式消息队列是数据平台架构中的关键组件。在结合了数据挖掘，数据分析和数据监控等需求的情况下，能够满足各种实时在线和批量离线处理应用场合对低延迟和批量吞吐性能的要求，它具有分布式、高吞吐、低延时和支持多种语言接口等优势。系统一边接收生产端发生的消息，一边由消费端源源不断地按序消费，它保证了数据流的实时性、连续性和稳定性。总体而言，系统试图提供一个同时满足在线和离线处理海量数据的消息派发。
解析管理：启动、监控、重启的其他进程；报告错误及事件；分配数据存储空间；发布阈值报告。
（3）数据流转换模块:数据流转换模块是基于B/S架构的，集大数据任务设计、部署和执行等功能为一体的数据流转换软件套件，支持图形化的同步、转换和装载等任务的设计部署和执行，并且提供任务的远程执行和监控功能，实现对平台内所有执行主机的统一管理和监控。
基于B/S架构的平台具有轻客户端的特点，使用者只需要安装一个浏览器就可以使用平台，不需要过多的操作系统适配，具有更好的平台适用性，并且对于系统自身来说，维护和升级过程也更加便捷，具有更好的可维护性。
在多台执行主机上执行不同的任务，可以充分的利用平台的计算资源，灵活均衡任务的负载。在机器资源充足的情况下，支持执行机器的横向动态扩展，可以方便的满足不断增长的任务的计算资源需求。
结合了kettle的设计思想，完全兼容kettle的转换和作业，kettle设计好的转换或作业可以直接在平台上部署执行，具有优秀的平台适应性和通用性。
在同步/转换任务的执行过程中，如果任务进程意外中断，平台会在中断的位置为任务设定重新同步的恢复点，在任务中断原因排除之后，在进行数据的重新同步时，会从恢复点重新开始同步/转换，保证数据的最终一致性。
另外，平台还提供对分布式关系数据库的支持，包含了对数据库的jdbc等连接的原生支持，可以通过平台组件，直接对数据库内数据进行各类sql同步/转换的操作。
在基础的数据和汇总的数据的基础上，进行数据关联加工，以支持应用需求所需要的数据。其实现的功能如下：
将数据加工抽象成5大类基础层函数库，通过可视化的函数流程编排，实现数据加工功能。
变量管理。支持预设的全局变量、自定义的全局变量和运行时的变量。
函数管理。支持预设函数，自定义函数。可以通过shell、java、tcl等扩展函数。
可视化函数流程编排。支持条件、循环等流程设置。支持导入，导出等功能
支持常见各种类型数据库。如oracle，sybase，sqlserver、db2、mysql。包括分布式关系数据库。
支持复杂的规则引擎处理。
灵活的运行方式。可以从开始节点运行，也可以从上次运行错误点开始运行元数据管理。支持数据模型、数据流程、转换规则、关系分析。
项目数据采集与交换范围主要包括：
永嘉县级医疗机构（永嘉县人民医院、永嘉县中医院、永嘉县妇幼保健院）相关系统、基层区域HIS相关系统、居民电子健康档案系统等。
数据采集与交换平台承担着数据采集与整合的职责，需要将来自相关医疗卫生机构的数据进行汇总、清洗、优化以及聚合之后再按信息消费者需要的形式展现出去。采集信息大致分为医疗服务数据、医疗保障数据、公共卫生数据、健康档案数据、专题业务数据以及业务运营数据6大类，具体内容如下：
（1）医疗服务数据
医疗服务数据来源于医院内部信息系统（如HIS、LIS、RIS、CIS系统）。项目将在统一标准的前提下，实现医疗服务数据在平台上的汇聚。
医疗服务业务涵盖门诊类业务和住院类业务。门诊类业务是指：普通门诊、急诊，专家门诊，特需门诊，专科门诊；住院类业务是指：普通住院、急诊观察，特需住院。患者是指获得医疗服务的人，涵盖持社保卡、农合卡以及院内就诊卡等就医的就诊人员。
医疗服务数据采集主要包括患者基本信息、患者就诊履历、实验室检验报告、影像诊断报告/影像图像数据、住院相关病历、门诊/住院诊断报告等。
● 患者基本信息
患者基本信息可以在医院挂号或入院登记环节从患者就医电子凭证中获取，并集中形成共享信息资源。但需逐步收集（因为居民不一定成为就诊患者）。同时，还可以从其它三个方面获取居民的基本信息——首先，与健康档案系统交换数据；其次，与全员人口系统交换数据；第三，公共卫生数据中的居民基本信息，以此形成居民健康档案的居民核心信息。
● 患者就诊履历
对于所有就诊患者，要求医院参照约定方式（格式和内容）形成患者就诊履历。具体采集内容包括：
就诊记录：就诊记录表示患者一次门诊或住院过程中的信息；
收费明细：收费明细中的收费信息主要根据收费单据细项进行罗列；
收费记录：收费记录中的收费信息主要针对医保支付费用进行描述。
● 实验室检验报告
各医院向平台提交实验室检验报告的业务环节不能对日常作业流程造成影响或变动。仅增加一个定时的自动作业，向医院前置机约定的目录下归档检验报告。
● 影像诊断报告
各医院向平台提交影像诊断报告的业务环节与提交实验室检验检查报告的过程相同，对日常作业流程不会造成影响或变动，仅增加一个定时的自动作业，由医院RIS系统向医院前置机约定的目录下归档报告。
住院相关病历
各医院向平台提交住院病案报告的业务环节对日常作业流程不会造成影响或变动。仅增加一个定时的自动作业，向医院前置机约定的目录下归档病案报告。技术实现方式上与前述实验室检验报告的提交完全相同。
采集的数据包括病案首页和出院小结，涵盖手术、实验室检验、影像检查等诸多方面的信息。
● 门诊/住院诊断报告
住院诊断报告的获取方式与住院相关病历的获取方式一样，技术实现方式上与前述实验室检验报告的提交完全相同。
（2）医疗保障数据
医疗保障数据是指医保/新农合参保人员在医疗机构发生的诊疗交易数据。医疗保障数据来源于医院HIS系统，业务涵盖门诊类业务和住院类业务。数据包括了诊疗记录数据、门诊挂号数据及收费明细数据、住院出入院数据及收费明细数据等六大类。
诊疗记录数据：交易记录是参保人员在医疗机构进行一次就诊的记录数据。
● 门诊、大病挂号数据
● 门诊、大病、家床收费明细数据
● 住院出入院数据
● 住院收费明细数据
● 出院诊断数据
（3）公共卫生数据
公共卫生数据是在妇幼保健所、社区卫生服务中心（站）、乡镇卫生院等专业机构的日常业务中产生，主要包含疾病管理、预防保健、计划免疫等内容。
● 传染病信息（含肺结核）
传染病信息主要包括对传染病患者进行报告、日常随访记录等。
● 慢病专案信息
慢病专案信息主要包括对慢病患者进行日常随访和管理的信息等。
● 妇女保健信息
妇女保健信息主要包括孕产妇信息、产褥期信息、更年期信息和健康检查信息等。
● 儿童保健信息
儿童保健信息主要包括儿童的健康体检、生长发育监测、评价和干预信息等。
● 计划免疫信息
计划免疫信息主要包括儿童基本信息，提供接种人信息管理、接种管理、副反应登记、针次维护、计免报表等。
● 重性精神病信息
● 职业病管理信息
● 食品安全监测信息
（3）健康档案数据
● 健康档案信息
健康档案信息主要包括社区档案、家庭档案和个人档案三类。
社区档案：社区基本资料（行政区划、人口学情况、社区环境和经济状况、人力资源及文化资源等）、社区平面图（社区、居委会、街道，交通、医疗机构、公共设施的分布情况等）；
家庭档案：家庭住址、人数及每人的基本资料、家族疾病史、建档医生和护士姓名、建档日期等；
个人档案：个人基本信息、既往史、行为危险因素、过敏史等。
老年人保健信息
老年人保健信息主要包括老年人专项档案管理信息、随访管理信息等内容。
● 健康体检信息
健康体检信息主要包括体检人历次体检的具体信息。
● 健康教育管理信息
健康教育管理信息主要包括健康教育活动计划管理、健康教育活动实施情况记录、健康教育活动效果评估。
● 中医药健康管理信息
（5）专题业务数据
根据专项管理要求，实现对各医疗单位对应主题管理系统数据的采集，主要包括：
● 双向转诊信息
提供患者个人基本信息、转出科室、转出医生、转入科室、转入医生等信息。
● 全科签约服务信息
提供签约患者健康档案信息、签约医生基本信息和服务项目等信息。
● 满意度综合管理信息
提供医生个人基本信息、满意度状态及分值等信息。
（6）业务运营数据
全民健康信息平台获取的医疗机构业务运营数据主要包括以下几类：财务与经营、医疗统计、监督管理、绩效考核、人力资源管理。
具体包括：
机构基本情况：包括基本信息、床位、职工构成、建筑物、设备、资产负债、年收入支出等；
人力资源基本信息：个人基本信息、专业情况、执业情况、专业培训等；
卫生机构设备信息：购置日期、价格、使用年限、年检查治疗标本数等；
卫生机构运营情况：专科特长、等级、分科床位数、医疗卫生服务情况等；
社区卫生服务中心/站、诊所、卫生所、医务室的运营情况；
● 医院排班情况；
● 医院号源动态分配情况；
● 医院分科床位动态使用情况；
● 医院检查检验设备动态使用情况；
● 医院手术室使用情况等。
交换服务
功能目标定位
● 为用户和上层应用提供统一的数据访问视图和数据处理。
● 为现有应用服务提供服务包装功能。
● 为上层应用提供统一的消息收发服务。
● 为用户解决复杂的数据交换和处理提供易用的、可扩展的解决方案。
消息集成服务
● 消息集成是应用整合的基础，消息传送为系统间特别是异构的系统间的应用整合提供通讯基础。消息传送的功能包括：消息收发、消息安全、消息地址、消息路由、消息转换等。
● 支持点对点通讯。消息发送应用可以向定点的目标系统发送消息。
● 支持点对多点通讯。消息发送应用可以同时向多个目标系统发送消息。
● 支持同步发送模式。消息发送应用可以以同步的方式向目标系统发送消息，● 这种模式保证消息发送完成后才将应用控制权交给消息发送应用。
● 支持异步发送模式。消息发送应用以异步的方式向目标系统发送消息，这种模式下，消息发送指令执行后立即将应用的控制权交给消息发送应用。
● 支持请求/响应消息交互模式。请求响应模式是远程服务调用中一种最基本的模式，消息收发功能提供了对这种模式的支持，消息发送者可以发送完请求消息后获取目标系统对请求消息的处理结果消息。
● 支持通知消息交互模式。通知消息交互模式是消息应用向目标系统执行信息公告的交互模式，目标系统接收到通知类型的消息可以根据业务需求自行处理。
支持回执消息交互模式。回执的交互模式要求消息的收到方在收到消息后给发送方一个收到确认消息。
● 支持消息携带附件发送。一个消息可以携带任意数量和大小的附件进行发送，对于大附件，消息收发会自动进行文件切割发送和收到数据组装的工作，方便消息收发应用对大数据的交换处理。
● 支持丰富的消息连接器类型，如socket，ftp，smtp，jms，vm，file，soap等。连接器是系统互联部分的重要服务，通过它系统外界进行通讯的通道。连接器管理可以让管理人员自定义各种类型的连接器，并且在系统中注册这些连接器。对于已有的连接器也可以根据实际的环境变化进行动态的删除和参数调整。
服务集成
服务集成是交换节点间采用服务调用的方式完成彼此间数据的发送和接收的过程。在服务集成中服务调用仅指具有远程能力的服务调用，例如：xml-rpc、web services、ejb、dcom、corba等。
服务集成的目标指数据交换平台能够以统一的方式完成服务调用。
数据集成服务
数据集成是完成对分布在网络上的各种数据提供统一访问和处理的功能，它主要包括提供统一访问的数据网格服务和面向复杂处理的数据处理服务。另外，作为支撑模块在数据集成中还包括元数据访问的服务。主要的功能特点如下：
提供丰富的元数据服务功能。
● 支持灵活的数据采集服务。
● 支持数据转换。
● 支持数据分发。
流程集成服务
流程集成服务是指采用统一流程模型语言描述复杂数据交换过程，并且在流程活动中内置支持多种类型的内置服务，例如：消息收发、数据处理、服务调用等。整个建模支持可视化工具建模，同时对于正在交换的流程可以监控。
存储服务是一系列存储库，用于存储健康档案的信息。根据健康信息的分类，存储服务分为七个存储库：居民基本信息存储库、主要疾病和健康问题摘要存储库、儿童保健存储库、妇女保健存储库、疾病控制存储库、疾病管理存储库以及医疗服务存储库。
存储服务除了对POS和业务协同平台提供健康档案的访问服务，也承担将来自POS和业务协同平台的业务文档按照健康档案的数据模型解析和封装为健康档案文档。卫生数据交换平台中存在三种类型的数据，文档数据、操作型数据、数据仓库数据，分别存在文档库、ODS库和数据仓库中，本次项目参考国际标准的通用EHR存储模型，以支持EHR的灵活扩展。为保证与永嘉县级卫生数据交换平台良好互联，健康档案存储服务遵循IHE ITI XDS规范。
本方案中健康档案存储等需完全符合卫生部《基于健康档案的区域卫生信息平台建设技术解决方案（试行）》健康档案的三维模型和基本信息、健康摘要和五大类卫生服务记录信息内容。
健康档案存储服务是一系列存储库，用于存储健康档案的信息。根据健康档案信息的分类，健康档案存储服务分为七个存储库：个人基本信息存储库、主要疾病和健康问题摘要存储库、儿童保健存储库。
存储逻辑架构要求
本方案卫生信息资源中心所存储的档案逻辑构架需参照了开放式电子健康档案（Open Electronic Health Record）理论中的逻辑构件关系。OpenEHR是一种具有开放性、共享性的健康信息处理平台，其利用传统的、书面的健康记录/档案，将现代计算机技术和卫生保健领域的专业知识进行整合，从而建立起一种能提供统一格式的信息体系，以利于信息使用者能方便地理解或共享这些信息。
标准化健康档案逻辑构件关系在参照了OpenEHR理论中各逻辑构件之间的关系后，将个人健康档案中各种信息之间所具有的简单或复杂的层级关系进行结构化，从而形成了健康档案的逻辑构架。在整个逻辑构架中，主要包括的逻辑构件有摘要（Extract）、文件夹（Folder）、文件（Composition）、文件段（Section）、条目（Entry）、聚合（Cluster）及数据元（Element）。
存储模型要求
基于卫生数据交换平台中存在三种类型的数据，文档数据、操作型数据、数据仓库数据，分别存在文档库、ODS库和数据仓库中。
（1）EHR文档库
▶ EHR存储以技术手段分类主要由索引存储、数据库存储、文件存储构成。索引存储是以索引文件的方式进行存储，其具体表现为以目前的搜索方式组织的文件存储，在实际运行过程中，将频繁调用的索引将被加载在内存中，减少磁盘读写频率；
▶ 数据库存储是当前最常用的存储方式，采用目前主流的大型数据库存储方式，主要存储已经被结构化的数据，这些数据将被迅速定位统计，ODS库主要以此方式进行存储；
▶ 文件存储是以文件系统方式对EHR中文档、影像信息进行存放，文件存储可以减少数据库存储中其他多余的运算和磁盘开销，直接依赖文件系统，提高EHR中心对大容量数据的吞吐能力.
（2）ODS库
▶ ODS数据库（操作型数据库）主要是作为EHR存储外的业务需求的补充。除了EHR信息外，在EHR数据中心还需要支持一些其他业务，比如说CDC的疾病健康，妇幼所的围产保健等具体医疗业务，这些业务所需的一些信息可以从EHR中抽取，但是同时另一部分信息可能和健康信息毫无关系只是为业务统计分析时使用，他们也有一定的业务流程，辅助存储就是为此类数据的存放场所。
▶ ODS数据库还包含对这些业务数据的汇总、展现、统计功能的支持，
▶ ODS数据库仅仅是一个单纯的存储服务，他可以依赖健康档案全程索引服务实现共享和使用EHR信息中已经存储信息的展示。
▶ ODS数据库既可以被用来针对工作数据做决策支持，又可用做将数据加载到数据仓库时的过渡区域。
▶ ODS是面向主题和面向综合的；
▶ ODS是易变的；
▶ ODS仅仅含有目前的、详细的数据，不含有累计的、历史性的数据。
（3）数据仓库
数据仓库提供用户用于决策支持的当前和历史数据，这些数据在传统的操作型数据库中很难或不能得到。数据仓库技术是为了有效的把操作形数据集成到统一的环境中以提供决策型数据访问，的各种技术和模块的总称。所做的一切都是为了让用户更快更方便查询所需要的信息，提供决策支持。
数据仓库由三个部分组成：数据仓库数据库、数据抽取工具和数据挖掘工具。
▶ 数据仓库数据库：是整个数据仓库环境的核心，是数据存放的地方和提供对数据检索的支持。相对于操纵型数据库来说其突出的特点是对海量数据的支持和快速的检索技术。
▶ 数据抽取工具：把数据进行必要的转化、整理，再存放到数据仓库内。数据转换都包括，删除对决策应用没有意义的数据段；转换到统一的数据名称和定义；计算统计和衍生数据；给缺值数据赋给缺省值；把不同的数据定义方式统一。
▶ 数据挖掘工具： 数据挖掘工具利用数据仓库中的大量数据中获取有效的、新颖的、潜在有用的、最终可理解的模式的过程。
数据抽取工具将会直接使用Data Service、LDS和Registry Service的Web Service接口，通过他们读取所需的数据，通过数据抽取工具的整理之后，存入数据仓库数据库。对于数据的分析将直接面向数据仓库数据库中的数据，对中心其他服务的运行没有影响。
数据的挖掘功能，开发运营人员可以使用成熟产品中数据挖掘工具，制定相应分析模型，通过数据挖掘工具的报表和图形功能来读取结果，或者继续调整模型来得到更准确的结果。
存储模式要求
▶ 卫生数据交换平台涉及到与居民卫生相关的所有业务，因此其业务数据具有类型多、容量大的特点。根据业务数据的特点，对数据存储的要求也不尽相同。在实际业务中，可采取集中存储、分布存储或者两种模式混合存储的方式。
数据库存储处理有集中存储处理和分布存储处理两种模式，集中存储是在统一的卫生信息资源中心对卫生范围内的数据进行统一存放，此方式主要以文档性数据为主；
▶ 分布存储是在卫生信息资源中心考虑其存储容量以及网络带宽情况，对大文件内容以及无法结构化且调用频度很低的健康档案内容采用的存储方式，中心对这些文件的位置以及主要属性信息进行索引存储，而不在卫生信息资源中心存储其实体数据，需方在进行调用时，通过数据中心索引寻找其文件位置，然后加载到卫生信息资源中心，再提供给内容需求方使用。
全程健康档案服务用于处理平台内与数据定位和管理相关的复杂任务。该服务包括相关的索引信息，这些索引将不同存储服务所保存的数据链接到一个特定的个人、医疗卫生人员、医疗卫生机构，实现共享及协同应用的实时响应、快速调阅，支持IHE ITI XDS Registry规范。
全程健康档案服务知晓所有的事务和业务逻辑以及数据访问规则的部件，它可以围绕任何数据主题汇集出真正的全程和综合的健康档案视图。同时全程健康档案服务可提供自动或手动的健康档案维护功能，包括由于居民身份唯一性识别的人工处理所带来的健康档案合并与拆分的操作。
索引服务全面掌握区域卫生信息基础平台所有关于居民的健康信息事件，包括居民何时、何地、接受过何种医疗卫生服务，并产生了哪些文档。索引服务主要记录两大类的信息，一是医疗卫生事件信息，另一为文档目录信息。
各级医疗卫生机构用户在被授权的情况下，可以通过全程健康档案服务提供的索引服务通过县级平台查看某居民的健康事件信息，以及事件信息所涉及的文档目录及摘要信息。进而可以实现文档信息的即时展示，使用户更多的了解居民（患者）既往的健康情况，为本次医疗服务提供相应的辅助参考作用。
健康档案管理服务
健康档案管理服务需包括档案管理功能、文档注册功能、事件注册功能以及索引服务功能。档案管理功能对健康档案的全生命周期进行管理，包括建档、注销、属地变更等。
5.1.1.1.1.1健康档案存储服务
需提供针对居民个人健康档案信息和诊疗服务记录的存储方案，提供针对医疗机构的基本公共卫生服务和医疗服务情况的数据存储服务方案。永嘉县区域卫生健康信息共享平台需要存储的数据库包括：卫生信息标准数据库、电子病历资源库、居民健康档案库、卫生综合管理资源数据库。
健康档案调阅服务
提供标准健康档案调阅浏览器。健康档案浏览器是一种特殊类型的PoS应用软件，被称为通用EHR访问工具，向医疗专家提供其客户的电子健康记录中可用信息的集成化和综合视图。EHR浏览器提供的软件能使经授权的最终用户登录到EHR信息结构上并访问其服务客户的EHR。
健康档案浏览器是为终端用户提供的基于Web的访问健康档案的应用程序。健康档案浏览器的目标是建立一个用户友好的环境，在该环境下授权的医疗卫生人员可以方便地访问卫生数据交换平台中保存的客户相关数据。卫生数据交换平台由七个域系统组成，每一域针对特定的医疗卫生人员。例如，儿童保健域服务于儿童保健人员的需求，处方药品域服务于开处方的医生和调配处方的药剂师的需求。每一个域的解决方案都提供一个终端用户的接口能力，以特别用于域相关的数据集和特殊的功能。
EHR的通用的需求包括：
（1）健康档案浏览器的显示窗口可以被嵌入Windows平台的应用程序。
（2）健康档案浏览器可以引用所被嵌入的应用程序的验证机制，直接通过Provider Registry的映射完成验证。
（3）健康档案浏览器的认证和Consent是直接通过中心的服务完成，与所嵌入的应用程序的配置无关。
（4）健康档案浏览器可以引用所被嵌入的应用程序的当前病人信息，通过Client Registry读取相关记录。
（5）可以通过卫生数据交换平台来搜索、访问病人的全面的医疗记录。
（6）健康档案浏览器可以对病人医疗记录进行重新排序、归类等工作，但不能直接更新医疗记录。
（7）所有调阅信息是通过中心的服务得到，不能直接调阅所嵌入的应用程序的本地数据。
健康档案浏览器的实现直接是通过一个Windows平台的IE控件实现。在启动时，用户的认证信息和所调阅病人的信息等都是通过HTTP Metadata的方式传送至中心服务器。中心服务器将协调View的HTTP调用到中心所对应的Web Service服务。
县级平台作为全县的协作中心，需要基于企业服务总线(ESB)建立统一的服务管理，针对来自于各医疗机构的应用服务范围和版本进行注册及管理，构建全县全民健康服务资源池，使其由原本仅供独立平台或系统使用的服务转换成为可面向全县各类全民健康服务系统调用的公用服务。服务管理的目标除了统合异构平台服务之外，也可实现服务的统一发布，任何渠道（医生工作站、APP、服务窗、公众号、网站等）不必和具体的平台或系统直接发生调用关系，均可通过服务管理实现对所需服务的调用，从而在平台发布策略管控前提下实现服务发布的公开、公平、公正，提升资源利用效率。
ESB针对医疗卫生数据分布的零散性、医疗卫生系统的异构性及业务协同交互的复杂性，提供了一整套共享服务的配置、发布、订阅、部署及互联互通的解决方案及产品实现。在目标上，通过共享服务的部署和执行提高了各个医疗卫生系统的信息共享和业务协同的能力；在治理上，通过简便易操作的管理系统提高了运维人员对共享服务落地的管理、配置及监控的日常工作效率；在技术上，将微服务的架构模式通过执行引擎低侵入的引入现有的医疗卫生系统的交互之中，即减少了系统互操作的耦合性，又灵活得可以满足日后更多的复杂交互方式和变化。详细技术要求参数如下：
|
序号 |
指标项 |
功能特点及技术规格指标 |
|
1 |
产品厂商资信 |
具有软件著作权登记证书 |
|
2 |
框架结构 |
采用分布式架构设计，所有引擎均以集群方式部署，支持集群动态伸缩、保证高吞吐环境下系统高可用。 |
|
体系结构由运行ESB中心端（服务配置及可视化监控中心）、ESB引擎（服务转发、报文协议转换、报文格式转换、并发控制、超时/失败熔断）、日志计算引擎（统计分析计算）、日志传输通道（日志流量削峰）组成。 |
||
|
3 |
跨平台支持 |
基于java开发，支持HP-UX、IBM AIX、SUN SOLARIS、Linux、WINDOWS 2000/2003等主流操作系统平台。 |
|
4 |
服务接入 |
支持HTTP、HTTPS等传输协议互转。 |
|
支持SOAP、SOAP_TEXT、XML、XML_TEXT、JSON等报文协议互转。 |
||
|
支持GET、POST、DELETE、PUT等HTTP方法互转 |
||
|
支持报文数据格式的灵活转换，可对复杂格式数据增加数据节点、删除数据节点、修改数据节点等操作。 |
||
|
支持常见的数据编码字符集。 |
||
|
支持目标服务负载均衡配置，可根据指定负载算法进行服务负载。 |
||
|
支持并发限制配置，保护目标服务不因为突发大流量请求导致服务崩溃。 |
||
|
支持动态路由，服务发布实时生效。 |
||
|
支持目标服务URL参数、PATH参数、HEADER参数转发配置。 |
||
|
5 |
服务开发 |
服务无需任何改造可直接发布。 |
|
操作本平台无需学习任何额外的语法、语义等表达式。 |
||
|
历史遗留服务调用迁移至本平台时，只需调用方在HTTP请求头增加签名认证信息即可（平台安全及调用分析需要）。 |
||
|
6 |
管理监控 |
ESB引擎健康状况视图 |
|
服务发布、调用依赖关系总览 |
||
|
服务运行状态监控 |
||
|
总体服务调用情况分析，如调用次数、调用耗时等。 |
||
|
总体服务调用失败分析，按失败类型分析。 |
||
|
对每个服务调用情况分析，如调用次数、调用耗时等 |
||
|
对每个服务服务调用失败分析，按失败类型分析。 |
||
|
7 |
安全机制 |
支持IP白名单 |
|
支持请求签名认证 |
||
|
支持响应报文字段过滤 |
||
|
8 |
产品扩展性 |
提供请求各阶段扩展插件机制，可实现指定接口后动态配置实现个性化需求。 |
|
9 |
产品部署 |
支持单机部署 |
|
支持集群部署，并实现负载均衡 |
本项目采用分布式部署、集中式管理的模式。在分布式部署方案中，部署在机构本地的前置机服务器通过数据采集的方式获取原始数据，在前置服务器上建立预处理数据库。ETL工具通过数据清洗、转换等方式将机构的非标准数据转换成标准化数据，数据质量控制管理软件将对数据的输出提供分析报告，各机构可对医院数据上传质量、数据上传情况等进行实时的查询，通过ETL工具可对数据的采集、清洗、上传等进行可视化管理。同时ETL工具将提供数据填报功能，将基本数据集所要求但在现有业务系统中没有的数据项收集上来。前置机服务器通过网络接入椒江区全民健康信息平台卫生数据中心的资源数据库，椒江区全民健康信息平台卫生数据中心部署远程运营管理客户端，可对机构端采集平台进行远程监控和管理，可对医院数据上传质量、上传情况等进行综合排名等应用。
数据转换
以组件化的方式实现数据转换。常用的数据转换包括字段映射、数据过滤、数据清洗、数据替换、数据计算、数据验证、数据加解密、数据合并、数据拆分等。提供便捷的数据映射工具，支持模糊匹配与人工确认，大大降低数据映射的工作量。
对采集的数据可以以多种方式进行数据转换，从而将抽取的数据转换成标准的数据格式，如果没有标准，可按照医院的实际要求进行数据的转换。数据转化方式将涵盖标准字典编码转换、查表转换、脚本转换、文本病历转换。
数据校验
从医院HIS、LIS、PACS等业务系统中采集及转换的业务数据，需进行统一的数据质量校验工作，才能存储到数据中心中，对校验失败的异常数据，提供校验报告，业务系统可根据校验报告中的内容进行数据调整。通过数据校验，可有效提高数据中心中的数据质量，以下是部分校验规则示例。
支持数据质量校验机制管理，定期（每日或每月）执行，并将结果保存以供查看。根据预先的配置，由系统自动对生成的数据结果进行统计，自动记录进日志。支持进行错误报警，报警功能可通过系统管理界面展现。
数据加载
将采集和转换加工后的数据装载到目的库中通常是数据采集过程的最后步骤。数据装载支持多种方式，如：直接SQL语句操作、通过标准接口完成操作、采用批量装载方法，如bcp、bulk、关系数据库特有的批量装载工具或api。
全员人口库
根据全员人口信息的基本概念和系统架构，结合国家《国家人口基础信息库建设项目（卫生计生委建设）》相关内容，全员人口信息的基本内容主要包括人口死亡、人口出生、新农合、全员人口基础信息等四大块内容。
● 人口死亡
死亡医学证明、姓名、性别、民族、职业、身份证件、婚姻状况、学历、工作单位名称、出生日期、死亡日期、实足年龄、行政区、户籍地址、现住地址、联系人姓名、家人电话号码、工作单位电话号码、直接死亡原因、发病到死亡的时长、其他疾病诊断、根本死因、主要致死疾病的最高诊断机构、死亡医院名称、死亡地点、死亡最高诊断依据、住院号、填报人姓名、填报机构名称、填报日期时间等。
● 人口出生
出生医学证明、姓名、性别、出生日期、出生地址、家庭地址、邮政编码、行政区、健康状况、母亲姓名、母亲出生日期、母亲国籍、母亲民族、母亲身份证件、父亲姓名、父亲出生日期、父亲国籍、父亲民族、父亲身份证件、出生孕周、出身身长、出生体重、助产人员姓名，助产机构名称、签发日期、签证机构名称等。
● 医保信息
相关机构数据、县/乡镇/村/组自然档案数据、家庭档案数据、个人基本数据等。
● 全员人口基础信息
人员ID、姓名、性别、公民身份号码、出生日期、民族、文化程度、婚姻状况、初婚日期、现居地址、户籍地址、变更情况等。
全员人口信息提供给县级全民健康信息平台使用，并可为医疗就诊及公共卫生相关的业务系统提供人员身份识别功能。个人注册凭借区域就医凭证包括身份证、社保卡、新农合卡、外来人员就诊卡等作为居民身份唯一性识别的需求。个人/患者注册用于对前来医院就诊患者的基本信息进行管理，通过对病患者基本信息的统一管理，可以实现对患者信息最完整的保存，可以解决患者信息在各个系统中的不一致问题，以避免重复录入患者基本信息的情况。卡号、姓名、性别、出生年月、身份证号、联系电话、通信地址、邮编。
平台将整合来自医院、公卫、妇幼和其它条线的数据，采用居民主索引（EMPI）建立居民的唯一识别号，把来自不同的、独立的系统和机构的居民标识实现统一的维护管理，并把这些信息映射成统一的标识。通过居民身份提交、居民身份注册、居民身份匹配、居民身份变更通知、居民身份检索等完成。
健康档案信息库主要实现对全区居民的电子健康档案的集中存储、应用和管理。
按照国家卫计委《健康档案数据集》标准的要求，健康档案信息库要求包括个人基本信息存储域、主要疾病和健康问题摘要存储域、儿童保健存储域、妇女保健存储域、疾病控制存储域、疾病管理存储域以及医疗服务存储域等七大信息域的数据。
这些健康档案数据集中存储到全民健康信息平台上后都需要对居民的主索引进行有效关联，形成以该居民为中心的全程健康档案管理和服务。
根据健康档案的基本概念和系统架构，健康档案的基本内容主要由个人基本信息和主要卫生服务记录两部分组成。
包括人口学和社会经济学等基础信息以及基本健康信息。其中一些基本信息反映了个人固有特征，贯穿整个生命过程，内容相对稳定、客观性强。主要有：
（1）人口学信息：如姓名、性别、出生日期、出生地、国籍、民族、身份证件、文化程度、婚姻状况等。
（2）社会经济学信息：如户籍性质、联系地址、联系方式、职业类别、工作单位等。
（3）亲属信息：如子女数、父母亲姓名等。
（4）社会保障信息：如医疗保险类别、医疗保险号码、残疾证号码等。
（5）基本健康信息：如血型、过敏史、预防接种史、既往疾病史、家族遗传病史、健康危险因素、残疾情况、亲属健康情况等。
（6）建档信息：如建档日期、档案管理机构等。
健康档案与卫生服务活动的记录内容密切关联。主要卫生服务记录是从居民个人一生中所发生的重要卫生事件的详细记录中动态抽取的重要信息。按照业务领域划分，与健康档案相关的主要卫生服务记录有：
（1）儿童保健：出生医学证明信息、新生儿疾病筛查信息、儿童健康体检信息、体弱儿童管理信息等。
（2）妇女保健：婚前保健服务信息、妇女病普查信息、计划生育技术服务信息、孕产期保健服务与高危管理信息、产前筛查与诊断信息、出生缺陷监测信息等。
（3）疾病预防：预防接种信息、传染病报告信息、结核病防治信息、艾滋病防治信息、寄生虫病信息、职业病信息、伤害中毒信息、行为危险因素监测信息、死亡医学证明信息等。
（4）疾病管理：高血压、糖尿病、肿瘤、重症精神疾病等病例管理信息，老年人健康管理信息等。
（5）医疗服务：门诊诊疗信息、住院诊疗信息、住院病案首页信息、成人健康体检信息等。
EHR数据库的组织形式以个人健康档案为核心展开，其存储结构方式更多的以个人基本索引模式组织展开，以结果数据为主体，这样的组织形式在以个人视角所见的健康档案中能够完整迅速的定位。
按照统一标准建立居民健康档案，加强规范化管理，针对居民健康档案实施分级管理模式，提高健康档案质量。并对历史居民健康档案数据按照规范化要求进行清洗，并整理进健康档案数据库。
针对业务数据来源多样、原始数据质量参差不齐、数据缺少比较基准、缺少统一关键索引等问题，将按照如下规则进行相应的清洗工作。
1、中心端对历史数据进行清洗，清洗的规则包括：
● 字段值域清洗；
● 字段必填初始化清洗（例如某些字段在区健康档案系统中为必填，历史数据为空的，需要填默认值）；
● 字段有效性清洗，例如：身份证号有效性、社保卡/医保卡号有效性等等；
● ……
对于未通过清洗的数据（例如：身份标识重复，身份标识编码不正确等数据），作为待处理数据。
对于已经通过清洗的数据进行合并等逻辑处理；完成合并等逻辑处理的数据，由中心端统一分配唯一号，作为区健康档案初始化数据，供对外服务调用。
在日常的数据管理过程中，将对数据做常规化的管理，保证数据质量，提高数据的利用率，将采用以下有效手段实现。
系统无法根据现有处理规则对数据进行自动的转换、清洗时，会自动的将这些异常业务数据和采集时间、地点、异常类型、异常数据内容、异常情况说明等信息维护到系统中的临时库（在前置机上称为备份库），等待数据维护人员进行干预维护。
数据维护规则：异常数据的维护将按照以下规则进行。
● 或逐类的对异常数据进行人工干预；
● 对于具有通性的异常处理形成业务规则加载到异常数据处理规则中；
● 可根据新规则进行处理的异常数据，退回临时库，要求异常数据处理规则根据新的业务规则重新处理所有异常数据；
● 对于无法按照规则处理，同时人工无法进行数据处理干预的将记录数据质量缺陷，数据存入缺陷库，同时向数据的报送单位发送数据质量缺陷报告。
电子病历库
电子病历库是居民个人在医疗机构历次就诊过程中产生和被记录的完整、详细的临床信息资源，是卫生信息系统重要的组成部分，从时效性和实际业务需求出发，电子病历库存需要尽可能多的存储居民近期以及历史的就医全过程信息，并且对于这些信息的完整性、数据正确性要求非常高。
按照国家卫计委《电子病历数据集》标准的要求，电子病历信息包括病人的病历概要、门(急)诊诊疗记录、住院诊疗记录、健康体检记录、转诊（院）记录、医疗机构信息等。
这些医疗数据集中存储到全民健康信息平台上后都需要对居民的EMPI进行有效关联，形成以该居民为中心的全程医疗服务记录。
电子病历是由医疗机构以电子化方式创建、保存和使用的，重点针对门诊、住院患者临床诊疗和指导干预信息的数据集成系统。是居民个人在医疗机构历次就诊过程中产生和被记录的完整、详细的临床信息资源。电子病历内容既包括临床诊断电子文档，同时还包括各类影像检查、实验室检验报告等内容，平台采集门诊/急诊记录、检验信息、检查信息、病案首页、病程记录、体温单、手术记录、护理记录、医嘱明细信息、收费记录与明细信息等。
医疗数据整合涵盖了诊疗业务和临床信息的整合。诊疗业务与临床信息是采用一体化的方式来采集和整合的。具体来说，整个诊疗业务和临床信息是从两个维度来贯串的，横向维度是“人”，纵向维度是“时间”。“人”具体来说就是就诊患者基本信息，所有的诊疗业务与临床数据都与患者唯一索引关联。“时间”具体来说就是就诊患者每次的就诊行为，一次就诊对应一个就诊流水号。所有的诊疗业务和临床实践都与就诊流水号关联。这样患者的任何一次挂号、收费、诊断、处方包括化验均可唯一定位。
医疗数据库主要包括：患者就诊履历信息、住院病案报告信息以及实验室检验报告信息等。库中各业务数据可以按照人的视角和临床的视角有两种不同的表关联关系视图。
卫生资源库
要求建立卫生资源库，包括区域内医疗卫生机构的相关的人员信息、机构信息、科室信息、设备信息、药品信息、耗材信息、床位信息等各种卫生资源，实现对全区的卫生资源进行汇总、统计和挖掘分析，为卫生综合统计分析提供有效的支撑。
运营数据库是医共体的主要组成部分之一。运营数据库是在临床数据、医院管理类数据以及财务类数据采集的基础上对各类数据进行归类整合，并加以数据挖掘分析利用。
运营数据库数据来源于医共体内各业务领域中实际产生的业务及管理数据，同时通过分析系统实现对管理、对业务提供数据服务与支持，方便其进行医疗服务运营分析、综合管理决策分析、医疗服务监管、绩效考核管理等运营管理
为了更好地服务于大众（包括常驻人口和流动人口），实现医院间的患者相关业务信息的跨院互认，须在永嘉县卫生数据中心为患者身份识别设置专门的应用，以实现多家医院机构之间的患者身份识别，建立患者在区属各家医疗机构之间的主索引。即居民区域主索引（MPI），通过居民主索引（MPI）将永嘉县已有的和即将建设的各类业务应用进行有机整合和统一，为区域内医疗卫生业务协同、业务联动、信息共享提供全面有效支撑。
健康档案是以居民为核心的，每一个居民都需要通过一个唯一的识别号来识别集中管理的居民数据记录。居民主索引（MPI，Master Patient Index）就是建立居民的唯一识别号，把来自不同的、独立的系统和机构的居民标识实现统一的维护管理，并把这些信息映射成统一的标识。通过居民主索引可以检索到所有关于该患者的医疗卫生相关信息。
MPI主要实现功能应包括：主索引规则管理、 主索引匹配、主索引维护、服务场景。
投标人需提出区域内居民身份信息的整合步骤详细方案，实现居民个人识别主索引规则管理机制。
5.1.2业务共享平台
注册服务包括对个人、医疗卫生人员、医疗卫生服务机构等的注册管理服务，系统对这些实体提供唯一的标识。针对实体形成注册库，注册库具有管理和解决单个实体具有多个标识符问题的能力，实现平台范围内针对单个实体的唯一身份识别。注册服务需支持IHE ITI PIX规范。
▶ 个人注册服务
个人注册服务是指在一定区域管辖范围内，形成一个个人注册库，个人的健康标识号、基本信息被安全地保存和维护着，提供给卫生数据交换平台所使用，并可为医疗就诊及公共卫生相关的业务系统提供人员身份识别功能。
▶ 医疗卫生人员注册服务
医疗卫生人员注册库，是一个单一的目录服务，为本区域内所有卫生管理机构的医疗服务提供者，包括全科医生、专科医生、护士、实验室医师、医学影像专业人员、疾病预防控制专业人员、妇幼保健人员及其他从事与居民健康服务相关的从业人员，系统为每一位医疗卫生人员分配一个唯一的标识，并提供给平台以及与平台交互的系统和用户所使用。
▶ 医疗卫生机构注册服务
通过建立医疗卫生机构注册库，提供本区域内所有医疗机构的综合目录，相关的机构包括县级医院、县卫健局所辖各社区卫生服务中心及卫生服务站等。系统为每个机构分配唯一的标识，可以解决居民所获取的医疗卫生服务场所唯一性识别问题，从而保证在维护居民健康信息的不同系统中使用统一的规范化的标识符，同时也满足卫生数据交换基础平台层与下属医疗卫生机构服务点层的互联互通要求。
▶ 医疗术语/字典服务组件
建立术语和字典注册库，用来规范医疗卫生事件中所产生的信息含义的一致性问题。术语可由平台管理者进行注册、更新维护；字典既可由平台管理者又可由机构来提供注册、更新维护。卫生数据交换平台在进行医疗/健康记录整合时，通过提供专业化的术语服务，支持HL7 Vocabulary，ICD-9，ICD-10，LOINC, SNOMED-CT等国际通用术语，以及用户自定义的专业术语，并提供术语识别与映射。
5.1.2.1.1运行配置管理
用户管理
对用户进行全面管理，包括用户组的增加、修改和删除；用户的增加、修改和删除；用户与用户组之间的对应；以及其余色的权限管理，安全可靠的密码管理等功能。
角色管理
完成对系统内角色的维护，以及对角色的分级管理。提供角色定义、权限设置、用户角色分配、用户角色查询、用户角色变更记录查询等功能。
权限管理
提供权限定义、查询及维护功能；提供权限授权角色查询、授权用户查询等功能。
配置管理
提供组件版本自动更新功能、系统参数设置功能，提供个性化服务功能等。
日志管理
平台运行情况的监控记录。提供日志的图形化监控功能；提供错误日志统计的功能；提供对平台运行产生的系统日志进行查询的功能。
5.1.2.2病人隐私保护
为了保证电子健康档案共享的同时实现对居民隐私的保护，平台必须对电子健康档案提供访问权限管理及数据加密等多种手段综合安全应用，包括授权、认证、基于角色的访问、数据库高级安全、应用流程控制等。此外还要考虑：
▶ 病人同意原则：强调居民/病人权利，按前述授权原则实现
▶ 匿名化：用于分析研究时隐去不必要的人员基本信息
▶ 居民个人隐私诊断信息隐藏服务，如艾滋病等。
▶ 同时，平台还需提供如下功能：
▶ 审计日志记录：提供多种级别的日志记录功能。
▶ 审计日志查询：根据用户需要，灵活的设定查询条件，提供良好的日志跟踪、分析等服务。
▶ 审计日志归档
标准化建设是卫生信息化建设的基础工作，也是进行信息交换与共享的基本前提。在信息资源整合的过程中，强调标准化的目的在于确保区域内医疗卫生机构的互联互通和信息共享。同时也能使投入信息化建设的资源得到充分利用。
为了保证区域内外信息系统数据交换的高性能、稳定性和灵活性，需要建立基于健康档案的统一标准规范，实现永嘉县全民健康信息平台相关的基础数据字典、医疗卫生服务机构、行政管理机构、卫生从业人员等的统一标准和统一维护，为医疗卫生、公共卫生、卫生管理及其他部门的应用系统提供统一的数据接口，实现基础数据的统一，实现永嘉县平台与其他应用系统或平台间的数据交换，完成永嘉县医疗卫生机构信息的采集、整合、存储与共享。
制定统一标准的数据规范。平台中有国家和省级标准的，采用国家和省级标准，无具体实施标准的或实施标准不够完善的，需制订和完善标准。通过制订和推广使用标准，统一全县数据标准。必须完成的标准：如医院的结构化电子病历接口标准，全县的药品库编码标准。
1、应用系统规范
应用规范的主要目的是确定业务的基本规范。对于业务基本规范的确立，主要应包含：业务的数据项、业务代码、业务信息分类、业务信息的内容结构、业务服务及业务流程。
2、应用支撑规范
应用支撑规范一方面为解决系统间信息资源整合，另一方面为业务标准中的业务知识表示提供支撑。主要应包括：资源数据类标准、资源整合标准以及信息基础设施规范。
3、数据类标准
数据类的标准确定了信息系统中的数据规范，涵盖的范围应包括：数据元目录、代码目录、分类目录和数据类资源目录。
4、信息交换标准
通过统一的信息交换标准制定，将实现区域内各应用系统及外部接口等的信息交换共享，主要应包括电子健康档案的数据存储标准及信息交换标准、电子病历的数据存储标准及信息交换标准。
5.1.2.3数据质量控制
在数据迁移工程中，原系统数据质量是影响数据移转项目进程以及质量的决定性因素。因此，在项目启动初期或者数据清洗过程中设计数据清洗规则时，应该同时进行数据的质量评估。可通过完整性、准确性、关联性、及时性、稳定性这五个维度综合评价。
数据质量评价需制定一套完整的接口数据质量评估体系，主要针对各联网医院的数据上传质量情况，包括上传质量以及上传的稳定程度两个部分。
社区/医院提交就诊患者相关的诊疗数据的质量，包括数据提交的关联性、准确性和完整性。
社区/医院提交就诊患者相关的诊疗档案数据的稳定/及时程度，包括数据提交的稳定性、及时性。
投标人需要在投标方案中针对数据完整性、准确性、关联性、及时性、稳定性提供具体评价指标以及指标的计分方式。
3.3.2 数据质量监控
为提高数据的采集质量，全民健康信息平台中应建立一整套完整的接口数据质量评估体系，同时建立完善的数据监控机制，对联网医疗卫生机构数据上传的情况（按接口分类的上传数量、上传成功率、质量评估结果等）进行综合展示，以指导各联网县平台、医疗卫生机构应用系统的改造与接口开发。
3.3.3 运行状态跟踪
平台内系统组件的数量众多，需了解平台内各个系统组件的当前状态和运行性能等相关信息，因此对平台内各个系统组件运行状态的跟踪管理成为日常管理维护的重要手段，应能支持通过功能界面的方式管理与监控平台各系统组件的运行状态。
居民健康信息数据至关重要，一旦遭到非法入侵、修改、增加、删除等不明侵害将会造成难以估量的损失和社会影响。为了保证居民健康信息共享的同时，还需要保证数据信息的安全及保护居民的健康隐私，要从整体上考虑可能存在的安全风险，对需要保护的各类信息进行分析，综合考虑系统可接受的风险程度，制定与各类信息系统安全需求相应的安全目标，建立起立体的信息安全体系，即通过物理级、网络级、应用级、系统级的安全性设计以及贯穿其中的安全管理措施来确实保证系统的整体安全，达到风险、安全与投资的最佳平衡。同时，从管理体制上进行必要的调整以适应整体安全管理策略的需要。
5.1.3.1商业智能分析平台
商业智能分析平台应能基于区域卫生信息平台数据中心实现完整的商业智能分析，应包括数据仓库建立、多维数据集建模和数据集市管理等功能，用户应能在该平台基础上，实现报表功能的自定义开发、即席查询和数据钻取等，应能支持多表头和图形化的表现形式，可以方便地将数据导出为csv、excel、pdf文件。
商业智能分析平台应包括商业智能分析引擎、即席查询分析模块、交互式仪表板模块、统一报表系统等。
（一）即席查询分析系统
平台应具有即席查询和分析功能，提供纯Web的交互界面，用户可以选择主题的指标、多级维度，然后立即获得所需的数据分析结果，用户可以在非常友好的界面下利用OLAP和内存引擎进行向下钻取，过滤、切片切块、分类、排序和生成图表。
用户操作的应具有信息的逻辑视图，方便地创建图形、透视表、报表、仪表盘和仪表板，方便地进行交互和钻取，方便地保存、共享、修改、格式化，方便地嵌入到用户个性化的仪表板或是统一的门户中。
（二）交互式仪表板
需能够通过交互式仪表板来展现数据。交互式仪表板运行在一个完全的Web架构上，能给用户提供基于每个个体的职责和身份的可操作、动态的个性化平台信息；可以直观和容易地了解信息；指导用户进行决策。在平台交互式仪表板的环境中，所有最终用户都能在浏览器中访问实时报告、提示、图形、表格、透视表等（无需任何插件）。每个用户都能快速和容易地对仪表板上的结果进行全面的钻取、导航、修改和交互。同时可以将互联网、共享文件服务器和文档资料库等其他的信息源都聚合在平台交互式仪表板上。
全灵活自定义指标、维度界面（自定义模式、指标、维度），全灵活数据计算界面，应支持下钻、上卷、切片切块、旋转、过滤汇总排序。
丰富可视化展示界面，应支持13种以上饼状、热点、环形图等可视化展示，可视化展示导出支持PNG、JPEG、PDF三种方式导出。
（三）报表系统
统一报表管理平台建成后，健康数据交换平台所需的报表都应纳入此平台开发和管理，由本平台提供多种形式供用户直接使用，或提供服务接口由应用系统调用。
统一报表管理平台应能充分发挥数据中心的数据整合优势，统一人口健康报表的统计口径，并符合国家、浙江省及温州、永嘉县相关医疗卫生统计报表的标准要求，应能灵活、简便、高效的为管理人员提供统一的报表浏览入口以及查询和取数服务。
（四）建设主要需求包括：
● 报表管理
应能对报表整个生命周期的管理，针对报表的申请、分析、定制、填报、审核、授权、发布、监控、归档等环节形成一整套完整的报表管理体系。
● 统一报表门户
统一报表门户应提供统一的报表视图框架，整合并浏览各个系统的报表文件。
展现方式
系统应支持按日期、机构、产品等维度对报表进行查询；支持固定报表、灵活查询、自定义报表、多维分析等报表种类。
● 机构和权限管理
应能支持人口健康现有机构及层级关系设置；支持机构的新开、撤并、等情况随时增减机构，支持灵活调整及自动更新机构汇总关系。
● 审计监督
应能从用户访问、报表文件、数据查询等多个层面对用户各个操作过程的日志信息进行登记、监督与审计。
5.1.3.2医疗服务智能分析主题库
建立永嘉县内公立医疗机构运行监管系统，通过采集医院运行数据和质量数据，设计各种专题分析以满足医院的实际业务需要，能够根据医院不断变化的需求而进行自定义配置功能。满足因不同管理者关注的对象不同而自定义设置的功能，并满足医院不断发展的趋势。应实现OLAP钻取分析，趋势分析、对比分析、同比环比分析、复杂构成分析、报表联动；能够进行表内运算和表间运算，多角度进行切片、切块。在图表展现上能够采用仪表盘，柱状图、趋势图、叠加图、雷达图、饼图等多种表达方式。对关键指标能够监控预警，能够支持导出生成excel文档。主要的统计分析专题如下：
5.1.3.2.1首页导航
|
专题名称 |
子专题名称 |
指标需求 |
|
首页导航 |
门诊业务概览 |
按照机构维度统计门诊量、门诊收入、人均费用、同比、环比指标，以表格的方式展现。并能够按照门诊量、门诊收入、人均费用指标定义链接； |
|
按照日期维度统计门诊量（近30天曲线）指标，以曲线图的方式展现。并能够按照门诊量、门诊收入、人均费用指标定义链接。 |
||
|
住院业务概览 |
按照医院维度统计出院人次、住院收入、人均费用、手术人次、平均住院日、同比、环比指标，以表格的方式展现。并能够按照出院人次、住院收入、人均费用、手术人次、平均住院日指标定义链接； |
|
|
按照日期维度统计出院人次（近30天曲线）指标，以曲线图的方式展现。并能够按照出院人次、住院收入、人均费用、手术人次、平均住院日指标定义链接。 |
||
|
医技业务概览 |
按照机构维度统计检验人次、放射人次、超声人要求按照科室、时间维度统计次指标，以表格的方式展现。并能够按照检验人次、放射人次、超声人次指标定义链接； |
|
|
按照日期维度统计检验人次、放射人次、超声人次（近30天曲线）指标，以曲线图的方式展现。并能够按照检验人次、放射人次、超声人次指标定义链接。 |
||
|
医疗质量概览 |
按照机构维度统计出院人数、死亡人数、死亡率、再入院率、手术人数、手术死亡数、手术死亡率、手术并发症、重返手术例、抢救病人数、抢救成功率、抢救死亡数、医院感染发生例数、漏报例数、无菌手术切口感染率指标，以表格的方式展现。并能够按照出院人数、死亡人数、手术人数指标定义链接。 |
5.1.3.2.2门诊主题
|
专题名称 |
子专题名称 |
指标需求 |
|
门急诊业务分析 |
门诊主要指标 |
按照科室、时间维度统计门诊人次，处方总数，总费用（门诊）指标，以表格的方式展现。 |
|
门诊各科室总费用比例 |
按照科室、时间维度统计总费用（门诊）指标，以饼图的方式展现。 |
|
|
门诊业务量 |
按照科室、时间维度统计门诊人次，门诊手术量，处方总数指标，以折线图的方式展现。 |
|
|
门诊收费 |
按照科室、时间维度统计药品费，治疗费，检查费，材料费指标，以堆叠图的方式展现。 |
|
|
门诊挂号 |
按照科室、时间维度统计挂号人次指标，以折线图的方式展现。 |
|
|
门急诊费用分析 |
门急诊费用 |
按照科室、时间维度统计总费用，门、急诊总费用，门、急诊挂号费用，检查费用，药品费用，材料费用，治疗费用，手术费用及占比，人均药费指标指标，以表格的方式展现。 |
|
费用占比分析 |
按照科室类别、时间维度统计医疗费用、药品费用、挂号费用指标，以饼图的方式展现。 |
|
|
科室费用对比分析 |
按照科室、时间维度统计科室总费用指标，以柱状图的方式展现。 |
|
|
门急诊病人分析 |
病人构成分析 |
按照性别，年龄，医保类型，地区，文化程度维度统计病人人数指标，以饼图的方式展现。 |
|
病人就诊类型分析 |
按照就诊类型，时间维度统计初诊人数、复诊人数，急诊人数，急诊留观人数；同比，环比，占比指标，以表格的方式展现。 |
|
|
门急诊流量分析 |
门诊流量分析 |
按照科室、时间维度统计挂号人次，医保人数，医保比例、日平均人数，最大日人数、同比增量、环比增量指标，以表格的方式展现。 |
|
挂号人次比（病人性质） |
按照病人性质、时间维度统计挂号人次、占比指标，以饼图的方式展现。 |
|
|
挂号人次比（科室） |
按照科室、时间维度统计挂号人次、占比指标，以饼图的方式展现。 |
|
|
挂号人次趋势 |
按照科室、时间维度统计挂号人次指标，以曲线图的方式展现。 |
|
|
门诊用药分析 |
处方信息 |
按照科室、医生维度统计处方数、处方合格率、用药剂量、抗菌药物处方数指标，以表格的方式展现。 |
|
药品信息 |
按照科室、医生维度统计药品费用、人均费用、抗菌药物、科室用药药比指标，以表格的方式展现。 |
|
|
药品使用量分析 |
统计前五个单品种使用数量最大的药品。 |
|
|
门诊挂号分析 |
挂号分析 |
按照科室、医生维度统计普通挂号人数、金额、占比、专家挂号人数、金额、人、占比、急诊挂号人数、金额、占比、退号数、占比、收入指标、以表格的方式展现。 |
|
预约分析 |
按照预约类型、爽约率维度统计电话预约数、网络预约指标，以饼图方式展现。 |
|
|
工作量统计 |
按照科室、时间维度统计出就诊前五的科室、医生、挂号人数前五科室指标，以直方图的方式展现。 |
|
专题名称 |
子专题名称 |
指标需求 |
|
住院业务分析 |
住院业务 |
按照科室、时间维度统计入院患者数，出院患者数，转入患者数，转出患者数，住院患者死亡数，总住院天数，总费用（住院）指标，以表格的方式展现。 |
|
住院费用比例 |
按照费用类别、时间维度统计总费用（住院）指标，以直方图的方式展现。 |
|
|
各年龄段住院病人比例 |
按照年龄分段、时间维度统计入院患者数指标，以直方图的方式展现。 |
|
|
出院情况比例 |
按照出院情况、时间维度统计、出院患者数指标，以饼图的方式展现。 |
|
|
出院费用分析 |
出院病人费用分析 |
按照科室、时间维度统计出院人数，住院天数，诊疗费用，药品费用，检查检验费用，住院总费用指标，以表格的方式展现。 |
|
出院病人护理等级分析 |
按照科室、时间维度统计护理等级，人数指标，以饼图的方式展现。 |
|
|
出院病人医保比例分析 |
按照科室、时间维度统计医保费用，自费费用指标，以柱状图的方式展现。 |
|
|
在院病人分析 |
病人类别分析 |
按照科室、时间维度统计在院人数、医保病人、自费病人、慢性病病人、危重病人指标，以表格的方式展现。 |
|
在院病人疾病分析 |
按照疾病、时间维度统计疾病、人数指标，以直方图的方式展现。 |
|
|
危重病人信息 |
统计姓名、性别、年龄、床位、科室、责任护士、责任医生，与病人与病人类别分析是联动关系。 |
|
|
手术业务分析 |
手术业务（科室） |
按照科室、时间维度统计手术患者出院人数，平均住院日，手术总费用，平均手术费用，手术药品费，平均手术药品费，手术台次指标，以表格的方式展现。 |
|
手术业务 |
按照手术，科室，时间维度统计手术台次，门诊手术台次，住院手术台次及同比，环比。手术平均住院日，手术总费用，平均手术费用，手术药品费，平均药费指标，以直方图的方式展现。 |
|
|
手术麻醉分级 |
按照麻醉等级，时间维度统计麻醉等级，手术台次指标，以饼图的方式展现。 |
|
|
住院预交金分析 |
欠费监控分析 |
按照科室、时间维度统计预交金，医疗费用，余额指标，以交通灯的方式展现。 |
|
预交金分析 |
按照科室、时间维度统计预交金，时间指标，以趋势图的方式展现。 |
|
|
漏费分析 |
按照科室、时间维度统计漏费次数，漏费金额指标，以表格的方式展现。 |
|
|
住院床位使用情况分析 |
在院病人分布情况 |
按照科室、时间维度统计科室，在院人数，比例指标，以表格的方式展现。 |
|
科室床位使用分析 |
按照科室、时间维度统计床位数，占比，平均住院日、床位使用率、床位周转率指标，以表格的方式展现。 |
|
|
床位使用率波动分析 |
按照时间维度统计时间，使用率指标，以曲线图的方式展现。 |
5.1.3.2.4医技主题
|
专题名称 |
子专题名称 |
指标需求 |
|
医技业务分析 |
医技业务分析 |
按照科室、时间维度统计科室，门诊检验人数，同比，环比，住院检验人数，同比，环比；急诊住院检验人数，同比，环比指标，以表格的方式展现。 |
|
检验次数 前五项目 |
按照时间维度统计检验/检查项目次数指标，以直方图的方式展现。 |
|
|
近四月检查/检验次数波动 |
按照类别（检查，检验）维度统计每个月的次数指标，以趋势图的方式展现。 |
|
|
工作量统计分析 |
科室工作量统计分析 |
按照科室、时间维度统计检验人次，同比，环比，急诊人数，同比，环比，总量，同比，环比指标，以表格的方式展现。 |
|
个人工作量统计 |
按照科室、时间、医生维度统计检查人数，急诊检查人数，检验人数，急诊检验人数指标，以直方图的方式展现。 |
5.1.3.2.5财务主题
|
专题名称 |
子专题名称 |
指标需求 |
|
医院收入分析 |
医院收入分析 |
按照机构、科室类别、科室、医疗小组维度统计医疗收入（金额、占比、同比、环比）、药品收入（金额、占比、同比、环比）、其他收入（金额、占比、同比、环比）、合计收入（金额、比例、同比、环比）指标，以表格的方式展现。 |
|
收入占比分析 |
按照科室、收入类别维度统计医疗收入占比、药品收入占比、其他收入占比指标，以饼图的方式展现。 |
|
|
收入对比分析 |
按照科室维度统计医疗收入、药品收入、其他收入、合计收入指标，以直方图的方式展现。 |
|
|
综合业务分析 |
住院业务指标 |
按照科室、时间维度统计出院人数，出院床日数，在院床日数，平均住院天数，业务收入，药品收入，材料费收入，耗占比，出院人均费用，出院药品人均，危重人数，病危床日数及同比环比指标，以表格的方式展现。 |
|
门诊业务指标 |
按照科室、时间维度统计门急诊人次，门诊人均费用，门诊收入，门诊药品收入，门诊药品人均指标及同比环比指标，以表格的方式展现。 |
|
|
手术业务分析 |
按照手术级别、科室、时间维度统计手术台次指标，以饼图的方式展现。 |
配置管理
|
功能名称 |
子功能名称 |
指标需求 |
|
配置管理 |
指标管理 |
可针对医院关注对象建立指标，指标建立支持指标公式利用加、减、乘、除等算法计算合成指标，并可以设置指标数据长度和数据类型，添加指标说明，说明链接。支持指标建立、修改、删除基本功能；并可按照业务对指标建立多个目录，具备目录增删改基本功能。 |
|
维度管理 |
可根据医院关注角度建立维度，对维度设置数据类型，选择字典名称。针对单一维度可新增或者引用其他维度方式以建立下钻维度。 |
|
|
模型管理 |
可通过指标、维度二维组合建立数据模型，以满足医院的管理决策关注内容要求。 |
|
|
主题管理 |
系统可加载数据模型建立主题，设置主题的数值单位、视图展现图表，并可根据具体指标、维度添加链接，并可设置层级和参考线、对照指标。 |
|
|
组图管理 |
需可选择多个布局，加载多个主题，可设置主题间的联动关系。并可添加预警组件和预警组件、行列数据联动动态主题组件。 |
|
|
预警配置 |
系统需支持根据指标的单一维度设置预警值，支持短信、邮件预警方式传达，预警频率支持设置小时、日、月单位。具备预警值的增删除改基本功能，具备预警监控启动、停止功能。 |
医疗协作监管系统是基于区域卫生健康信息共享平台，对医疗协作开展情况的数据进行挖掘分析，实现对医疗协作业务的实时监控与跟踪，了解分析医疗协作业务开展的实际情况和主要问题，根据问题提出改进措施，推动医疗协作更加深入顺畅的开展。医疗协作监管系统还对各医院间协作的利益进行核算和结算，并对协作业务的数量和质量进行分析，对专家医生多点执业情况，基层坐诊的频度和效果，资源的利用效率情况进行监控分析。
医疗服务质量分析系统就是基于区域卫生信息数据中心，根据质量指标按照各医院、各科室进行实时统计分析，多各医院、各科室的质量指标进行实时监控，并与各质量指标的基准值进行对比，对超出基准值的指标和部门通过短信息、邮件等方式通知相关人员，责令其及时整改，确保从上到下关注医疗质量指标的持续性改进。该系统应依照卫生部《三级综合医院医疗质量管理与控制指标体系（2011年版）》等规范。
5.1.3.2.6.1药品监管分析
1. 门诊用药监管
应包括人均药费、均次处方额、人均处方数、药品组成等。按不同区进行数据表现，按不同机构等级进行数据反应。
2. 门诊基药监管
应包括基药使用率、基药费用率、基药金额等。按不同区进行数据表现，按不同机构等级进行数据反应。
3. 门诊抗菌药物监管
应包括抗菌药物金额、抗菌药物使用率、抗菌药物费用率、抗菌药物（一、二、三以以上联）联合使用率、特殊抗菌药物使用率等。按不同区进行数据表现，按不同机构等级进行数据反应。
4. 门诊注射药物监管
应包括注射药物金额、注射处方数、注射处方率、注射费用率等。按不同区进行数据表现，按不同机构等级进行数据反应。
5. 住院用药监管
应包括人均药费、床日药费、药费排名等。按不同区进行数据表现，按不同机构等级进行数据反应。
同门诊药品监管分析一样，住院药品分析同样支持通过双击任意条目，数据可以向下钻取，从而可以查询到相应医疗机构各科室乃至各医生的住院药品使用情况。
6. 住院基药监管
应包括基药金额、人均基药额、基药费用率、排名等。按不同区进行数据表现，按不同机构等级进行数据反应。
7. 住院抗菌药物监管
应包括抗菌药物金额、人均抗菌药物金额、抗菌药物使用率、抗菌药物费用率、特殊抗菌药物使用率等。按不同区进行数据表现，按不同机构等级进行数据反应。
8. 住院注射药物监管
应包括注射药物金额、人均注射药物金额、注射药物使用率、注射药物费用率等按不同区进行数据表现，按不同机构等级进行数据反应。
9. 住院抗菌药物使用强度监管
应包括：抗菌药物总消耗，抗菌药物使用强度等。按不同区进行数据表现，按不同机构等级进行数据反应。
10. 单病种分析
根据不同病种，对该病种的住院情况以及抗生素使用情况以图表形式进行直观展现，帮助相关管理人员进行查询分析。
11. 区域药品分析
对于永嘉县医疗机构单位内部药库、药房的库存（一天前的实施库存）进行监管分析，同时监管永嘉县各卫生机构内的药品采购计划。
12. 医保监管分析
统计各个永嘉县各卫生机构内的医保数据，如：医疗总费用、符合医保费用、记账金额、符合医保费基金支付、不符合医保费用基金支付、人头数、人次数、人次人头比、均次医疗费、自付费用、药占比、材料占比等数据。报表格式需要区分社保、农保、住院、门诊。
5.1.3.3公共卫生智能分析主题库
应系统对疾病管理、疾病控制、妇幼保健、卫生监督、计划免疫等公共卫生服务的执行情况进行全方位的综合监管。
应通过数据的采集服务从各基层业务系统中获取公共卫生服务数据，根据明确的质量监管指标加以统一监督和管理，以提供按照日期、行政区划、责任机构等多条件的查询和图表展示。主要功能应包括：
1. 指标管理
应提供灵活多维度的指标配置管理功能。
2. 业务分析
需通过公共服务情况的统计，进行同比和环比的公共服务分析。
3. 监控报告
需提供健康档案规范建档率、高血压建档率、糖尿病建档率、重症精神病建档率、健康教育活动执行率、健康体检人数、慢病随访率、慢病分级管理情况、0-6岁儿童管理率、孕产妇管理率、高危产妇管理率、产后访视情况、预防接种及时率、传染病上报率、突发公共卫生事件报告率、卫生监督歇班次数等。监控报告相关数据滞后时间最大不能超过一周。
4. 个案监管和跟踪
需提供个案的健康档案（含专项档案）的抽查，审核的监管等，提供整体公共卫生服务情况的监管，以实现从点到面的监管，及时甚至提前发现提前干预和全程跟踪。
5.1.3.4 数据实时驾驶舱
数据实时驾驶舱系统应能展现实时的全景运营数据分析视图。系统应采用先进的数据挖掘技术，为领导提供智能决策支持，通过静态、动态、图形表现等多种形式提供了科学的、准确的、快速的、直观的分析数据、图表等，为领导决策提供直观直接的数据分析展示。
数据实时驾驶舱系统主要技术如下：
● 应能实现丰富的、可视化的图表展现功能，确保KPI图表、战略地图、数据驾驶舱、仪表盘的灵活性、交互性和直观性。
● 动态可视化支持动态图表、动态组件交互行为，并可PNG格式可视化展示导出。
● 应能建立人口健康经营分析指标体系，实现统一指标、统一维度、统一业务语言，自上而下地理顺关键指标逻辑关系，全面提升信息的支持决策能力。
● 应能建立人口健康关键经营指标的应用主题分析模型，实现经营分析的信息全视图建设。
● 应能对KPI图表、战略地图、数据驾驶舱、仪表盘进行整体设计，实现分层次、模块化管理，并可对关键经营指标进行动态调整。
健康档案共享系统即电子健康档案浏览器，需基于居民健康信息平台，实现辖区内的卫生信息共享、调阅，不同机构的人员按照不同的权限实现信息的调阅，数据共享直接调用一个加密的地址，调用地址是需要用户名及密码认证的。
需支持在社区机构、大中型医院等各级医疗卫生服务机构内实现调阅服务。信息调阅服务依托健康档案浏览器予以实现。健康档案浏览器是为终端用户提供的基于Web或手机访问健康档案的应用程序。授权的医疗卫生人员可以方便地访问区域卫生健康信息共享平台中居民的健康信息。调阅应用需包含：非影像信息调阅、影像信息调阅、居民身份模糊查询。
系统需利用数据交换技术，数字认证等技术，通过制定居民完整的电子健康记录标准（居民从生到死的医疗卫生信息，包括个人健康档案，病历，检验检查报告，体检报告，处方等），在数据中心建立核心健康档案数据库，整合区域内部的卫生信息资源，形成以居民健康档案为核心，覆盖全业务信息的信息树结构。
5.2.1.1居民健康档案共享内容
居民健康档案浏览器的首页集中显示居民基本信息、健康信息、既往诊断信息、事件提醒信息、近期用药清单、近期就诊记录、近期化验信息、近期检查信息。
具体展现内容需要包括：
|
序号 |
功能 |
展现内容（对于一些敏感数据用*代替） |
|
1 |
调阅内容-个人基本信息 |
（一） 个人基本信息 包括人口学和社会经济学等基础信息以及基本健康信息。主要包含： 1．人口学信息：如姓名、性别、出生日期、出生地、国籍、民族、身份证件、文化程度、婚姻状况等。 2．社会经济学信息：如户籍性质、联系地址、联系方式、职业类别、工作单位等。 3．亲属信息：如子女数、父母亲姓名等。 4．社会保障信息：如医疗保险类别、医疗保险号码、残疾证号码等。 5．基本健康信息：如血型、过敏史、预防接种史、既往疾病史、家族遗传病史、健康危险因素、残疾情况、亲属健康情况等。 6．建档信息：如建档日期、档案管理机构等。 |
|
2 |
调阅内容-个人医疗服务查询 |
（二） 主要卫生服务记录 主要卫生服务记录是从居民个人一生中所发生的重要卫生事件的详细记录中动态抽取的重要信息。在健康档案浏览器中需要展现的卫生服务记录有： 1．儿童保健：出生医学证明信息、新生儿疾病筛查信息、儿童健康体检信息、体弱儿童管理信息等。 2．妇女保健：婚前保健服务信息、妇女病普查信息、孕产期保健服务与高危管理信息、产前筛查与诊断信息、出生缺陷监测信息等。 3．疾病预防：预防接种信息、传染病报告信息等。 4．疾病管理：高血压、糖尿病、肿瘤、重症精神疾病等病例管理信息，老年人健康管理信息等。 5．医疗服务：门诊诊疗信息、住院诊疗信息、住院病案首页信息、健康体检信息、各类检验结果、检查报告等。 |
5.2.1.2 系统功能
基于数据中心的电子健康档案浏览器向各医疗卫生机构提供个人电子健康档案查询访问界面，包括全部内容的查询界面和部分内容的查询界面，各医疗卫生机构系统可以方便地调用这些界面实现业务的整合，从而完成业务的协作。
健康档案维护：系统需要提供多种具有严格授权控制的健康档案数据采集途径。提供系统管理员人工新增，修改健康档案的途径。提供健康档案自动更新的接口。
健康档案配置：居民可以自己控制健康档案的权限，自定义健康档案的展现方式，健康档案的展现内容等。
健康档案权限管理：系统维护人员对居民健康档案使用者的身份的进行控制和管理，对其权限进行控制和管理。
验证登录：通过多种手段识别唯一居民身份，从而得到提供服务的授权。特别注意系统登录安全性，防止泄露居民隐私。
居民健康档案查询：居民根据居民唯一身份查询居民本人健康档案信息。得到授权的医疗机构或医疗工作人员根据居民统一身份识别查询居民健康档案，作为医疗工作参考信息。
日志管理：系统记录健康档案新增，更新和查询的记录日志。以及用户登录、调阅的时间、过程以及调阅计算机的IP地址等信息，以备统计和追溯。
5.2.1.3 应用安全控制
电子健康档案浏览器大多是在浏览器固定的区域内通过静态推送的模式展示给阅览者。无论是医务工作人员还是患者，都无法控制某部分的信息是否展示，很多时候存在患者本人不希望把某些隐私信息展示出去，或者当前的医务工作人员并不具备相应的阅览权限的时候，则存在冲突。
系统需支持如下功能：
1. 权限控制：
通过模块化得权限控制管理，对不同的电子健康档案浏览模块实行差别化的权限控制管理，通过对阅览者的身份识别，来获取到相应的阅览权限。
患者本人也可以登录到居民健康网站门户，在允许的范围内，设定自己不愿意展示出去的健康信息，尊重患者的隐私保护权益。
2. 应用审计：
记录系统访问日志，日志信息包括详细的访问信息及访问内容，为对各类攻击及异常访问的完整追溯提供了基础。
3. 身份认证：
通过基于数字签名的身份认证机制，为主应用层提供用户在业务系统中权限的权限信息，保障业务信息访问者的权限控制包含控制力的角度，功能权限管理。
此次系统单点登录建设需实现HIS，健康档案、绩效系统等帐号角色权限统一，同时支持不同厂商信息系统。供应商需按照要求提供异构业务系统单点登录集中访问的解决方案。
单点登录（SSO）需采用OAuth2.0认证机制，基于统一用户账号的登录认证，同时搭配区域卫生健康信息共享平台统一门户，实现各异构/业务系统统一登录、集中访问的效果。
单点登录统一门户需采用Web系统架构，通过浏览器直接访问，进行链接打开各系统（B/S的web页面或C/S的exe程序）。
供应商需提供切实可行的对接方案，满足如java、. net等流行编程语言实现的系统单点登录的实现，需详细描述所采用的技术手段、对接方式、可以达到的效果等。
系统需提供一个统一且高度集成的身份认证体系，以单点登录为核心，实现对用户身份信息的统一管理及统一认证，该系统有如下特点：
（1） 唯一账号密码
提供统一的用户认证机制，支持单点登录，实现对用户信息的集中有效管理。当用户访问多家医院的信息门户系统时，只需要通过统一身份认证系统主动进行一次认证。所有门户系统都使用一致的登录操作，用户访问所有医院信息门户系统都使用唯一的用户名和密码。
（2） 高度安全性
安全性主要是指系统中的敏感信息不被非法窃取和篡改。一方面，身份认证服务的功能性质决定了系统必须杜绝漏洞和隐患的存在；另一方面，医学信息系统中存放着大量包括患者隐私的敏感数据，这就更加突出了安全性在系统设计开发中的地位。因此，必须采取措施以保证数据在存储、传递等各个环节的安全性。
（3）平台兼容性
统一身份认证系统要求和各家医院的信息门户系统集成来提供服务，而各个门户系统可能运行在多种操作系统平台之上，这就要求统一身份认证系统与各门户系统间的通信必须是平台无关的，统一身份认证系统能够为各家医院的信息门户系统提供一致的认证服务。
（4） 可集成性
对于已经稳定运行的医院信息门户系统，统一身份认证系统的实现要避免对其进行大规模改动，要尽可能地利用现有系统的身份认证模块及权限设置，实现无缝集成。对于将要开发的系统，则应该在开发阶段增加对统一身份认证的支持。
（5） 可扩展性
本系统十分注重系统的可扩展性和灵活性。随着各种不同应用系统的开发和部署，统一身份认证系统应该能够方便地将它们融入进来，统一身份认证服务可以作为身份认证模块为各种新的应用系统工作。
（6） 稳定性
统一身份认证系统是整个集成系统中的核心部分，该系统的故障将会导致整个集成系统的瘫痪，因此必须保障统一身份认证系统的稳定性。在系统的设计开发过程中，不仅考虑了系统各模块的合理性和流程的可靠性，而且还采用冗余措施来保证系统运行的连续性。
本次项目建设对上需按照温州市级平台与永嘉县大数据中心平台所要求的数据接口标准规范进行监管数据批量上传，对下需围绕县域监管指标发布接口标准规范，要求人民医院与中医院做好相应接口改造，确保相关监管指标数据做到实时上传。以上两种途径均是按照平台级数据交互进行。
5.3.1.1 温州数据上传对账统计
应实现与温州市级数据上传内容的数据质量统计分析，通过分析结果找到上传数据的质量问题，从而进行对应的数据质量提升，满足市级平台要求。
5.3.1.2温州市级共享交互平台上传
需整合永嘉县内各家医疗机构生成的数据，统一汇总实现与温州市级平台的数据上传业务，具体与温州市级平台互联包括：基本服务、患者注册服务、病历文档共享服务、区域术语与字典服务，与市级信息平台的信息共享、业务协同（如区域一卡通）、区域远程医疗、区域医疗公众服务、健康档案的上传与共享等。
5.3.1.3 慢性病报告接口整合
需整合永嘉县内各家医疗机构生成的数据，统一汇总应实现与温州市级平台的数据上传业务，具体与温州市级平台互联应包括：高血压、慢阻肺和高危人群报卡，糖尿病、心脑血管和恶性肿瘤的报卡、初防、随访，死亡医学证明书等。
5.3.1.4 传染病报告接口整合
需整合永嘉县内各家医疗机构生成的数据，应统一汇总实现与温州市级平台的数据上传业务，具体与温州市级平台互联应包括：常规传染病报告信息、手足口病报告信息、性病报告信息、AFP报告信息等。
5.3.1.5 温州市签约平台接口整合
需整合永嘉县内各家医疗机构生成的数据，应统一汇总实现与温州市级平台的数据上传业务，具体与温州市级平台互联应包括：签约初始化、户籍地址或居住地址查询、人群类别对应服务包、签约验证、签约申请单提交、查看签约详情、查看签约服务项目详情、查询本机构签约信息、预签约初始化、居民所在地址、返回下级地址信息、根据地址返回服务机构、根据签约机构初始化、预签约提交、取消预签约等。
5.3.1.6 温州市区域妇幼系统与电子病例系统对接接口整合
需整合永嘉县内各家医疗机构生成的数据，应统一汇总实现与温州市级平台的数据上传业务，具体与温州市级平台互联应包括：获取本机构用户信息、获取孕产妇基本信息、获取孕产妇产前检查-首次检查信息、获取孕产妇产前检查-复查信息、上传更新孕产妇产前检查-复查信息（一般检查项目）、上传更新孕产妇产前检查-检验信息、上传更新孕产妇产前检查-检查信息、上传更新孕产妇高危信息(轻度中度高危)、上传更新孕产妇重度高危信息报告卡等。
5.3.1.7 电子病例数据共享文档接口整合
需整合永嘉县内各家医疗机构生成的数据，统一汇总实现与温州市级平台的数据上传业务，具体与温州市级平台互联包括：电子病历文档上传、查询病历共享文档等。
需接入直属卫生机构和乡镇计生系统，实现数据的全面整合。
检验报告按标准格式集中传输到统一的检验数据中心，提供标准的接口服务为其它机构的检验申请接入平台。
具体内容应包含接口服务：公用数据下载服务、申请单上传及下载、病人信息上传及下载服务、标本结果上传及下载服务、标本流转状态监控服务、危急值上传下载服务。
通过区域卫生健康信息共享平台，使患者在永嘉县内生成的电子病历档案，与其自身在市级平台的电子病历数据进行紧密整合，形成完整的电子病历档案。
5.3.2.3 影像报告上传及查询服务整合
负责处理所有影像报告归档，保存相关操作DICOM影像存储路径并实现文字报告的自动归档存储及数据库管理。支持对病人医学影像信息记录建立主索引(MPI)管理，以及为不同医院信息系统的ID体系间建立交互关联和索引机制。
系统需支持永嘉县内移动随访数据与电子健康档案内容的整合，使得移动随访数据能够被有效的记录在居民个人档案中方便进行调阅和处理。
在永嘉县内将采集辖区居民的慢病管理信息的内容。在区域卫生健康信息共享平台的基础上通过前置机实现健康档案对接。
系统需支持区域体检的数据与永嘉县内居民健康档案的数据对接整合，应实现体检数据能够有效地与健康档案进行整合，方便进行调阅。
系统需支持满意度信息与永嘉县各医共体内人事管理系统与绩效管理系统的数据内容整合，应实现数据在医务人员管理中的合理应用。
需完成与永嘉县县政府大数据平台及县级医院数据平台的对接，实现相关数据的互联互通，协同共享。
5.3.4 与基层医疗机构补偿机制改革绩效考核系统对接
需完成与基层医疗机构补偿机制改革绩效考核系统的对接，为基层医疗机构补偿机制改革绩效考核系统提供数据支持，此平台需从省、市相关平台获取层医疗机构补偿机制改革绩效考核系统需要的数据，获取数据产生的费用成本纳入此项目的预算，不再额外支付任何费用，此功能为重点工作，若不满足作无效标处理。（▲投标时提供承诺函，该项为废标项，如不提供按无效投标处理）
5.3.5 其他接口
根据实际工作要求，完成各类信息系统接口对接工作。
第六章 项目实施要求
投标厂商应具备较强的行业经验、信息系统集成能力和质量管理体系，同时需要根据项目建设内容和进度需要，派驻具有一定资质能力水平的成员组成项目小组对此次项目进行实施及服务。
投标人应承诺在项目合同签订后6个月内完成系统调研、培训、数据准备和系统上线等工作。
投标人应具备与本项目匹配的服务能力，以响应招标人的技术服务要求。
第七章 售后服务要求
7.1 系统维护要求
要求供应商提供的维护服务内容包括但不限于以下内容，所有维护工作费用均包括在年维护费内，不再额外产生费用，驻点工程师的饮食、住宿、交通等费用由供应商自行承担。
|
序号号 |
项目要求 |
参数要求 |
|
1 |
基本维护 |
7*24小时互联网/电话技术支持、远程维护支持，重大故障工程师到场解决，系统每月巡检并提供巡检报告等 |
|
2 |
工程师驻点 |
▲要求供应商至少委派1名工程师到甲方现场驻点，若工程师无法完成甲方指派的维护工作，甲方有权要求更换，直到甲方满意为止。 |
|
3 |
其他维护工作内容 |
系统现有功能模块优化升级； 各类系统接口开发，包括数据采集和下发接口； 各类工作报表开发 系统数据库的安装与维护 系统数据定期备份
|
7.2 免费维护期
(1)▲本项目免费维护期为应用软件通过最终验收之日起不少于一年（含一年），费用包含在投标总价当中。
(2)维护期内应用系统的任何更新（包括升级和调整）都需提供最新的需求说明、业务流程图、数据流程图，并在原有基础上及时更新。
第八章 验收标准与付款方式
（1）系统初验
经过若干轮回的开发、完善工作，达到了系统初验的条件后，承建单位可以向采购人提交系统初验的申请，并经采购人同意后组织系统初验。
系统初验的基本条件是：
全面完成系统的设计、开发、测试和集成工作，基本达到功能、性能、使用等方面的要求；
用户对系统的使用方式满意，确实方便了用户，提高了用户的效率，达到了系统的设计目标；
系统运行基本稳定，上线试运行后确保不会影响业务部门的正常工作。
（2）系统试运行
系统初验合格后，经确认系统进入3个月的试运行期。在试运行期间，一方面要提供足够的培训和技术支持，保障用户能够正确的理解和使用系统，另一方面，要根据运行中出现的问题以及用户需求情况，及时修改完善系统。试运行时间，要至少保证连续1个月无重大事故发生。所有试运行期间的程序修改和软件变化都将在试运行结束后写入操作和维修手册中。
（3）系统终验
系统在达到了全部规定要求，连续成功稳定运行3个月以上，承建单位在提交全部相关文档、报告、代码等交付物的前提下，可以向招标人提出系统竣工验收的申请。用户按照验收标准组织验收。终验合格后，工程建设完工，进入质量保证期。
8.2付款方式
（1）合同签订前，乙方应向甲方提供合同总金额5%的履约保证金，如乙方未按规定提交履约保证金则甲方有权取消合同，引起的一切损失由乙方承担。合同签订后十五个工作日内，甲方向乙方支付合同总额30%的预付款；系统全部开发完成、上线试运行并初验合格且收到发票后三十个工作日内，甲方向乙方支付合同总金额的30%；项目建设完成，并通过终验合格且收到发票后三十个工作日内，甲方向乙方支付合同总金额的30%；项目验收合格后满1年且系统无质量和服务问题，在收到发票三十个工作日内，甲方向乙方支付合同总额10%的合同款。
收藏