一种基于云的实损医疗费保险金申请系统及方法

本发明涉及一种基于云的实损医疗费保险金申请系统及方法，特别是涉及一种基于云的实损医疗费保险金申请系统及方法，其为了可以在云计算环境下处理保险金申请，将包含医疗机构电子签名的电子数据交换(Electronic data interchange，EDI)数据传递至云服务器，将EDI数据传输至保险公司，以便不受时间和地点的约束即可方便地进行申请。

实损医疗保险是一种被保险人因疾病或伤害住院或门诊时保障作为医疗费实际所承担的费用的健康保险。一般情况下，被保险人为了申请保险金，需要到医院或药店取得诊疗费收据、诊断书、处方、处方药费收据等各种凭证后，通过传真传输或邮寄到保险公司。

如上所述，为了申请实损医疗费保险金，需要从医疗机构取得凭证，填写保险公司的申请表，并向该保险公司提出申请。而现实中由于申请手续繁琐，对于小额医疗费而言，多数被保险人即使可以根据保险合同收到保险金，也会由于手续复杂且不便而不申请保险金。

另外，医疗机构中存在着需要减少开具多种证明等简单及重复性工作，以及大量使用不必要的纸张而导致浪费的问题，保险公司中存在申请数据输入错误等问题，因此，需要简化实损医疗保险申请流程。

作为现有技术，有韩国公开专利第10-2016-0069684号(金融机构服务器和保险金自动申请方法)，但仅公开了通过拍摄医疗费结算单(statement)并分析图像来申请保险金的技术。

发明所要解决的问题

本发明为了解决上述现有技术的问题而提出，其目的在于提供一种将包含医疗机构电子签名的EDI数据传递至云服务器，且将EDI数据传输至保险公司，以能够方便地进行申请的系统及其方法。

本发明可以提供一种基于云的实损医疗费保险金申请系统及其方法，该方法可以为单独存在的医疗机构和保险公司的每个流程引入系统化的标准程序，通过标准化的API计算，与医疗机构服务器的DBMS和开发语言的类型无关地提取包含诊疗信息的EDI数据，使得在云计算环境下，可以有效地申请保险金。

本发明要解决的另一问题是通过移动终端简化流程。现有的处理方法中存在用户将凭证打印出来并提交给保险公司，保险公司也要对申请数据进行输入的步骤，而对于本发明的实施例而言，通过用户的移动终端将电子签名的原始数据以EDI形式及电子文件的形式传输至基于云的系统，而不经过现有的凭证打印步骤及输入步骤。

另外，对于发送到云端的实损保险申请数据而言，可以通过组建虚拟专用网络的方式，使用专用通信方法和JSON(JavaScript Object Notation，JS对象简谱)发送和接收数据来传输到个别保险公司。

本发明要解决的另一问题是准确地向保险公司申请医疗机构所发行的信息。通过电子签名的原始数据的认证、用户终端的认证和应用程序防止伪造和篡改技术，将个人(患者)的诊疗信息原封不动地转发给保险公司。

用于解决问题的方案

根据本发明实施例的一种基于云的实损医疗费保险金申请方法，包括：当用户的移动终端向云服务器请求申请实损医疗费保险金时，向医疗机构服务器请求申请实损医疗费保险金的步骤；上述医疗机构服务器提取EMR DB单元中存储的患者信息和诊疗信息，API构建器单元根据固有的API映射上述诊疗信息的步骤；上述医疗机构服务器通过医疗机构的电子签名对映射的诊疗信息进行认证，并对转换后的诊疗信息进行加密，以将包含诊疗信息的EDI数据发送给上述云服务器的步骤。

根据本发明实施例的一种基于云的实损医疗费保险金申请系统，包括：云服务器，当从用户终端接收到实损医疗费保险金申请请求时，向医疗机构服务器请求实损医疗保险金资料，当保险金申请数据系统从上述医疗机构服务器接收到包含诊疗信息的EDI数据时，生成诊疗费收据、诊断书、处方、处方药费收据、诊疗费明细中的至少一个，当用户终端确认保险金领取信息时，删除上述EDI数据；医疗机构服务器，当从上述云服务器接收到实损医疗费保险金申请请求时，从EMR DB单元提取患者信息和诊疗信息，API构建器单元利用固有的API映射诊疗信息，通过医疗机构的电子签名对映射的诊疗信息进行认证，并对上述诊疗信息进行加密，以将包含诊疗信息的EDI数据发送到上述云服务器；及保险公司服务器，当从上述云服务器接收到包含诊疗信息的EDI数据时，基于患者的合同计算保险金，并向上述云服务器请求诊疗明细，上述云服务器确认诊疗信息并对未申请的内容请求确认是否申请并接收回复，上述保险公司服务器确认账户信息，对未申请的内容请求确认个人信息。

发明效果

根据本发明，通过标准化的API，可以与医疗机构服务器的异构DBMS和开发语言的类型无关地，生成用于申请保险金的EDI数据。

另外，根据本发明，可以利用用户终端查询个人所加入的各保险公司的投保明细。

