与基于云计算的医院信息系统对接的医保处理系统的制作方法

本发明涉及数据信息处理技术领域，特别涉及一种与基于云计算的医院信息系统对接的医保处理系统。

背景技术：

基于云计算的的医院信息系统(hospitalinformationsystem，his)又称之为云his系统，其最大的优点就是投入少、上线快，并且系统内的业务板块还可根据实际情况进行配选，这些都是非常符合中小规模民营医疗机构的轻资产运营需求的。但是随着云his系统业务的发展，我们发现一个问题，那就是各地区医保系统的接口并不是完全一致的，这就导致云端系统要不停开发对接各地区医保系统的处理流程，甚至要在每个业务板块中嵌入不同地区的医保处理流程。这样无形中就增加了云端的复杂度和耦合度，从而使得云his系统的迭代效率降低、模块化性能减弱。再加上不同地区的网络传输效率差异，远程的云his系统很难与每个地区的医保系统之间都保持同步，从而云端医保流程越复杂则医保交易超时失败的频率越高。

技术实现要素：

本发明的目的，就是针对现有技术的缺陷，提供一种与基于云计算的医院信息系统对接的医保处理系统,采用标准指令或服务接口与云his系统间进行通讯，并将与门诊、住院相关的对接各地区医保系统的处理流程从原有的云端转移到本地，这样就可以彻底解决云端医保业务过度耦合、错误率高的问题。

为实现上述目的，本发明实施例提供了一种与基于云计算的医院信息系统对接的医保处理系统，所述系统包括：门诊处理模块、住院处理模块、数据库、医保接口模块和读卡器模块；

所述门诊处理模块分别与医院信息系统、所述数据库、所述医保接口模块和所述读卡器模块连接；所述门诊处理模块包括门诊收费处理单元和门诊退费处理单元；所述门诊收费处理单元用于识别所述医院信息系统发送的门诊收费指令数据，并通过所述读卡器模块、所述医保接口模块和所述数据库进行第一用户门诊收费操作；所述门诊退费处理单元用于识别所述医院信息系统发送的门诊退费指令数据，并通过所述医保接口模块和所述数据库进行第一用户门诊退费操作；

所述住院处理模块分别与所述医院信息系统、所述数据库、所述医保接口模块和所述读卡器模块连接；所述住院处理模块包括住院登记处理单元、住院费用上传处理单元、住院结算处理单元和住院取消处理单元；所述住院登记处理单元用于识别所述医院信息系统发送的住院登记指令数据，并通过所述读卡器模块、所述医保接口模块和所述数据库进行第一用户住院登记操作；所述住院登记处理单元还用于识别所述医院信息系统发送的住院登记取消指令数据，并通过所述医保接口模块和所述数据库进行第一用户住院登记取消操作；所述住院费用上传处理单元用于识别所述医院信息系统发送的住院费用上传指令数据，并通过所述医保接口模块和所述数据库进行第一用户住院费用上传操作；所述住院费用上传处理单元还用于识别所述医院信息系统发送的住院费用上传取消指令数据，并通过所述医保接口模块和所述数据库进行第一用户住院费用上传取消操作；所述住院结算处理单元用于识别所述医院信息系统发送的住院结算指令数据，并通过所述医保接口模块和所述数据库进行第一用户住院结算操作；所述住院取消处理单元用于识别所述医院信息系统发送的住院取消指令数据，并通过所述读卡器模块、所述医保接口模块和所述数据库进行第一用户住院取消操作；

所述医保接口模块与医保系统连接；所述医保接口模块用于处理所述门诊处理模块与所述医保系统的数据传输，以及所述住院处理模块与所述医保系统的数据传输；所述医保接口模块包括医保信息获取接口、医保门诊登记接口、医保门诊费用上传接口、医保门诊预结算接口、医保门诊结算接口、医保门诊退费接口、医保住院登记接口、医保住院登记取消接口、医保住院费用上传接口、医保住院费用上传取消接口、医保住院预结算接口、医保住院结算接口和医保住院退费接口；

所述读卡器模块与用户医保卡连接；所述读卡器模块用于处理所述门诊处理模块读取所述用户医保卡的操作，以及所述住院处理模块读取所述用户医保卡的操作。

优选的，所述门诊收费处理单元具体用于在进行第一用户门诊收费操作时，向所述读卡器模块发送第一读卡指令数据，并接收从所述读卡器模块返回的第一用户数据；

再通过所述医保信息获取接口向所述医保系统发送所述第一用户数据，并接收所述医保信息获取接口返回的第一用户医保数据；

再对所述第一用户医保数据进行第一医保信息分析操作，并将分析结果向所述医院信息系统发送，并接收从所述医院信息系统发送的第一用户门诊登记数据和第一用户门诊收费数据；

再通过所述医保门诊登记接口向所述医保系统发送所述第一用户门诊登记数据，并接收所述医保门诊登记接口返回的第一门诊登记状态数据；

若所述第一门诊登记状态数据为登记成功，则通过所述医保门诊费用上传接口向所述医保系统发送所述第一用户门诊收费数据，并接收所述医保门诊费用上传接口返回的第一门诊费用上传状态数据；

若所述第一门诊费用上传状态数据为上传成功，则通过所述医保门诊预结算接口向所述医保系统发送门诊预结算指令数据，并接收所述医保门诊预结算接口返回的第一用户门诊预结算数据；

再向所述医院信息系统发送所述第一用户门诊预结算数据，并接收从所述医院信息系统返回的第一用户门诊结算数据；

