妇幼保健系统 架构设计讨论方案0819.docx
《妇幼保健系统 架构设计讨论方案0819.docx》由会员分享，可在线阅读，更多相关《妇幼保健系统 架构设计讨论方案0819.docx（16页珍藏版）》请在冰点文库上搜索。
妇幼保健系统架构设计讨论方案0819
妇幼保健系统架构设计讨论方案
（2015-08-06）
1.需求概述
●遵循市健康信息网所要求的市区二级架构体系。
●孕保系统是在原系统基础上的升级和流程优化，原有功能必须保留。
●儿保系统在原有功能的基础上重新规划设计，优化原有流程，扩展新功能。
●对于自行建设妇幼系统的区县，需满足《上海市妇幼保健信息功能规范》，并且能够无缝与市妇幼平台对接，同时也可为区县提供标准版的妇幼保健信息系统。
●系统设计过程中需满足妇幼部分业务实时性要求；同时也满足各级妇幼保健所、社区卫生服务中心、各类医院的日常使用需求。
●充分利用医院HIS、LIS等系统的已有数据，避免“二次录入”。
2.架构设计
2.1.一期建设内容
下图是对于市妇幼平台现状的描述。
原市妇幼孕保系统是一个“烟囱”系统，产科医院、社区医院、妇保所等机构通过“市突发公卫专网”直连此系统。
同时，有些区县又建设了自己的妇幼系统，区内的二级医院和社区医院与之相连。
国妇婴、一妇婴等通过自建的系统与之相连。
图（2-1）市妇幼平台一期建设内容
原有儿保系统分为市级平台端和区县应用端，分别通过区级平台接入到上海市市级区域卫生信息平台。
非实时的数据交换通过市、区两级区域卫生信息平台实现，实时的业务协同则通过市、区两级儿保系统内部的服务进行实现。
下图为一期儿保系统构架。
图（2-2）市儿保平台一期建设内容
2.2.本期建设内容的总体架构
基于一期妇幼建设经验，针对不足之处需进一步完善优化（网络、数据共享等），确保本期能够降低基础录入工作量并提升工作效率，提高妇女、儿童信息延续性、准确性、实时性。
妇幼是基于市区二级平台。
在健康信息网架构基础上，突出与妇幼相关系统组件，其系统架构如下图：
市妇幼平台
孕保系统儿保系统
接入机构
标准规范
安全体系
区妇幼保健所
市妇幼中心
社区医院
区属二三级医院
三甲医院
医联平台
区妇幼平台
产前筛查
更年期
危重抢救
出生
婚检
艾梅乙
妇女病
2
1
3
孕保、出生、婚检…各妇幼系统
计划生育指导
辅助生殖
危重抢救
转诊
儿童保健
疾病筛查中心
图（2-3）市妇幼平台二期整体架构
其中蓝色箭头代表访问应用；灰色双向箭头代表实时或非实时的数据交换。
图中的三个数字代表三甲医院接入时的三种方案。
2.3.应用部署和用户角色分析
按照市区两级平台的架构，妇幼平台分为市、区县两级，分别部署于市公卫平台区域和区县平台区域，并通过市公卫平台和区县平台与外部系统交换数据。
根据属地化管理的要求，一、二级医院按所在区县归入各区妇幼平台，三级医院接入属地所在区妇幼平台（过渡期也可考虑直接接入市妇幼平台）。
各应用系统的部署情况见下表：
市妇幼中心
区妇保所
三甲医院
区属二、三级医院
社区医院
孕保
访问市妇幼平台的应用
访问区妇幼平台的应用
助产机构访问区妇幼（或市妇幼）平台的应用
助产机构访问区妇幼平台的应用
访问区妇幼平台的应用
孕保-产前筛查
同上
访问区妇幼平台的应用
产筛机构访问市妇幼平台的应用
助产机构访问区妇幼平台的应用
孕保-危重抢救中心
同上
访问区妇幼平台的应用
抢救中心访问市妇幼平台的应用
助产机构访问区妇幼平台的应用
出生
同上
访问区妇幼平台的应用
助产机构访问区妇幼（或市妇幼）平台的应用
助产机构访问区妇幼平台的应用
婚检
同上
同上
国妇婴访问区妇幼（或市妇幼）平台的应用
浦东妇幼访问区妇幼平台的应用
艾梅乙
同上
同上
助产机构访问区妇幼（或市妇幼）平台的应用
助产机构访问区妇幼平台的应用
访问区妇幼平台的应用
更年期
同上
同上
访问区妇幼平台的应用
妇女病
同上
同上
有资质的机构访问区妇幼（或市妇幼）平台的应用
有资质的机构访问访问区妇幼平台的应用
儿保
同上
同上
疾病筛查中心、听力诊断中心访问市妇幼平台的应用
有资质的机构访问访问区妇幼平台的应用
访问区妇幼平台的应用
3.数据流转说明
3.1.数据流转概述
市妇幼平台所需的数据，按产生方式来分，可分为两部分：
1、终端用户手工录入的，2、可以从医院内部系统中获取的。
按流转时效来分，也可分为两部分：
1、需要实时交换的，2、不需要实时交换的。
以下3.2和3.3这两个章节的内容，除3.3.2外，描述的都是通过终端录入的信息以及能够通过技术手段（见3.6中的模式一）将医院内部系统的数据拷贝到妇幼系统中的。
3.2.区属医院的数据流转
区属医院的数据流转方式如下图。
区县可根据自身情况选择“标准版妇幼系统”或自建妇幼系统。
区属医院包括社区医院、二级医院和区属的三级医院，以及能接入区级平台的民营医院和军队医院。
图（3-1）区属医院的数据流转
这里需要注意的是，区妇幼平台的应用中必须包含全市的数据或由区级平台上的应用实时（秒级）向市级平台发起请求（因为孕妇可能跨区产检或分娩）。
3.3.三甲医院的数据流转
由于三甲医院的妇幼业务属地和管理现状比较复杂，我们必须进行更详细的分析。
对于三甲医院的接入方式，我们提供下述三种方案供依次选用，即推荐的选用顺序为方案一、方案二、方案三。
3.3.1.方案一（直接属地化管理）
方案一：
三甲医院按属地化管理的原则，接入各区县妇幼系统并实现双向数据交换，再由区县妇幼系统与市级妇幼系统进行数据交换、共享。
图中绿色粗箭头代表实时或非实时的数据交换通路；黑色细箭头代表访问应用。
图（3-2）三甲医院的数据流转方案一
优点：
完全符合“属地化管理”的要求。
不足：
有些区县现有的网络情况并不支持，建设进度受制于三甲医院与其所在区的网络连通工作，也受制于三甲医院接入区级平台的意愿。
另外，区妇幼平台的应用中必须包含全市的数据或由区级平台上的应用实时（秒级）向市级平台发起请求（因为孕妇可能跨区产检或分娩）。
3.3.2.方案二（利用健康网通路的数据交换）
方案二：
三甲医院利用现有的健康档案数据交换渠道进行数据的双向数据交换，并按属地化管理的原则将三甲医院的数据落到各区县妇幼系统。
图中绿色粗箭头代表实时或非实时的数据交换通路；红色细箭头代表质控反馈。
图（3-3）三甲医院的数据流转方案二
优点：
完全利用现有通路，不受制于网络连通情况。
不足：
需要医联平台配合改造数据交换接口，而且需要手工录入的信息在医院系统中并不存在（如何考虑？
），风险比较大。
作为业务管理方，区县平台获得数据的时效性较差。
3.3.3.方案三（间接属地化管理）
方案三：
在过渡阶段，采用方案一或方案二暂时有困难的三级医院直接接入市级妇幼系统并实现双向数据交换，由市级妇幼系统与区县妇幼系统进行数据共享和交换。
图中绿色粗箭头代表实时或非实时的数据交换通路；黑色细箭头代表访问应用。
图（3-4）三甲医院的数据流转方案三
优点：
建设进度不受制于其他部门；避免了平台及数据交换，则数据质量比较高。
市级平台获取数据的时效性较好。
不足：
一定程度上又形成了“烟囱”；与市区二级平台的建设初衷有一定的差异。
作为业务管理方，区县平台获得数据的时效性较差。
3.4.质控与交换频度
3.4.1.属地化管理
各级医院都连入相应的区妇幼平台
交换频度
分拣情况
孕保
1、应用录入的内容入区妇幼临时库；
2、区妇幼临时库数据交换给市妇幼，市妇幼质控合格的（入市妇幼正式库）并返回给区妇幼，入正式库；
3、质控不合格，市妇幼通知相应区妇幼修改。
区妇幼è市妇幼：
每小时一次。
（实时）
当孕妇户籍地址不在本区时，可能有A区上传，市级平台下发到A、B两区。
出生
1、应用录入的内容入区妇幼临时库；
2、区妇幼临时库数据交换给市妇幼，市妇幼质控后（入市妇幼正式库）并返回给区妇幼，入正式库；
3、区妇幼正式库数据交换给区疾控，区疾控质控后反馈给区妇幼，区妇幼反馈给市妇幼；（应该是市妇幼市疾控，具体质控方式及交换频度另议）
4、市妇幼通知相应区修改。
需要和市疾控再讨论
不存在A区è市级平台èB区
婚检
同“孕保”
区妇幼è市妇幼：
每天一次。
不存在A区è市级平台èB区
艾梅乙
同“孕保”
同上
不存在A区è市级平台èB区
更年期
同“孕保”
同上
无
妇女病
同“孕保”
同上
无
儿保
1.市疾控数据交换给市妇幼临时库
2.将临时数据与儿保唯一编码引擎进行匹配并质控,有效的数据进入新生儿登记
3.根据儿童居住地分发给区妇幼平台
需要和市疾控再讨论
根据儿童居住地,可能有A区è市级平台èB区
3.4.2.三甲医院的方案二
对于三甲医院的“方案二”，医联与市级平台之间的质控要求，参照上一节；医院到医联平台的交换频度以及医联平台到市级平台的交换频度，也都参照上一节。
（这对医联平台提出了很高的改造要求！
）
3.4.3.三甲医院的方案三
三甲医院直接连入市平台系统
分拣情况
孕保
1、应用录入的内容入市妇幼临时库；
2、市妇幼质控合格的（入市妇幼正式库）并推给三甲医院所属的区妇幼，入正式库；
3、质控不合格，市妇幼通知三甲医院修改
当孕妇户籍地址不在本区时，可能有A区上传，市级平台下发到A、B两区。
出生
1、应用录入的内容入市妇幼临时库；
2、市妇幼质控后（入市妇幼正式库）并推给三甲医院所属的区妇幼，入正式库；
3、区妇幼正式库数据交换给区疾控，区疾控质控后反馈给区妇幼，区妇幼反馈给市妇幼；
4、市妇幼通知三甲医院修改。
不存在A区è市级平台èB区
艾梅乙
同“孕保”
不存在A区è市级平台èB区
妇女病
同“孕保”
无
儿保
1、三甲医院通过市妇幼平台提供的应用,直接录入数据
2、三甲医院通过接口,向市妇幼平台提供数据
3、市妇幼平台进行质控后,根据儿童现居住地,分发给区妇幼平台
根据儿童居住地,可能有A区è市级平台èB区
3.5.实时交换与非实时交换
所有实时的数据交换都采用消息中间件、服务或数据交换平台来实现；所有非实时的数据交换都采用数据交换平台来实现。
详见下表说明。
实时
非实时
区属医院à区平台
不详
已有
区平台à市级平台
消息中间件、服务或数据交换平台（暂无）
数据交换平台（已有）
市平台à区级平台
消息中间件、服务或数据交换平台（暂无）
数据交换平台（已有）
三甲医院à医联平台
消息中间件、服务或数据交换平台（暂无）
数据交换平台（已有）
医联平台à市级平台
消息中间件、服务或数据交换平台（暂无）
数据交换平台（已有）
非实时交换拟采用健康信息平台上已经部署使用的万达信息研发中心的产品CuteInfo。
在市平台区县端共享区部署数据库前置机，作为市区交换的中转。
也可以配置CuteInfo的交换频度，使之成为实时交换的工具。
消息中间件可采用万达信息研发中心的消息中间件产品CuteMessage。
在市平台区县端共享区部署CuteMessage的转发组件xSRVgateway，作为区县妇幼平台和市妇幼平台实时数据交换的中继站。
自建妇幼平台的区县与市平台的实时和非实时数据交换需要万达信息与自建妇幼平台的区县厂商进行协调（可能牵涉到一些协调工作）。
3.6.充分利用院内数据
除了三甲医院的“方案二”外，其他的几种数据流转方案，都牵涉到如何将医院内部系统的信息转移到妇幼系统中。
可采用以下三种模式。
模式一：
借助于医联平台或各区县平台的“智能提醒”系统，拓展接口，将医院内部系统数据实时读入到妇幼应用系统中。
（3.2、3.3.1、3.3.3默认采用此种方式）
模式二：
制定实时或非实时的接口，将医院内部系统信息上传到区级和市级妇幼平台中。
然后与应用系统中的数据做整合。
（参考“三甲医院的方案二”）
模式三：
上述条件都不满足，则只有手工在妇幼应用系统中重新录入，应尽量避免这种情况。
建议：
上面这样的分法其实有点乱，可以归纳成：
必须部署在市平台的应用（孕保-产前筛查、急救中心）
需录入的数据
医院系统内部数据
三甲医院
通过应用保存在市平台上
通过智能提醒插件拷贝到妇幼系统中，或按上述模式二上传（类似方案二）。
建议尽量部署在区平台的应用
需录入的数据
医院系统内部数据
三甲医院
通过应用保存在区平台或市平台上；落在区平台的数据应上传到市平台（方案一）；落在市平台的数据应回传到区平台（方案三）。
通过智能提醒插件拷贝到妇幼系统中，或按上述模式二上传（方案二）。
一、二医院
通过应用保存在区平台上
通过智能提醒插件拷贝到妇幼系统中，或按上述模式二上传（类似方案二）。
注：
由于可能频繁的发起跨区调阅，建议孕保系统部署在市里。
3.7.与外部平台的数据交换
妇幼的出生系统需要与疾控部门进行数据交换，我们建议数据交换的层面在市级平台，即，市妇幼与市疾控做数据交换。
4.实现方案及问题分析
4.1.网络连通性验证
4.1.1.区平台与市平台
即市民健康网现有的政务网通路，各区都有一个市卫计委下发的前置机（装有Oracle前置库，不同的业务数据使用不同的用户；并装有万达信息的数据交换平台Cuteinfo）。
目前市级大卫生平台要求各区上传的诊疗数据、市疾控要求各区上传的疾控数据，都通过此前置机上传。
以后市妇幼要求各区上传的妇幼数据也需通过此通路上传，将会引起一定的数据库访问瓶颈和网络传输瓶颈。
另据相关同事反映，市卫计委为每个区县下发的前置机不止这一台，如征得市卫计委和各区县的同意，也可以使用。
4.1.2.三甲医院与市平台
直接的通路包括：
突发公卫专网（193.168.X.X）；为“临检（？
）”准备的前置机及其专线（一直未使用）。
间接的通路包括：
经“医联平台”跳转。
4.1.3.三甲医院与所在区平台
需协调区平台，使其网络地址映射到政务网地址（10.X.X.X），三甲医院即可访问（按刘璐老师的说法）。
4.2.实时数据质控
4.2.1.实时数据交换的质控
因区县数据实时入市核心库，对于上传的数据，特别是不使用标准版的区县数据，需进行一定的质控，以避免上传无效数据，影响系统整体运转的情况。
主要需考虑以下几个问题：
●每一个数据接口的数据质量要求（必填项、允许值范围等）
●不合格数据的处理反馈机制
●不合格数据的修改、重报机制
以上问题需结合实际业务进行分析解决。
4.2.2.应用系统的质控
初步考虑同上。
4.3.传输效率验证
因系统涉及到的网络环境复杂，接入单位多，建议考虑搭建一个简易系统测试各级单位以及医院之间的连通性。
●市公卫平台部署一个测试服务端（模拟市妇幼系统位置）
●先期选择一两个区县平台部署一个测试服务端（模拟区县妇幼系统位置）
●市平台区县共享区部署一个测试网络中转系统（向研发中心申请一个CuteMessage的试用版）
●选择一两个试点医院部署CuteMessage前置端（根据其网络情况，如医生工作站能直接连通区县平台则无需部署）
以上可能需各级用户和相关公司以及本公司内部其他项目组的配合。
4.4.数据交换日志
●对每一笔数据交换均进行详细的日志记录；
●日志记录允许区县、医院端自助查询；
●为减少数据量，对超出一定时间的日志进行归档。
4.5.网络或应用接口故障
应用系统接口应具备容错性，当发生网络故障或第三方应用故障时，能保证系统在一定范围内的正常运转，并在故障恢复后尽快恢复系统正常运转。
●无法获取远程数据时，显示相应的提示消息，如不影响业务的开展，允许继续执行业务操作；
●无法传输数据时，对待传输数据进行标记，并在系统恢复后续传；
●发生故障时均需记录详细日志以便排查错误原因
升级会员 