另外，根据本发明，可以利用用户终端不受时间和地点的约束，简便地申请实损医疗保险及查询实损医疗保险申请，用户便利性高。

另外，通过对实损医疗费保险金申请的数据输入实现电算化，效率性高。

图1是用于说明根据本发明实施例的一种基于云的实损医疗费保险金申请方法的流程图。

图2是根据本发明实施例的实损医疗费保险金申请系统的结构图。

图3和图4是用于说明根据本发明实施例的API构建器单元的操作方法的流程图。

图5是根据本发明实施例的API构建器单元的结构图。

图1是用于说明根据本发明实施例的一种基于云的实损医疗费保险金申请方法的流程图。

参考图1，基于云的实损医疗费保险金申请方法是，当云服务器100从用户终端400接收到实损医疗费保险金申请请求时，则向医疗机构服务器200请求实损医疗费保险金申请(S101)。

云服务构成虚拟化和分布式处理技术的计算环境，根据提供的资源可以分为基础设施即服务(Iaas)、平台即服务(Paas)和软件即服务(Saas)，本发明可以构成Paas，其提供用于开发和执行应用程序的环境。

通过移动虚拟键盘加密处理方法提供安全的数据输入环境，并通过提供全键盘(Qwerty键盘)、英文/数字/特殊字符专用键盘来提供移动安全策略。另外，可以使用通过适用安全套接字协议(Secure Sockets Layer，SSL)而加强通信区间安全和使用AES256等加密算法的应用程序内部数据安全技术。

通过移动服务的ID/PassWord策略对用户进行认证，基于信息的机密性和完整性，禁止存储终端设备中的重要信息，并且，通过应用程序的防止伪造和篡改技术实施终端设备安全策略。

医疗机构服务器200提取存储于电子病历数据库(Electronic Medical Record，EMR DB)单元210中的患者信息和诊疗信息(S103)，API构建器单元220根据应用程序编程接口(Application Programming Interface，API)映射上述诊疗信息(S103)。上述诊疗信息可以包括药价信息和处方信息。上述API是可以与异构数据库管理系统(DatabaseManagement System，DBMS)和开发语言的类型无关地，映射为标准化的诊疗信息的标准化API。API构建器单元220可以生成、管理及测试用于标准化医疗机构服务器内的数据库信息(例如，诊疗信息等)的API。API构建器单元220可以设置于医疗机构服务器内并在其内进行动作，但不限于此。API构建器单元220从EMR DB单元提取诊疗信息并生成数据源，编写结构化查询语言(Structured Query Language，SQL)查询，并反复进行测试以映射诊疗信息(S104)。

医疗机构服务器200通过医疗机构电子签名对映射的诊疗信息进行认证(S105)，并对上述映射的诊疗信息进行加密(S107)。医疗机构服务器200向云服务器100发送包含诊疗信息的EDI数据(S111)。上述EDI数据可以包含映射的诊疗信息和患者信息。

云服务器100基于上述EDI数据生成收据、诊断书、处方、处方药费收据、诊疗费明细中的至少一个(S113)。即，上述云服务器可以基于上述EDI数据，根据保险公司的专门结构，转换收据、诊断书、处方、处方药费收据、诊疗费明细中的至少一个。

此后，当用户终端400选择了保险公司时(S115)，云服务器100向保险公司服务器300查询是否与保险公司签订了合同(S117)。保险公司服务器300执行确认是否签订合同的认证，并将认证结果发送到云服务器100(S121)。

然后，云服务器100将包含诊疗信息的EDI数据传递给保险公司服务器300(S123)，保险公司服务器300基于上述EDI数据，依据患者的合同计算保险金(S125)。

保险公司服务器300向上述云服务器请求诊疗明细(S127)，上述云服务器确认诊疗信息，并请求确认对未申请的内容是否进行申请(S131)。

保险公司服务器300确认账户信息(S133)，针对未申请的内容向云服务器100请求确认个人信息。云服务器100确认账户信息(S137)，之后确认领取信息(S141)。另外，保险公司服务器确认保险金申请输入信息(S139)。然后，云服务器100删除已完成实损医疗费保险金申请的EDI数据。

另外，药店服务器由药品程序和Demon(幽灵)程序驱动，并与云服务器连接，当云服务器传递处方信息并请求配药时，药店服务器的Demon程序接收该请求并发送给药品程序，药品程序可以计算药价并传递给Demon程序。Demon程序可以将药价发送到云服务器请求结算，接收结算完成信息。

即，本发明通过云服务器传递包含诊疗信息的EDI数据，从而可以随时随地在线申请保险金，并且，在完成保险金申请时，云服务器上的保险申请数据将被删除，提高了安全性。

图2是根据本发明实施例的实损医疗费保险金申请系统的结构图。参考图2，实损医疗费保险金申请系统10包括云服务器100、医疗机构服务器200、保险公司服务器300和用户终端400。当用户终端400请求实损保险金时，云服务器100向医疗机构服务器200请求申请实损医疗费保险金，医疗机构服务器200利用标准化API对诊疗信息进行映射并加密，将包含诊疗信息的EDI数据提供给云服务器100。云服务器100将EDI数据传递给保险公司服务器300，进行保险金计算及申请。