再通过所述医保门诊结算接口向所述医保系统发送所述第一用户门诊结算数据，并接收所述医保门诊结算接口返回的第一用户门诊结算状态数据；

若所述第一用户门诊结算状态数据为结算成功，则将所述第一用户门诊登记数据、所述第一用户门诊收费数据和所述第一用户门诊结算数据组成的第一用户门诊收费记录存入所述数据库，再通过所述医院信息系统的云服务应用程序接口api修改所述医院信息系统的云端数据库中对应门诊收费记录的数据状态。

优选的，所述门诊退费处理单元具体用于在进行第一用户门诊退费操作时，从所述门诊退费指令数据中提取出第一用户门诊退费单据数据；

再对所述第一用户门诊退费单据数据进行门诊退费分类操作生成第一门诊医保退费数据和第一门诊现金退费数据向所述医院信息系统发送，并接收从所述医院信息系统返回的第一门诊医保退费确认数据；

再调用所述医保门诊退费接口向所述医保系统发送所述第一门诊医保退费确认数据，并接收所述医保门诊退费接口返回的门诊医保退费状态数据；

若所述门诊医保退费状态数据为退费成功，则将所述第一用户门诊退费单据数据和所述第一门诊医保退费确认数据组成的第一用户门诊退费记录存入所述数据库，再通过所述医院信息系统的云服务应用程序接口api修改所述医院信息系统的云端数据库中对应门诊退费记录的数据状态。

优选的，所述住院登记处理单元具体用于在进行第一用户住院登记操作时，向所述读卡器模块发送第二读卡指令数据，并接收从所述读卡器模块返回的第二用户数据；

再通过所述医保信息获取接口向所述医保系统发送所述第二用户数据，并接收所述医保信息获取接口返回的第二用户医保数据；

再对所述第二用户医保数据进行第二医保信息分析操作，并将分析结果向所述医院信息系统发送，并接收从所述医院信息系统发送的第一用户住院登记数据；

再通过所述医保住院登记接口向所述医保系统发送第一用户住院登记数据，并接收所述医保住院登记接口返回的第一用户住院登记状态数据；

若所述第一用户住院登记状态数据为登记成功，则将所述第二用户数据、所述第二用户医保数据和所述第一用户住院登记数据组成的第一用户住院登记记录存入所述数据库，再通过所述医院信息系统的云服务应用程序接口api修改所述医院信息系统的云端数据库中对应住院登记记录的数据状态。

优选的，所述住院登记处理单元具体用于在进行第一用户住院登记取消操作时，从所述住院登记取消指令数据中提取出第一用户住院登记取消数据；

再通过所述医保住院登记取消接口向所述医保系统发送所述第一用户住院登记取消数据，并接收所述医保住院登记取消接口返回的第一用户住院登记取消状态数据；并向所述医院信息系统发送所述第一用户住院登记取消状态数据；

若所述第一用户住院登记取消状态数据为取消成功，则将所述第一用户住院登记取消数据转换为第一用户住院登记取消记录存入所述数据库。

优选的，所述住院费用上传处理单元具体用于在进行第一用户住院费用上传操作时，从所述住院费用上传指令数据中提取出第一用户住院费用明细数据；

再通过所述医保住院费用上传接口向所述医保系统发送所述第一用户住院费用明细数据，并接收从所述医保住院费用上传接口返回的第一用户住院费用上传状态数据；

若所述第一用户住院费用上传状态数据为上传成功，则将所述第一用户住院费用明细数据转换为第一用户住院费用上传记录存入所述数据库，再通过所述医院信息系统的云服务应用程序接口api修改所述医院信息系统的云端数据库中对应住院费用记录的数据状态。

优选的，所述住院费用上传处理单元具体用于在进行第一用户住院费用上传取消操作时，从所述住院费用上传取消指令数据中提取出第一用户住院费用取消数据；

再通过所述医保住院费用上传取消接口向所述医保系统发送所述第一用户住院费用取消数据，并接收从所述医保住院费用上传取消接口返回的第一用户住院费用上传取消状态数据；并向所述医院信息系统发送所述第一用户住院费用上传取消状态数据；

若所述第一用户住院费用上传取消状态数据为取消成功，则将所述第一用户住院费用取消数据转换为第一用户住院费用上传取消记录存入所述数据库。

优选的，所述住院结算处理单元具体用于在进行第一用户住院结算操作时，通过所述医保住院预结算接口向所述医保系统发送住院预结算指令数据，并接收所述医保住院预结算接口返回的第一用户住院预结算数据；

再向所述医院信息系统发送所述第一用户住院预结算数据，并接收从所述医院信息系统返回的第一用户住院结算数据；

再通过所述医保住院结算接口向所述医保系统发送所述第一用户住院结算数据，并接收所述医保住院结算接口返回的第一用户住院结算状态数据；

若所述第一用户住院结算状态数据为结算成功，则将所述第一用户住院结算数据转换为第一用户住院结算记录存入所述数据库，再通过所述医院信息系统的云服务应用程序接口api修改所述医院信息系统的云端数据库中对应住院结算记录的数据状态。

优选的，所述住院取消处理单元具体用于在进行第一用户住院取消操作时，从所述住院取消指令数据中提取出第一用户住院退费单据数据；

再对所述第一用户住院退费单据数据进行住院退费分类操作生成第一住院医保退费数据和第一住院现金退费数据向所述医院信息系统发送，并接收从所述医院信息系统返回的住院退费确认指令数据；

