宁波市通用就诊卡三期项目接口标准及数据采集解决方案.docx
- 文档编号:10389333
- 上传时间:2023-05-25
- 格式:DOCX
- 页数:27
- 大小:207.42KB
宁波市通用就诊卡三期项目接口标准及数据采集解决方案.docx
《宁波市通用就诊卡三期项目接口标准及数据采集解决方案.docx》由会员分享,可在线阅读,更多相关《宁波市通用就诊卡三期项目接口标准及数据采集解决方案.docx(27页珍藏版)》请在冰点文库上搜索。
宁波市通用就诊卡三期项目接口标准及数据采集解决方案
宁波市通用就诊卡三期项目
接口标准及数据采集解决方案
宁波市卫生局
二〇〇九年四月
目录
一、概述3
1.编写目的3
2.项目背景3
3.总体目标3
4.总体设计思想3
二、前置机应用部署规格4
1.监控表规范4
1.1.监控表表结构4
1.1.1.表名:
T_MONITOR_PERSON_INFO4
1.2.监控表补充说明6
2.共享资源规范7
2.1.共享资源信息的说明7
2.2.共享资源信息控制说明7
2.3.共享资源信息的获取8
2.3.1.获取共享资源信息的接口方式8
2.3.1.1.WEBService的解释8
2.3.1.1.1.什么是webservice8
2.3.1.1.2.基本概念8
2.3.1.2.WebService的调用9
2.3.1.2.1.什么时候使用WebServices9
2.3.1.2.2.如何调用WebServices10
2.3.1.2.3.高层接口10
2.3.1.2.4.低层接口10
2.4.共享资源信息的说明10
3.数据初始化及部署11
三、业务场景设计11
1.新增卡11
2.换卡12
3.补卡14
4.跨院就诊15
5.患者信息更新17
6.医保/农保用户就诊及信息修改。
18
四、其他事项20
一、概述
1.编写目的
此文档为“宁波市医疗就诊卡信息交换与管理系统”之前置机与医院HIS系统数据交互解决方案。
2.项目背景
目前宁波市区各主要医院的发卡量之和达到600万张以上,预计至少有三分之二是重复办卡。
患者到医院看病时要买一张该医院就诊卡,到另外一家医院看病时又要买一张就诊卡,这样患者看病十分不方便。
另外,目前全市各医院的门诊病历本也不通用,使得病人手中往往有多本病历本,给病人造成一定的浪费。
对于医保和农保患者,到医院看病只须出示医保卡或农保卡,目前宁波市医保用户约90万,农保用户100多万,但对于更多的自费病人,去不同医院看病会办理不同的就诊卡,甚至在同一家医院也会办理多张就诊卡。
为了实现宁波市范围内各家医院能跨院就诊,实现市民就诊看病“一卡通”,为此建设医疗就诊卡信息交换与管理系统。
3.总体目标
●统一各家医院目前各自发放的就诊卡,使患者能够领过一次就诊卡,即可以在各家医院通行使用
●为进一步建立以患者为本位的诊疗档案,实现对患者诊疗信息的交换共享和协同服务打下基础
4.总体设计思想
为了降低系统的耦合度,我们采用缓存表和WEB应用作为媒介来实现HIS系统与前置机数据的交互。
●缓存表是指监控表,其中所有数据都由医院来提供,保存了医院系统采集的新就诊卡数据和患者更新数据,现改为医院调用WebService接口,由WebService来访问数据库。
●共享资源信息提供就诊卡中心所有患者信息及卡信息,它通过WEBService模式供医院调用查询。
二、前置机应用部署规格
1.监控表规范
监控表是一张物理表,结构和各医院厂商的人员信息表类似。
1.1.监控表表结构
1.1.1.表名:
T_MONITOR_PERSON_INFO
字段名
字段描述
数据类型
长度
备注
LOGID
LOGID
VARCHAR2
30
Notnull
IP
医院终端IP地址
VARCHAR2
15
Notnull
MAC
医院终端MAC地址
VARCHAR2
48
REPORT_HOSPITAL
上报医院编号
VARCHAR2
6
Notnull
PERSONID
档案号
VARCHAR2
30
NAME
姓名
VARCHAR2
20
Notnull
SEX
性别
VARCHAR2
1
0:
男;1:
女
Notnull
BIRTHDAY
出生日期
DATE
CFTYPE
证件类型
VARCHAR2
1
0:
身份证;
9:
其他;
CFNUMBER
证件号码
VARCHAR2
60
BLOOD_TYPE
血型
VARCHAR2
1
WEDLOCK
婚姻状况
VARCHAR2
1
VARCHAR2
60
CARD_TYPE
卡类型
VARCHAR2
1
0:
医保卡;1:
农保卡;2:
就诊卡;9:
其它卡
CARD_NUMBER
卡号
VARCHAR2
20
INSURANCE_NO
保险号
VARCHAR2
20
医保卡对应的保险号;或者是就诊卡的明码;
REGE_TIME
建卡时间
DATE
HOSPITAL_NUMBER
建卡医院代码
VARCHAR2
10
CARD_STATUS
卡状态
VARCHAR2
1
0:
正常;1:
暂停;3:
挂失;4:
损坏注销;5:
遗失注销
Notnull
OPT_TIME
操作时间
DATE
保存暂停时间或者暂停时间或者注销时间或者挂失时间
ADDRESS
详细住址
VARCHAR2
100
PROVINCE
省/市
VARCHAR2
6
DISTRICT
区
VARCHAR2
6
STREET
街道
VARCHAR2
6
HOME_POSTCODE
家庭住址邮政编码
VARCHAR2
6
HOME_PHONE
家庭电话
VARCHAR2
20
COMPANY
工作单位
VARCHAR2
100
COMPANY_ADDRESS
单位地址
VARCHAR2
100
COMPANY_POSTCODE
单位邮编
VARCHAR2
6
METIER
职业
VARCHAR2
100
COMPANY_PHONE
单位电话
VARCHAR2
20
MOBILE
手机号
VARCHAR2
20
FOLK_NAME
(联系人)家属姓名
VARCHAR2
20
FOLK_PHONE_NUMBER
(联系人)家属电话
VARCHAR2
60
OPTYPE
操作类型
VARCHAR2
1
Notnull;0新增;1修改;2删除;
REPORT_TIME
记录上传前置机时间
DATE
Notnull;保存数据从医院HIS系统中更新到前置机缓存表的时间,精确到时分秒
OLD_CARD_NUMBER1
旧的就诊卡卡号1
VARCHAR2
20
OLD_CARD_HOSPITAL1
旧的就诊卡发卡医院1
VARCHAR2
6
OLD_CARD_NUMBER2
旧的就诊卡卡号2
VARCHAR2
20
OLD_CARD_HOSPITAL2
旧的就诊卡发卡医院2
VARCHAR2
6
OLD_CARD_NUMBER3
旧的就诊卡卡号3
VARCHAR2
20
OLD_CARD_HOSPITAL3
旧的就诊卡发卡医院3
VARCHAR2
6
OLD_CARD_NUMBER4
旧的就诊卡卡号4
VARCHAR2
20
OLD_CARD_HOSPITAL4
旧的就诊卡发卡医院4
VARCHAR2
6
OLD_CARD_NUMBER5
旧的就诊卡卡号5
VARCHAR2
20
OLD_CARD_HOSPITAL5
旧的就诊卡发卡医院5
VARCHAR2
6
CREATE_TIME
创建时间
DATE
Notnull本记录在HIS系统中创建的时间
MODIFY_TIME
记录修改时间
DATE
Notnull本记录在HIS中最后一次修改时间,第一次默认等于创建时间
1.2.监控表补充说明
●LOGID:
是能唯一标识记录的主键。
编码规则:
6位医院编码+8位年月日+8位流水号,其中医院编码见清单。
LOGID由医院HIS来生成。
●档案号:
档案号非必填,凡是未填写档案号的数据,系统认为它是新增患者信息的数据(不区分医保、农保、就诊卡患者);凡是填写了档案号的数据,系统认为是修改患者信息。
本字段应与操作类型字段进行校验。
●卡类型:
0:
医保卡;1:
农保卡;2:
就诊卡;9:
其它卡。
●卡号:
根据卡类型,填写相应的卡号。
如果是就诊卡,只保存新就诊卡卡号。
●操作类型:
0新增;1修改;2删除;本字段要和档案号字段进行校验。
●更新时间:
数据从医院HIS系统中更新到前置机缓存表的时间,精确到时分秒。
●旧的就诊卡卡号1:
如果是换卡业务场景,需要保存旧的就诊卡卡号。
●旧的就诊卡卡号2~5同理
●旧的就诊卡发卡医院1:
如果输入的旧的就诊卡卡号,一定要保存对应的医院编号。
●旧的就诊卡发卡医院2~5同理。
●现改为医院调用WebService接口,由WebService来访问数据库。
2.共享资源规范
2.1.共享资源信息的说明
共享资源信息由四部分组成,分别是人员基本信息、人员扩展信息、卡信息、就诊卡历史信息。
这四类资源的ER关系如下:
其中:
●人员基本信息与人员扩展信息是一对多的关系,通过档案号关联
●人员基本信息和就诊卡信息是一对多的关系,通过档案号关联
●就诊卡历史记录表保存了各家医院旧的就诊卡信息,主要为了实现跨院换卡功能
2.2.共享资源信息控制说明
人员基本信息表、人员扩展信息表、卡信息表是通过档案号来进行关联的。
REPORT_TIME(更新时间):
当前置机端发布更新数据时,会把更新的时间保存在本字段中。
医院HIS可根据本字段选择性地更新增量数据。
2.3.共享资源信息的获取
2.3.1.获取共享资源信息的接口方式
为了安全起见,二期方案变一期方案中采用的开放共享表提供直接查询模式为采用WEBService模式实现。
2.3.1.1.WEBService的解释
2.3.1.1.1.什么是webservice
Webservice就是一个应用程序,它向外界暴露出一个能够通过Web进行调用的API,通过Web来调用这个应用程序。
Webservices是建立可互操作的分布式应用程序的新平台。
Webservice平台是一套标准,它定义了应用程序如何在Web上实现互操作性,通过Webservice标准对这些服务进行查询和访问。
构建后Webservice,用SOAPToolkit等方法把其暴露给Web客户,任何语言、任何平台上的客户都可以阅读其WSDL文档,以调用这个Webservice。
客户根据WSDL描述文档,会生成一个SOAP请求消息。
Webservice都是放在Web服务器(如IIS)后面的,客户生成的SOAP请求会被嵌入在一个HTTPPOST请求中,发送到Web服务器来。
Web服务器再把这些请求转发给Webservice请求处理器。
请求处理器的作用在于解析收到的SOAP请求,调用Webservice,然后再生成相应的SOAP应答。
Web服务器得到SOAP应答后,会再通过HTTP应答的方式把它送回到客户端。
2.3.1.1.2.基本概念
●SOAP
构建的Webservice需要提供给其他应用调用它。
简单对象访问协议(SOAP)提供了标准的远程过程调用(RPC)方法来调用Webservice。
SOAP规范定义了SOAP消息的格式,以及怎样通过HTTP协议来使用SOAP。
SOAP也是基于XML和XSD的,XML是SOAP的数据编码方式。
客户端和服务端之间的方法调用请求和结果返回值都放在这些消息里。
●XML和XSD
可扩展的标记语言(XML)是Webservice平台中表示数据的基本格式。
除了易于建立和易于分析外,XML主要的优点在于它既是平台无关的,又是厂商无关的。
无关性是比技术优越性更重要的。
XML解决了数据表示的问题,但它没有定义一套标准的数据类型,更没有说怎么去扩展这套数据类型。
例如,整形数到底代表什么?
16位,32位,还是64位?
这些细节对实现互操作性都是很重要的。
W3C制定的XMLSchema(XSD)就是专门解决这个问题的一套标准。
它定义了一套标准的数据类型,并给出了一种语言来扩展这套数据类型。
Webservice平台就是用XSD来作为其数据类型系统的。
当用某种语言来构造一个Webservice时,为了符合Webservice标准,所有使用的数据类型都必须被转换为XSD类型。
●WSDL(WebServicesDescriptionLanguage)
用于描述服务端所提供服务的XML格式。
WSDL文件里,描述了服务端提供的服务、调用方法,以及调用时所要遵循的格式,比如调用参数和返回值的格式等等。
WSDL很像COM编程里的IDL(InterfaceDescriptionLanguage),是服务器与客户端之间的契约,双方必须按契约严格行事才能实现功能。
●UDDI
UDDI的目的是为电子商务建立标准.
UDDI是一套基于Web的、分布式的、为WebService提供的、信息注册中心的实现标准规范,同时也包含一组使企业能将自身提供的WebService注册,以使别的企业能够发现的访问协议的实现标准。
●远程过程调用RPC与消息传递
WebService本身其实是在实现应用程序间的通信。
有两种应用程序通信的方法:
RPC远程过程调用和消息传递。
使用RPC的时候,客户端的概念是调用服务器上的远程过程,通常方式为实例化一个远程对象并调用其方法和属性。
RPC系统试图达到一种位置上的透明性:
服务器暴露出远程对象的接口,而客户端就好像在本地使用的这些对象的接口一样,这样就隐藏了底层的信息,客户端也就根本不需要知道对象是在哪台机器上。
2.3.1.2.WebService的调用
2.3.1.2.1.什么时候使用WebServices
Webservice是创建可互操作的分布式应用程序的新平台。
Webservice的主要目标是跨平台的可互操作性。
为了达到这一目标,Webservice是完全基于XML、XSD等独立于平台、独立于软件供应商的标准的。
Webservice在应用程序跨平台和跨网络进行通信的时候是非常有用的。
Webservice适用于应用程序集成、B2B集成、代码和数据重用,以及通过Web进行客户端和服务器的通信的场合。
2.3.1.2.2.如何调用WebServices
客户端:
取得服务端的服务描述文件WSDL,解析该文件的内容,了解服务端的服务信息,以及调用方式。
根据需要,生成恰当的SOAP请求消息(指定调用的方法,已经调用的参数),发往服务端。
等待服务端返回的SOAP回应消息,解析得到返回值。
服务端:
生成服务描述文件,以供客户端获取。
接收客户端发来的SOAP请求消息,解析其中的方法调用和参数格式。
根据WSDL和WSML的描述,调用相应的COM对象来完成指定功能,并把返回值放入SOAP回应消息返回给用户。
2.3.1.2.3.高层接口
使用高层接口,不需要知道SOAP和XML的任何信息,就可以生成和使用一个WebService。
SoapToolkit2.0通过提供两个COM对象――SoapClient和SoapServer,来完成这些功能。
在客户端,只需要生成一个SoapClient实例,并用WSDL作为参数来调用其中的mssoapinit方法。
SoapClient对象会自动解析WSDL文件,并在内部生成所有WebService的方法和参数信息。
之后,你就可以像调用IDispatch接口里的方法一样,调用里面所有的方法。
在VB或是脚本语言里,你甚至可以直接在SoapClient对象名后面直接加上.方法(参数…)进行调用。
2.3.1.2.4.低层接口
要使用低层接口,你必须对SOAP和XML有所了解。
你可以对SOAP的处理过程进行控制,特别是要做特殊处理的时候。
在客户端,首先要创建一个HttpConnector对象,负责HTTP连接。
设定Connector的一些头部信息,比如EndPoinURL和SoapAction等。
如果网络连接需要使用代理服务器,那也要在这里设定相关的信息。
接着创建SoapSerializer对象,用于生成Soap消息。
按照WSDL里定义,把所有参数按顺序序列化,得到一个完整的SOAP请求消息。
该Soap消息,作为Payload通过HttpConnector被发送到服务端。
最后,生成一个SoapReader对象,负责读取服务端返回的SOAP消息,取得其中的返回值。
2.4.共享资源信息的说明
详见“就诊卡二期接口开发说明.doc”文档。
3.数据初始化及部署
数据的初始化工作分为三步来进行:
●第一步采集各家医院的就诊卡数据库,将各家医院就诊卡数据汇总为全市就诊卡历史库;
●第二步将各个区的农保数据汇总为全市农保数据库,将全市农保数据更新到共享资源信息中(人员基本信息、人员扩展信息、卡信息);
●第三步将全市医保数据库更新到共享资源信息中(人员基本信息、人员扩展信息、卡信息)。
三、业务场景设计
根据实际业务来看,主要业务场景有以下六种:
1.新增卡
业务说明:
患者去医院办理一张新就诊卡。
业务流程:
1.患者去挂号处填写信息表和购买就诊卡;
2.HIS通过挂号处将患者信息增加到医院HIS系统;
3.HIS将新增患者信息提交到区前置机;
4.区前置机将新增数据提交给区数据中心;区数据中心将数据上传到市数据中心,市中心再将更新后的数据发布给其他前置机。
技术实现:
1.HIS将患者信息按照规范提交到区前置机监控表中。
控制说明:
a)必填项:
医院终端IP(或者医院终端MAC地址)、上报医院编号、姓名、性别、出生日期、卡类型、卡号、卡状态、建卡时间、建卡医院代码、保险号、操作类型、记录创建时间、记录修改时间、记录上传前置机时间。
b)档案号:
不能填写。
c)卡类型:
2就诊卡。
d)操作类型:
0新增。
e)卡状态:
0正常
2.换卡
业务说明:
持一张或多张旧就诊卡去任意一家联网医院换新就诊卡。
业务流程:
1.患者去医院挂号处换卡;
2.挂号处通过刷旧卡查询区县前置机,获取人员信息
3.挂号处通过刷旧卡查询HIS系统,此时有两种情况:
a)如果在HIS中查询到患者信息,则执行第4步;
b)如果HIS系统中没有查询到患者信息,则执行第3步;
4.HIS系统向前置机查询旧卡,此时有两种情况:
a)若查询到信息,则执行第4步;
b)若没有查询到患者信息,则跳到第8步;
5.HIS系统获取患者旧卡信息,并显示在挂号处;
6.HIS系统获取新就诊卡信息(通过刷新卡),并连同人员信息一起保存到HIS系统;
7.HIS系统将换卡信息(新卡、旧卡、人员信息)提交到前置机;
8.前置机将最新数据提交给区数据中心,区数据中心将数据上传到市数据中心,市中心再将更新后的数据发布给其他前置机。
9.如果未找到旧卡信息则做新增卡操作
技术实现:
1.HIS系统通过WebService接口查询前置机共享资源信息。
控制说明:
a)通过旧卡内数据查询,有重复数据则返回多条数据(按发卡医院顺序排列,由医院人员选择确定)。
b)传入条件:
卡内数据
c)返回结果:
历史卡表信息
2.HIS系统将患者信息提交到前置机监控表,控制说明:
d)必填字段:
医院终端IP(或者医院中断MAC地址)、上报医院编号、姓名、性别、出生日期、卡类型、卡号、卡状态、建卡时间、建卡医院代码、保险号、操作类型、记录创建时间、记录修改时间、更新时间、旧的就诊卡卡号1、旧的就诊卡发卡医院1。
e)档案号:
不能填写。
f)卡类型:
2就诊卡。
g)操作类型:
0新增。
h)更新时间:
数据从医院HIS系统中更新到前置机缓存表的时间,精确到时分秒。
i)旧的就诊卡卡号1:
保存旧的就诊卡卡号。
j)旧的就诊卡发卡医院1:
保存对应的医院编号。
k)后台控制:
卡状态=0正常
3.补卡
场景前置条件:
患者就诊卡因就诊卡遗失或就诊卡损坏两种原因需要补办,并且患者在办理就诊卡时提供了完整的身份证件号。
需要注意的是,如果患者无法提供身份证和以及系统内身份证号不完整的患者,系统将不提供补办就诊卡业务。
两个主要业务场景:
一、无法提供身份证的患者或身份证号不完整患者按照新增卡场景来执行。
二、正常补卡流程按照以下场景执行:
1.患者去医院挂号处出示身份证并申请补卡;
2.挂号处通过身份证号码(遗失补卡)或就诊卡明码(损坏补卡)到HIS系统查询旧卡信息,此时有两种情况:
a)如果在HIS中查询到患者信息,则执行第4步;
b)如果HIS系统中没有查询到患者信息,则执行第3步;
3.HIS系统向前置机提交查询旧卡信息需求,此时有两种情况:
a)若查询到信息,则执行第4步;
b)若没有查询到患者信息,则执行第8步;
4.前置机返回患者旧卡信息到HIS系统。
5.HIS系统将旧就诊卡信息提交到前置机:
操作类型为2(删除),卡状态为4(损坏注销)或5(遗失注销)
6.HIS系统将新就诊卡信息(通过刷新卡),并连同人员信息一起保存到HIS系统;(进行此环节操作,挂号处人员必须保证患者提供的身份证和系统内信息一致)
7.HIS系统将患者信息(新卡、人员信息)提交到前置机;
8.前置机将最新数据提交给区数据中心,区数据中心将数据上传到市数据中心,市中心将旧卡信息打上“注销”标记,并保存注销纪录。
(下次遗失卡再来用时,可以提示,不能再用了。
)再将更新后的数据发布给其他前置机。
9.如果未找到旧卡信息则做新增卡操作。
技术实现:
1.分为遗失补卡和损坏补卡两种情况
a)遗失补卡:
HIS根据身份证号查询HIS及调用前置机WebService接口查询患者信息。
i.传入条件:
身份证号
ii.返回结果:
个人信息和扩展信息(可能多条)
b)损坏补卡:
HIS根据就诊卡明码查询HIS及调用前置机WebService接口查询患者信息。
i.传入条件:
就诊卡明码
ii.返回结果:
卡信息、个人信息和扩展信息
2.HIS将患者信息提交到监控表,控制说明:
a)必填字段:
档案号、医院终端IP(或者医院中断MAC地址)、上报医院编号、姓名、性别、出生日期、证件类型、证件号、卡类型、卡号、卡状态、建卡时间、建卡医院代码、操作类型、记录创建时间、记录修改时间、更新时间。
b)卡类型:
2:
就诊卡。
c)操作类型:
1新增、2删除。
d)更新时间:
数据从医院HIS系统中更新到前置机缓存表的时间,精确到时分秒。
e)卡状态为:
4(损坏注销)或5(遗失注销)
4.跨院就诊
业务说明:
患者已经办理过新的就诊卡,并且到任意一家联网医院进行就诊。
业务流程:
1.患者在挂号处出示在它院办理的就诊卡;
2.挂号处刷就诊卡查询HIS系统;此时有两种情况:
a)如果查询到患者信息,则跨院就诊已实现,该流程结束;
b)如果没有查询到患者信息,则继续第3步。
3.HIS系统查询前置机;
a)
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 宁波市 通用 就诊 卡三期 项目 接口标准 数据 采集 解决方案