云服务器100包括诊疗信息EDI发送/接收单元110、生成单元120、保险公司选择单元130、认证单元140、确认单元150、EDI数据存储单元160、控制单元170。

对于诊疗信息EDI发送/接收单元110而言，当用户终端400请求申请实损医疗费保险金时，可以向医疗机构服务器200请求申请实损医疗费保险金。并且，当从医疗机构服务器200接收到包含诊疗信息的EDI数据时，可以将其传递给保险公司服务器300。生成单元120可以基于接收到的EDI数据，生成收据、诊断书、处方、处方药费用收据和诊疗费明细中的至少一个(S113)。

当用户终端400选择了保险公司时，保险公司选择单元130可以向被选择的保险公司服务器请求查询保险公司合同。

当从保险公司服务器300接收到认证结果时，认证单元140可以进行用户认证。当从保险公司服务器300接收到诊疗明细或个人信息请求时，确认单元150可以确认诊疗信息及账户信息并传递给保险公司服务器300。

当EDI数据存储单元160从医疗机构服务器200接收到EDI数据时，暂存该数据，当从用户终端接收到保险金领取信息时，便可删除所存储的EDI数据。

控制单元170可以控制云服务器的各个组件。

医疗机构服务器200包括EMR DB单元210、API构建器单元220、医疗机构电子签名单元230、加密单元240、通信单元250和控制单元260。

EMR DB单元210可以存储有患者信息、诊疗信息、处方信息、院务信息及历史信息。EMB DB单元210中存储的信息类型不受限制。

API构建器单元220从EMR DB单元210提取患者信息和诊疗信息，并利用API映射处方信息和诊疗信息。即，API构建器单元生成数据源，且可以在通过SQL查询编写指南(guide)的简单编写及通过API构建器映射为标准数据后，通过反复验证来进行映射。由此，可以将异构DBMS之间的数据和以不同的开发语言开发的数据进行标准化。

医疗机构电子签名单元230通过医疗机构电子签名对转换后的诊疗信息进行认证。加密单元240可以通过对映射的诊疗信息进行加密来提高安全性，通信单元250可以与云服务器100发送/接收数据，控制单元260可以控制医疗机构服务器的各个组件。

保险公司服务器300包括认证单元310、保险金计算单元320、确认单元330、请求单元340、通信单元350及控制单元360。当认证单元310从云服务器100接收到查询保险公司是否签订合同的请求时，执行确认患者和保险公司之间是否签订合同的认证，并将认证结果发送给云服务器100。保险金计算单元320基于从云服务器接收的EDI数据，依据患者的合同计算保险金。

确认单元330可以确认账户信息或保险金申请输入信息。

请求单元340可以向云服务器请求患者的诊疗明细，云服务器100确认诊疗信息，并请求确认对未申请的内容是否进行申请。

通信单元350可以与云服务器100发送/接收数据，控制单元360可以控制保险公司服务器的各个组件。

图3和图4是用于说明根据本发明实施例的API构建器单元的动作方法的流程图。

参考图3和图4，API构建器单元构建应用服务器(S301)，开发API(S303)，请求分析超文本传输协议(HTTP)、LIVE框架(Liveframework)、查询类(Query Class)、程序(Procedure)中的至少一个(S305)。此时，应用服务器可以由IIS、Tomcat、Tuxedo、Entera等构建，但不限于此。上述API可以由.Net、ASP、Java、C语言实现。

之后，从EMR DB接收信息生成数据源(S307)，并开发业务逻辑(S309)。之后，调用SQL语句，收集查询结果，编写HTTP、Liveframework、Query Class、Procedure、表述性状态转移(REST)方式中的至少一个响应(S313)。通过测试，如符合标准则结束，不符合标准则重新返回业务逻辑开发步骤。

另外，在另一实施例中，API构建器单元设置有API工具(S401)，生成数据源(S403)。此后，编写SQL查询(S405)，并反复进行测试(S407)。

图5是根据本发明实施例的API构建器单元的结构图。

参考图5，API构建器单元220包括生成模块221、SQL编写模块222、测试模块223、分析模块224、收集模块225及控制模块226。生成模块221通过接收存储在EMR DB单元210内的患者信息、诊疗信息、处方信息、院务信息及历史信息中的患者信息和诊疗信息来生成数据源。SQL编写模块222可以编写SQL查询并将其传递给测试模块223进行测试。分析模块224可以分析HTTP请求。收集模块225可以收集查询结果并编写HTTP响应。控制模块226可以控制API构建器单元220的各个模块。认证模块227可以确认传输数据的真伪并对其进行加密。追踪模块228可以在传输后实时确认保险公司服务器的保险金申请状态。即，可以从EMR DB单元210接收数据，并由API构建器单元220将该数据转换成标准化的输出形式。

以上，参考附图中所示的实施例说明了本发明，但这仅是示例性的，本领域的普通技术人员应当理解，可由此进行各种变形以及实施等同的其他实施例。因此，本发明真正的技术上的保护范围应由权利要求书中的技术思想来确定。