若所述住院退费确认指令数据为确认退费，则向所述读卡器模块发送第三读卡指令数据，并接收从所述读卡器模块返回的第三用户数据；

再通过所述医保信息获取接口向所述医保系统发送所述第三用户数据，并接收所述医保信息获取接口返回的第三用户医保数据；

再对所述第三用户医保数据进行第三医保信息分析操作，并将分析结果向所述医院信息系统发送，并接收从所述医院信息系统发送的第一住院医保退费确认数据；

再调用所述医保住院退费接口向所述医保系统发送所述第一住院医保退费确认数据，并接收所述医保门诊退费接口返回的住院医保退费状态数据；

若所述住院医保退费状态数据为退费成功，则将所述第一用户住院退费单据数据和所述第一住院医保退费确认数据组成的第一用户住院退费记录存入所述数据库，再通过所述医院信息系统的云服务应用程序接口api修改所述医院信息系统的云端数据库中对应住院退费记录的数据状态。

本发明实施例提供的一种与基于云计算的医院信息系统对接的医保处理系统,采用标准指令或服务接口与云his系统间进行通讯，并将与门诊、住院相关的对接各地区医保系统的处理流程从原有的云端转移到本地，这样就可以彻底解决云端医保业务过度耦合、错误率高的问题。

附图说明

图1为本发明实施例提供的一种与基于云计算的医院信息系统对接的医保处理系统示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部份实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

为降低云his系统的运行负荷，在云his系统与医保系统之间架设了本发明实施例提供的一种与基于云计算的医院信息系统对接的医保处理系统，并将原来由云his系统处理的与门诊、住院相关的医保处理流程全部迁移到了该医保处理系统上，另外，该医保处理系统还提供本地数据库用以存储医保交互记录数据，也为云his系统核对、回滚医保信息提供了便利。图1为本发明实施例提供的一种与基于云计算的医院信息系统对接的医保处理系统示意图，如图1所示，该医保处理系统10包括：门诊处理模块101、住院处理模块102、数据库103、医保接口模块104和读卡器模块105。

这里，门诊处理模块101用于对接云his系统与医保系统来完成与门诊相关的登记、费用上传、预结算、结算和退费处理流程；住院处理模块102用于对接云his系统与医保系统来完成与住院相关的登记/登记取消、费用上传/费用上传取消、预结算、结算和住院取消等处理流程；数据库103用于被门诊处理模块101和住院处理模块102调用来存储与门诊、住院相关的和医保系统交互的记录数据；医保接口模块104包括多个对接医保系统的应用程序接口(applicationprograminterface，api)，该模块用于将门诊处理模块101和住院处理模块102发送的数据封装为医保系统标准数据发至医保系统，并负责接收、解析医保系统回发的数据再传输至门诊处理模块101和住院处理模块102；读卡器模块105用于对接云his系统内所有型号的读卡器，并负责完成对用户医保卡数据的信息读取操作。下文将分为五部分对各个模块进行更进一步的阐述。

一、门诊处理模块101

如图1所示，门诊处理模块101分别与云his系统、数据库103、医保接口模块104和读卡器模块105连接；门诊处理模块101包括门诊收费处理单元101a和门诊退费处理单元101b。

其中，门诊收费处理单元101a用于识别云his系统发送的门诊收费指令数据，并通过读卡器模块105、医保接口模块104和数据库103进行第一用户门诊收费操作。在本发明实施例提供的一个具体实现方式中，门诊收费处理单元101a具体用于在进行第一用户门诊收费操作时：

步骤1，首先，向读卡器模块105发送第一读卡指令数据，并接收从读卡器模块105返回的第一用户数据；

这里，门诊收费处理单元101a在处理用户门诊收费时，首先需要通过读卡器模块105获得用户医保卡上的个人数据也就是第一用户数据，该数据至少包括用户姓名、年龄、身份证明标识信息、医保用户标识信息等；

步骤2，再通过医保信息获取接口104a向医保系统发送第一用户数据，并接收医保信息获取接口104a返回的第一用户医保数据；

这里，门诊收费处理单元101a在获得了用户的个人数据之后，再通过医保接口模块104的医保信息获取接口104a从医保系统中查询到与第一用户数据对应的当前用户的医保信息也就是第一用户医保数据，该数据至少包括当前用户的医保机构信息、医保类型信息以及与门诊、住院相关的登记信息；

步骤3，再对第一用户医保数据进行第一医保信息分析操作，并将分析结果向云his系统发送，并接收从云his系统发送的第一用户门诊登记数据和第一用户门诊收费数据；

这里，门诊收费处理单元101a在得到当前用户的第一用户医保数据之后要对其数据内容进行医保信息分析，主要是判断当前用户是否有医保、是否处于住院状态、是否有特殊病种备案(诸如大病备案、两病备案之类的)，若有医保且未处于住院状态则进一步判断对应医保机构的门诊报销范围与额度，若有医保且处于住院状态则进一步判断对应医保机构的住院门诊报销范围与额度，若有特殊病种备案则进一步判断具体的备案病种报销范围与额度；在完成医保分析之后，将分析结果向云his系统回发，以便云his系统前端可以根据当前的分析结果对用户门诊的诊疗项目进行自费项目与医保项目的选择；云his系统在完成对当前用户的门诊挂号、看诊、划价之后，会将挂号、看诊、缴费等相关信息分为第一用户门诊登记数据和第一用户门诊收费数据发回给门诊收费处理单元101a，这里第一用户门诊登记数据可以包括用户的个人数据、医保数据、挂号数据、分诊数据、诊疗数据等，第一用户门诊收费数据可由一个或多个收费单据构成，每个收费单据都包括缴费项目数据、缴费明细数据和缴费金额数据；

步骤4，再通过医保门诊登记接口104b向医保系统发送第一用户门诊登记数据，并接收医保门诊登记接口104b返回的第一门诊登记状态数据；

这里，门诊收费处理单元101a在收到第一用户门诊登记数据和第一用户门诊收费数据之后，首先会通过医保接口模块104的医保门诊登记接口104b在医保系统上为当前用户的本次门诊完成门诊登记处理，第一门诊登记状态数据即为医保系统返回的登记处理结果，若该结果为登记成功则继续后续步骤；若该结果为登记失败则门诊收费处理单元101a应停止执行后续步骤，并向云his系统返回登记失败信息；

步骤5，若第一门诊登记状态数据为登记成功，则通过医保门诊费用上传接口104c向医保系统发送第一用户门诊收费数据，并接收医保门诊费用上传接口104c返回的第一门诊费用上传状态数据；

这里，门诊收费处理单元101a在医保系统上成功为当前用户的本次门诊完成门诊登记之后，即可通过医保接口模块104的医保门诊费用上传接口104c将第一用户门诊收费数据上传到医保系统上，做为后续医保系统预结算与结算的参考凭证；第一门诊费用上传状态数据为医保系统返回的上传结果，若为成功则继续后续处理步骤，若为失败则门诊收费处理单元101a可根据具体的失败状态进行对应的处理，例如，若失败状态为类似通讯失败这样的状态则可预先设定上传频率与上传失败次数阈值进行多次传送；

步骤6，若第一门诊费用上传状态数据为上传成功，则通过医保门诊预结算接口104d向医保系统发送门诊预结算指令数据，并接收医保门诊预结算接口104d返回的第一用户门诊预结算数据；

这里，门诊收费处理单元101a在医保系统上成功为当前用户的本次门诊完成费用上传之后，即可通过医保接口模块104的医保门诊预结算接口104d向医保系统发送预结算指令，医保系统随即根据本地预先获取的门诊登记信息、上传费用信息等参考数据，对当前用户本次门诊的医保报销项目进行预结算统计，从而生成第一用户门诊预结算数据返回到门诊收费处理单元101a；

步骤7，再向云his系统发送第一用户门诊预结算数据，并接收从云his系统返回的第一用户门诊结算数据；再通过医保门诊结算接口104e向医保系统发送第一用户门诊结算数据，并接收医保门诊结算接口104e返回的第一用户门诊结算状态数据；

这里，门诊收费处理单元101a在接收到医保系统返回的第一用户门诊预结算数据之后，首先将其发回云his系统以供系统前端进行信息显示和实缴费用调整，发回方式可采用基于接口的数据流方式也可采用基于图形界面的弹窗方式；云his系统的前端基于第一用户门诊预结算数据将当前用户本次门诊的缴费内容分为自费内容和医保报销内容两类向当前用户进行缴费确认，其中医保报销内容不可调整、自费内容可根据当前用户是否选择用户医保卡个人账户进行缴费再进一步调整为现金缴费部分和个人账户缴费部分；在当前用户完成缴费确认之后，云his系统会将用于医保报销的最终缴费数据也就是第一用户门诊结算数据发回到门诊收费处理单元101a；门诊收费处理单元101a随后会将该数据通过医保接口模块104的医保门诊结算接口104e发送到医保系统用以启动医保系统的结算处理流程，第一用户门诊结算状态数据即为医保系统返回的处理结果；若该结果为结算成功则继续后续步骤，若为失败则门诊收费处理单元101a会停止执行后续步骤，并向云his系统返回失败状态；

步骤8，若第一用户门诊结算状态数据为结算成功，则将第一用户门诊登记数据、第一用户门诊收费数据和第一用户门诊结算数据组成的第一用户门诊收费记录存入数据库103，再通过云his系统的云服务应用程序接口api修改云his系统的云端数据库中对应门诊收费记录的数据状态。

这里，门诊收费处理单元101a在医保系统上成功为当前用户的本次门诊完成费用结算之后，会将与本次门诊收费相关的过程数据合并为一条完整的第一用户门诊收费记录存入数据库103中对应的数据列表中，并在数据保存之后将云his系统端与当前用户本次门诊收费操作对应的数据记录的状态修改为已结算状态。

门诊退费处理单元101b用于识别云his系统发送的门诊退费指令数据，并通过医保接口模块104和数据库103进行第一用户门诊退费操作。在本发明实施例提供的又一个具体实现方式中，门诊退费处理单元101b具体用于在进行第一用户门诊退费操作时：

步骤11，首先，从门诊退费指令数据中提取出第一用户门诊退费单据数据；

这里，门诊退费处理单元101b从云his系统处接收到门诊退费指令数据后，首先从该数据中提取出与退费相关的退费单据数据也就是第一用户门诊退费单据数据，该数据类似收费数据，包括退费项目数据、退费明细数据和退费金额数据；

步骤12，再对第一用户门诊退费单据数据进行门诊退费分类操作生成第一门诊医保退费数据和第一门诊现金退费数据向云his系统发送，并接收从云his系统返回的第一门诊医保退费确认数据；

这里，门诊退费处理单元101b会将退费数据进一步细分为自费退费和医保退费两类数据，其中自费退费数据也就是第一门诊现金退费数据为向个人自费支付账户进行退费的费用信息，医保退费数据也就是第一门诊医保退费数据为向医保系统进行退费的费用信息；在进行医保退费之前，门诊退费处理单元101b会将第一门诊医保退费数据和第一门诊现金退费数据发回云his系统以供系统前端进行信息显示和退费调整；云his系统的前端基于第一门诊医保退费数据和第一门诊现金退费数据将当前用户本次门诊的退费内容分为自费退费内容和医保退费内容两类向当前用户进行退费确认，其中医保退费内容不可调整、自费内容可根据当前用户是否选择用户医保卡个人账户进行缴费再进一步调整为现金退费部分和个人账户退费部分；在当前用户完成退费确认之后，云his系统会将用于医保退费最终退费数据也就是第一门诊医保退费确认数据发回到门诊退费处理单元101b；

步骤13，再调用医保门诊退费接口104f向医保系统发送第一门诊医保退费确认数据，并接收医保门诊退费接口104f返回的门诊医保退费状态数据；

这里，门诊退费处理单元101b在获得第一门诊医保退费确认数据之后，会通过医保接口模块104的医保门诊退费接口104f将其发送至医保系统完成对应的退费流程，门诊医保退费状态数据即为医保系统返回的处理状态；若该状态为退费成功则继续执行后续步骤，若为失败则门诊退费处理单元101b会将失败状态反馈给云his系统，并通过调用云his系统提供的数据接口对当前用户的本次门诊退费操作进行数据或流程回滚从而可以不对云his系统中对应的退费数据或流程造成破坏；

步骤14，若门诊医保退费状态数据为退费成功，则将第一用户门诊退费单据数据和第一门诊医保退费确认数据组成的第一用户门诊退费记录存入数据库103，并通过云his系统的云服务应用程序接口api修改云his系统的云端数据库中对应门诊退费记录的数据状态。

这里，门诊退费处理单元101b在医保系统上成功为当前用户的本次门诊完成退费之后，会将与本次门诊退费相关的过程数据合并为一条完整的第一用户门诊退费记录存入数据库103中对应的数据列表中，并在数据保存之后将云his系统端与当前用户本次门诊退费操作对应的数据记录的状态修改为已退费状态。

二、住院处理模块102

如图1所示，住院处理模块102分别与云his系统、数据库103、医保接口模块104和读卡器模块105连接；住院处理模块102包括住院登记处理单元102a、住院费用上传处理单元102b、住院结算处理单元102c和住院取消处理单元102d。

住院登记处理单元102a用于识别云his系统发送的住院登记指令数据，并通过读卡器模块105、医保接口模块104和数据库103进行第一用户住院登记操作。在本发明实施例提供的又一个具体实现方式中，住院登记处理单元102a具体用于在进行第一用户住院登记操作时：

步骤21，首先，向读卡器模块105发送第二读卡指令数据，并接收从读卡器模块105返回的第二用户数据；

这里，住院登记处理单元102a在处理用户住院登记时，首先需要通过读卡器模块105获得用户的医保卡上的个人数据也就是第二用户数据，该数据至少包括用户姓名、年龄、身份证明标识信息、医保用户标识信息等；

步骤22，再通过医保信息获取接口104a向医保系统发送第二用户数据，并接收医保信息获取接口104a返回的第二用户医保数据；

这里，住院登记处理单元102a在获得了用户的个人数据之后，再通过医保接口模块104的医保信息获取接口104a从医保系统中查询到与第二用户数据对应的当前用户的医保信息也就是第二用户医保数据，该数据至少包括当前用户的医保机构信息、医保类型信息以及与门诊、住院相关的登记信息；

步骤23，再对第二用户医保数据进行第二医保信息分析操作，并将分析结果向云his系统发送，并接收从云his系统发送的第一用户住院登记数据；

这里，住院登记处理单元102a在得到当前用户的第二用户医保数据之后要对其数据内容进行医保信息分析，主要是判断当前用户是否有医保、是否处于住院状态、是否有特殊病种备案(诸如大病备案、两病备案之类的)，若有医保且未处于住院状态则进一步判断对应医保机构的住院报销范围与额度，若有医保且处于住院状态则应进行当前用户已住院以及当前登记住院机构的信息提示，若有特殊病种备案则进一步判断具体的备案病种报销范围与额度；在完成医保分析之后，将分析结果向云his系统回发，以便云his系统前端可以根据当前的分析结果对当前用户进行住院登记信息也就是第一用户住院登记数据的数据准备，该数据包括当前用户的个人数据、医保数据、住院机构数据以及与治疗相关的其他数据；云his系统在完成对第一用户住院登记数据的准备之后会将其发回给住院登记处理单元102a；

步骤24，再通过医保住院登记接口104g向医保系统发送第一用户住院登记数据，并接收医保住院登记接口104g返回的第一用户住院登记状态数据；

这里，住院登记处理单元102a在收到第一用户住院登记数据之后，会通过医保接口模块104的医保住院登记接口104g在医保系统上为当前用户的本次住院完成住院登记处理，第一用户住院登记状态数据即为医保系统返回的登记处理结果，若该结果为登记成功则继续后续步骤；若该结果为登记失败则住院登记处理单元102a应停止执行后续步骤，并向云his系统返回登记失败信息；

步骤25，若第一用户住院登记状态数据为登记成功，则将第二用户数据、第二用户医保数据和第一用户住院登记数据组成的第一用户住院登记记录存入数据库103，并通过云his系统的云服务应用程序接口api修改云his系统的云端数据库中对应住院登记记录的数据状态。

这里，住院登记处理单元102a在医保系统上成功为当前用户的本次住院完成登记之后，会将与本次住院登记相关的过程数据合并为一条完整的第一用户住院登记记录存入数据库103中对应的数据列表中，并在数据保存之后将云his系统端与当前用户本次住院登记对应的数据记录的状态修改为已登记状态。

住院登记处理单元102a还用于识别云his系统发送的住院登记取消指令数据，并通过医保接口模块104和数据库103进行第一用户住院登记取消操作。在本发明实施例提供的又一个具体实现方式中，住院登记处理单元102a具体用于在进行第一用户住院登记取消操作时：

步骤31，首先，从住院登记取消指令数据中提取出第一用户住院登记取消数据；

这里，若当前用户想取消在医保系统中登记的住院信息则可通过云his系统向住院登记处理单元102a发送包含了第一用户住院登记取消数据的住院登记取消指令数据来启动取消住院登记的操作；第一用户住院登记取消数据与第一用户住院登记数据对应，也应包含当前用户的个人数据、医保数据、住院机构数据以及与治疗相关的其他数据；

步骤32，再通过医保住院登记取消接口104h向医保系统发送第一用户住院登记取消数据，并接收医保住院登记取消接口104h返回的第一用户住院登记取消状态数据；并向云his系统发送第一用户住院登记取消状态数据；

这里，住院登记处理单元102a在提取出第一用户住院登记取消数据之后，会通过医保接口模块104的医保住院登记取消接口104h在医保系统上为当前用户的本次住院完成取消登记处理，第一用户住院登记取消状态数据即为医保系统返回的取消登记处理结果，若该结果为取消成功则继续后续步骤；若该结果为取消失败则住院登记处理单元102a应停止执行后续步骤，并向云his系统返回取消失败信息；

步骤33，若第一用户住院登记取消状态数据为取消成功，则将第一用户住院登记取消数据转换为第一用户住院登记取消记录存入数据库103。

这里，住院登记处理单元102a在医保系统上成功为当前用户的本次住院完成取消登记之后，会将与本次住院取消登记相关的过程数据合并为一条完整的第一用户住院登记取消记录存入数据库103中对应的数据列表中，并在数据保存之后将云his系统端与当前用户本次住院登记对应的数据记录的状态修改为登记取消状态。

住院费用上传处理单元102b用于识别云his系统发送的住院费用上传指令数据，并通过医保接口模块104和数据库103进行第一用户住院费用上传操作。在本发明实施例提供的又一个具体实现方式中，住院费用上传处理单元102b具体用于在进行第一用户住院费用上传操作时：

步骤41，首先，从住院费用上传指令数据中提取出第一用户住院费用明细数据；

这里，住院登记处理单元102a在医保系统上成功为当前用户的本次住院完成住院登记之后，住院费用上传处理单元102b才可正常响应云his系统发送的住院费用上传指令数据，并从中提取出用于上传的第一用户住院费用明细数据，该数据一般由住院的缴费单据构成，每个缴费单据上都包括缴费项目数据、缴费明细数据和缴费金额数据；

步骤42，再通过医保住院费用上传接口104i向医保系统发送第一用户住院费用明细数据，并接收从医保住院费用上传接口104i返回的第一用户住院费用上传状态数据；

这里，住院费用上传处理单元102b通过医保接口模块104的医保住院费用上传接口104i将第一用户住院费用明细数据上传到医保系统上，做为后续医保系统预结算与结算的参考凭证；第一用户住院费用上传状态数据为医保系统返回的上传结果，若为成功则继续后续处理步骤，若为失败则住院费用上传处理单元102b可根据具体的失败状态进行对应的处理，例如，若失败状态为类似通讯失败这样的状态则可预先设定上传频率与上传失败次数阈值进行多次传送；

步骤43，若第一用户住院费用上传状态数据为上传成功，则将第一用户住院费用明细数据转换为第一用户住院费用上传记录存入数据库103，并通过云his系统的云服务应用程序接口api修改云his系统的云端数据库中对应住院费用记录的数据状态。

这里，住院费用上传处理单元102b在医保系统上成功为当前用户完成住院费用上传之后，会将与本次住院费用上传相关的过程数据合并为一条完整的第一用户住院费用上传记录存入数据库103中对应的数据列表中，并在数据保存之后将云his系统端与当前用户本次上传操作对应的数据记录的状态修改为已上传状态。

住院费用上传处理单元102b还用于识别云his系统发送的住院费用上传取消指令数据，并通过医保接口模块104和数据库103进行第一用户住院费用上传取消操作。在本发明实施例提供的又一个具体实现方式中，住院费用上传处理单元102b具体用于在进行第一用户住院费用上传取消操作时：

步骤51，首先，从住院费用上传取消指令数据中提取出第一用户住院费用取消数据；

这里，若当前用户想取消在医保系统中已经上传的住院费用信息则可通过云his系统向住院费用上传处理单元102b发送包含了第一用户住院费用取消数据的住院费用上传取消指令数据来启动取消已上传的住院费用信息的操作；第一用户住院费用取消数据与第一用户住院费用数据对应；

步骤52，再通过医保住院费用上传取消接口104j向医保系统发送第一用户住院费用取消数据，并接收从医保住院费用上传取消接口104j返回的第一用户住院费用上传取消状态数据；并向云his系统发送第一用户住院费用上传取消状态数据；

这里，住院费用上传处理单元102b在提取出第一用户住院费用取消数据之后，会通过医保接口模块104的住院费用上传取消接口104j在医保系统上为当前用户完成对应住院费用的取消操作，第一用户住院费用上传取消状态数据即为医保系统返回的取消上传的处理结果，若该结果为取消成功则继续后续步骤；若该结果为取消失败则住院费用上传处理单元102b应停止执行后续步骤，并向云his系统返回取消失败信息；

步骤53，若第一用户住院费用上传取消状态数据为取消成功，则将第一用户住院费用取消数据转换为第一用户住院费用上传取消记录存入数据库103。

这里，住院费用上传处理单元102b在医保系统上成功为当前用户完成对应住院费用的取消操作之后，会将与本次取消操作相关的过程数据合并为一条完整的第一用户住院费用上传取消记录存入数据库103中对应的数据列表中，并在数据保存之后将云his系统端与当前用户本次费用上传取消操作对应的数据记录的状态修改为上传取消状态。

住院结算处理单元102c用于识别云his系统发送的住院结算指令数据，并通过医保接口模块104和数据库103进行第一用户住院结算操作。在本发明实施例提供的又一个具体实现方式中，住院结算处理单元102c具体用于在进行第一用户住院结算操作时：

步骤61，首先，通过医保住院预结算接口104k向医保系统发送住院预结算指令数据，并接收医保住院预结算接口104k返回的第一用户住院预结算数据；

这里，住院登记处理单元102a在医保系统上成功为当前用户的本次住院完成住院登记之后，住院结算处理单元102c才可正常响应云his系统发送的住院结算指令数据；在执行住院结算操作时，首先要通过医保接口模块104的医保住院预结算接口104k向医保系统发送预结算指令来启动住院预结算操作，医保系统根据本地预先获取的住院登记信息、住院上传费用信息等参考数据，对当前用户本次住院的医保报销项目进行预结算统计，从而生成第一用户住院预结算数据返回到住院结算处理单元102c；

步骤62，再向云his系统发送第一用户住院预结算数据，并接收从云his系统返回的第一用户住院结算数据；

这里，住院结算处理单元102c在接收到医保系统返回的第一用户住院预结算数据之后，首先将其发回云his系统以供系统前端进行信息显示和实缴费用调整；云his系统的前端基于第一用户住院预结算数据将当前用户本次住院的缴费内容分为自费内容和医保报销内容两类向当前用户进行缴费确认，其中医保报销内容不可调整、自费内容可根据当前用户是否选择用户医保卡个人账户进行缴费再进一步调整为现金缴费部分和个人账户缴费部分；在当前用户完成缴费确认之后，云his系统会将用于医保报销最终缴费数据也就是第一用户住院结算数据发回到住院结算处理单元102c；

步骤63，再通过医保住院结算接口104l向医保系统发送第一用户住院结算数据，并接收医保住院结算接口104l返回的第一用户住院结算状态数据；

这里，住院结算处理单元102c在接收到第一用户住院结算数据之后，会通过医保接口模块104的医保住院结算接口104l将该数据发送到医保系统用以启动医保系统的结算处理流程，第一用户住院结算状态数据即为医保系统返回的处理结果；若该结果为结算成功则继续后续步骤，若为失败则住院结算处理单元102c会停止执行后续步骤，并向云his系统返回失败状态；

步骤64，若第一用户住院结算状态数据为结算成功，则将第一用户住院结算数据转换为第一用户住院结算记录存入数据库103，并通过云his系统的云服务应用程序接口api修改云his系统的云端数据库中对应住院结算记录的数据状态。

这里，住院结算处理单元102c在医保系统上成功为当前用户的本次住院完成费用结算之后，会将与本次住院结算相关的过程数据合并为一条完整的第一用户住院结算记录存入数据库103中对应的数据列表中，并在数据保存之后将云his系统端与当前用户本次住院结算操作对应的数据记录的状态修改为已结算状态。

住院取消处理单元102d用于识别云his系统发送的住院取消指令数据，并通过读卡器模块105、医保接口模块104和数据库103进行第一用户住院取消操作。在本发明实施例提供的又一个具体实现方式中，住院取消处理单元102d具体用于在进行第一用户住院取消操作时：

步骤71，首先，从住院取消指令数据中提取出第一用户住院退费单据数据；

这里，住院取消处理单元102d从云his系统处接收到住院取消指令数据后，首先从该数据中提取出与住院取消相关的退费单据数据也就是第一用户住院退费单据数据，该数据类似收费数据，包括退费项目数据、退费明细数据和退费金额数据；

步骤72，再对第一用户住院退费单据数据进行住院退费分类操作生成第一住院医保退费数据和第一住院现金退费数据向云his系统发送，并接收从云his系统返回的住院退费确认指令数据；

这里，住院取消处理单元102d会将退费数据进一步细分为自费退费和医保退费两类数据，其中自费退费数据也就是第一住院现金退费数据为向个人自费支付账户进行退费的费用信息，医保退费数据也就是第一住院医保退费数据为向医保系统进行退费的费用信息；在进行医保退费之前，住院取消处理单元102d会将第一住院医保退费数据和第一住院现金退费数据发回云his系统以供系统前端进行信息显示和退费调整；云his系统的前端基于第一住院医保退费数据和第一住院现金退费数据将当前用户本次住院取消的退费内容分为自费退费内容和医保退费内容两类向当前用户进行退费确认，其中医保退费内容不可调整、自费内容可根据当前用户是否选择用户医保卡个人账户进行缴费再进一步调整为现金退费部分和个人账户退费部分；在当前用户完成退费确认之后，云his系统会向住院取消处理单元102d发送住院退费确认指令数据；若该数据为确认退费则继续执行后续流程，若为取消退费则住院取消处理单元102d会停止执行后续步骤，并向云his系统返回住院取消失败的状态信息；

步骤73，若住院退费确认指令数据为确认退费，则向读卡器模块105发送第三读卡指令数据，并接收从读卡器模块105返回的第三用户数据；

这里，住院退费确认指令数据为确认退费时，住院取消处理单元102d会通过读卡器模块105获得用户的医保卡上的个人数据也就是第三用户数据，该数据至少包括用户姓名、年龄、身份证明标识信息、医保用户标识信息等内容；

步骤74，再通过医保信息获取接口104a向医保系统发送第三用户数据，并接收医保信息获取接口104a返回的第三用户医保数据；

这里，住院取消处理单元102d在获得了用户的个人数据之后，再通过医保接口模块104的医保信息获取接口104a从医保系统中查询到第三用户数据对应的当前用户的医保信息也就是第三用户医保数据，该数据至少包括当前用户的医保机构信息、医保类型信息以及与门诊、住院相关的登记信息；

步骤75，再对第三用户医保数据进行第三医保信息分析操作，并将分析结果向云his系统发送，并接收从云his系统发送的第一住院医保退费确认数据；

这里，住院取消处理单元102d在得到当前用户的第三用户医保数据之后要对其数据内容进行医保信息分析，主要是判断当前用户是否有医保、是否处于住院状态、是否有特殊病种备案(诸如大病备案、两病备案之类的)，若有医保且未处于住院状态则进一步判断对应医保机构的住院报销范围与额度，若有医保且处于住院状态则应进行当前用户已住院以及当前登记住院机构的信息提示，若有特殊病种备案则进一步判断具体的备案病种报销范围与额度；在完成医保分析之后，住院取消处理单元102d会将分析结果向云his系统回发，以便云his系统前端可以根据医保分析结果对步骤72时得到的自费退费内容和医保退费内容做进一步的校验调整，从而得到最终的医保退费数据也就是第一住院医保退费确认数据并发回给住院取消处理单元102d；

步骤76，再调用医保住院退费接口104m向医保系统发送第一住院医保退费确认数据，并接收医保门诊退费接口104f返回的住院医保退费状态数据；

这里，住院取消处理单元102d在获得第一住院医保退费确认数据之后，会通过医保接口模块104的医保住院退费接口104m将其发送至医保系统完成对应的退费流程，住院医保退费状态数据即为医保系统返回的处理状态；若该状态为退费成功则继续执行后续步骤，若为失败则住院取消处理单元102d会将失败状态反馈给云his系统，并通过调用云his系统提供的数据接口对当前用户的本次住院退费操作进行数据或流程回滚从而可以不对云his系统中对应的退费数据或流程造成破坏；

步骤77，若住院医保退费状态数据为退费成功，则将第一用户住院退费单据数据和第一住院医保退费确认数据组成的第一用户住院退费记录存入数据库103，并通过云his系统的云服务应用程序接口api修改云his系统的云端数据库中对应住院退费记录的数据状态。

这里，住院取消处理单元102d在医保系统上成功为当前用户完成住院取消操作之后，会将与本次住院取消相关的过程数据合并为一条完整的第一用户住院退费记录存入数据库103中对应的数据列表中，并在数据保存之后将云his系统端与当前用户本次住院取消操作相关的数据记录的状态修改为已退费状态。

三、数据库103

本发明实施例的数据库103包括多个数据列表，用以分别存储上述操作中的第一用户门诊收费记录、第一用户门诊退费记录、第一用户住院登记记录、第一用户住院登记取消记录、第一用户住院费用上传记录、第一用户住院费用上传取消记录、第一用户住院结算记录和第一用户住院退费记录，并通过用户的唯一识别码信息(诸如用户的身份证明标识数据、医保标识数据)和或记录的创建时间信息来建立所有数据记录之间的关联关系。

四、医保接口模块104

如图1所示，医保接口模块104与医保系统连接；医保接口模块104包括医保信息获取接口104a、医保门诊登记接口104b、医保门诊费用上传接口104c、医保门诊预结算接口104d、医保门诊结算接口104e、医保门诊退费接口104f、医保住院登记接口104g、医保住院登记取消接口104h、医保住院费用上传接口104i、医保住院费用上传取消接口104j、医保住院预结算接口104k、医保住院结算接口104l和医保住院退费接口104m；医保接口模块104用于处理门诊处理模块101与医保系统的数据传输，以及住院处理模块102与医保系统的数据传输。其中，各个接口数据传输的处理过程在上文中已给出说明，在此不再进行重复描述。

五、读卡器模块105

如图1所示，读卡器模块105还与用户医保卡连接；读卡器模块105用于处理门诊处理模块101读取用户医保卡的操作，以及住院处理模块102读取用户医保卡的操作。

本发明实施例提供的一种与基于云计算的医院信息系统对接的医保处理系统,采用标准指令或服务接口与云his系统间进行通讯，并将与门诊、住院相关的对接各地区医保系统的处理流程从原有的云端转移到本地，这样就可以彻底解决云端医保业务过度耦合、错误率高的问题。

专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。