CN111681006A - 一种医院信息化系统的支付安全保障方法 - Google Patents

一种医院信息化系统的支付安全保障方法 Download PDF

Info

Publication number
CN111681006A
CN111681006A CN202010451169.4A CN202010451169A CN111681006A CN 111681006 A CN111681006 A CN 111681006A CN 202010451169 A CN202010451169 A CN 202010451169A CN 111681006 A CN111681006 A CN 111681006A
Authority
CN
China
Prior art keywords
payment
hospital
risk
information system
level
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010451169.4A
Other languages
English (en)
Other versions
CN111681006B (zh
Inventor
方达通
陆翠芬
张立
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wuhan Medical Union Co ltd
Original Assignee
Wuhan Medical Union Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wuhan Medical Union Co ltd filed Critical Wuhan Medical Union Co ltd
Priority to CN202010451169.4A priority Critical patent/CN111681006B/zh
Publication of CN111681006A publication Critical patent/CN111681006A/zh
Application granted granted Critical
Publication of CN111681006B publication Critical patent/CN111681006B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

本发明提供一种医院信息化系统的支付安全保障方法，监控院内支付平台的运行状态，并监控院内支付平台与所述院外支付系统之间的联通状态，针对医院信息化系统不同的故障状况，定义医院信息化系统不同故障状况对应的支付风险级别，并制定不同支付风险级别对应的风险处理预案。当医院信息化系统发生故障时，进行相应的风险处理预案执行。本发明针对支付系统内部系统和服务监控，故障及时发现预警；二、根据故障类型和级别，提供备用方案，当故障发生时，预警通知管理人员并通知人工快速介入处理。目的在于分析影响医院支付运行的各个相关系统可能出现的风险，进行风险处理预案准备，以保障不同风险条件下，支付的安全与收费业务运行。

Description

一种医院信息化系统的支付安全保障方法
技术领域
本发明实施例涉及支付安全领域，尤其涉及一种医院信息化系统的支付安全保障方法。
背景技术
随着医疗信息化的飞速发展，全国各大医院基本上已经建设了适合本院流程的信息管理系统。医院管理系统已成为保障医院正常运行不可缺少的关键部分。医院管理系统基本涵盖了医院各个部门，包括门急诊挂号、病房管理、医生站护士站管理、库房管理、检验科室等，所以各科室对医院管理系统的依赖性也与日俱增。但信息化也是一把双刃剑，在给医院各科室带来快捷方便提高医疗效率的同时，也有它脆弱的一面。信息化系统不能正常运行将会导致整个医院陷于瘫痪。制订一套完整的应急方案，确保系统发生故障时可以迅速解决问题，已成为医院信息化建设的重中之重。
院外支付系统(含支付应用)是连接患者与院内服务的桥梁，医院支付中心的稳定与安全，也必将是医院信息化系统保障内容之一。
随着支付技术的发展，院外支付系统及支付服务灵活多变，院内支付服务的内涵不断拓展，这势必会增加医院支付管理的压力，支付系统亦将面临风险将更加严峻；而随着医院信息化水平不断提升，对支付系统的要求亦将更高。
在任何系统使用过程中，不可避免会遇到一些天灾人祸。确保患者能得到及时、有效地治疗，维持正常的医疗秩序，是医院在各应急预案，必须考虑的重要条件。造成医院信息化系统瘫痪，不能进行正常的流程性工作的因素，一般包括系统内在及外在因素，如雷击、病毒、黑客、长时间停电、机器故障或数据损坏等。医院一般会结合院内信息化系统情况，制定了信息系统应急预案，保障信息系统出现突发故障情况下，保证最短时间内恢复，避免出现长时间系统瘫痪。支付系统安全方案是在此基础上的补充，一般涉及的风险情况如下：
1)、院内支付平台故障：院内支付平台连接着院内业务系统以及院外支付系统/应用，当院内支付平台发生故障，则会造成接入院内支付平台的应用无法进行正常的支付流程，从而影响医院的业务运行。
2)、院内业务系统故障：医院的业务系统是医院各项业务运行的基石，当医院业务系统发生故障时，所有与院内业务系统进行交互的应用和系统均难正常运行。院内支付平台也不例外，支付系统与业务系统信息“断联”，业务系统亦无法判断患者的处方支付状态，就医秩序必将受到影响。
3)、院外支付系统/应用故障：院外系统，包括支付系统及支付应用，是医院开放服务呈现的窗口，也是连接医院服务的入口。医院外部系统/应用发生故障，一般不会影响到医院内部的系统运行，但会影响医院整体服务的效率与质量，影响患者服务的体验。院外支付系统/应用发生故障，则相应的院内支付平台无法正常使用相应的支付服务，甚至造成患者支付频繁故障，引发患者投诉。
因此，如何提供一种方法，在医院信息化系统发生故障时提供处理方案，以保障医院信息化系统的支付安全，成为亟待解决的问题。
发明内容
本发明实施例提供一种医院信息化系统的支付安全保障方法，用以解决医院信息化系统发生故障时，支付安全受到影响的问题。
本发明实施例提供一种医院信息化系统的支付安全保障方法，其中，所述医院信息化系统包括院内支付平台、院内业务系统、院外支付系统和集成平台，所述院内支付平台一端通过集成平台连接所述院内业务系统，另一端与所述院外支付系统连接，所述方法包括：
S1，监控院内支付平台的运行状态，并监控院内支付平台与所述院外支付系统之间的联通状态；
S2，当医院信息化系统发生故障时，根据当前的故障状况以及预设的故障风险分级策略，判断医院信息化系统当前的支付风险级别；
S3，根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理。
进一步，在所述步骤S1获取医院信息化系统当前的故障状况信息之前，所述方法还包括：
针对医院信息化系统不同的故障状况，设定故障风险分级策略；
所述设定故障风险分级策略具体包括：定义医院信息化系统不同故障状况对应的支付风险级别，并制定不同支付风险级别对应的风险处理预案。
进一步，所述定义医院信息化系统不同故障状况对应的支付风险级别具体包括：
当故障状况为院外支付系统故障时，定义此时医院信息化系统的支付风险级别为五级支付风险；
当院内支付平台发生故障时，定义此时医院信息化系统的支付风险级别为四级支付风险；
当集成平台或业务接口出现故障时，定义此时医院信息化系统的支付风险级别为三级支付风险；
当院内业务系统发生故障时，定义此时医院信息化系统的支付风险级别为二级支付风险；
当医院信息化系统瘫痪时，定义此时医院信息化系统的支付风险级别为一级支付风险。
进一步，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，包括：
S31，若医院信息化系统的支付风险级别为五级支付风险，此时院外支付系统发生故障，按照五级风险处理预案进行处理；五级风险处理预案的处理流程具体包括：
监控院内支付平台与所述院外支付系统之间的联通状态，发现故障后进行预警。
确定发生故障的院外支付系统并立即停用；
引导患者使用未发生故障的院外支付系统；
故障修复后，开启修复后的院外支付系统。
进一步，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，还包括：
S32，若医院信息化系统的支付风险级别为四级支付风险，此时院内支付平台发生故障，按照四级风险处理预案进行处理；四级风险处理预案的处理流程具体包括：
预先部署院内支付平台的备用系统；其中，院内支付平台的数据服务器在医院内网部署；
预先将院内支付平台的核心数据存储备份在备用系统中；
在院内支付平台发生故障时，预警通知管理人员，快速切至备用系统；
对发生故障的院内支付平台进行故障定位与修复，修复完成后转为备用系统。
进一步，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，还包括：
S33，若医院信息化系统的支付风险级别为三级支付风险，此时集成平台出现故障，按照三级风险处理预案进行处理；所述三级风险处理预案的处理流程具体包括：
预先部署院内支付平台与院内业务系统之间的两套对接方式，包括院内支付平台通过集成平台与院内业务系统对接的“间联模式”，以及院内支付平台直接与院内业务系统对接的“直联模式”；
当集成平台发生故障不能正常使用时，预警通知管理人员，将院内支付平台与院内业务系统的对接方式由“间联模式”切换为“直联模式”；
集成平台故障修复完成后，评估是否将对接方式还原为“间联模式”。
进一步，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，还包括：
S34，若医院信息化系统的支付风险级别为二级支付风险，此时院内业务系统发生故障，按照二级风险处理预案进行处理；所述二级风险处理预案的处理流程具体包括：
预警通知管理人员，将院内支付平台与客户端支付系统对接；
院内支付平台直接对接所述客户端支付系统进行收款业务；
除收款业务之外，其他业务均通过人工处理。
进一步，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，还包括：
S35，若医院信息化系统的支付风险级别为一级支付风险，此时医院信息化系统瘫痪，按照一级风险处理预案进行处理；所述一级风险处理预案的处理流程具体包括：
预警通知管理人员，启动云支付系统，采用智能pos终端收费；智能pos终端与微信支付网关和支付宝支付网关对接；
协调资源对医院信息化系统的故障进行全面排查与修复。
进一步，所述院内业务系统至少包括HIS、LIS和PACS。
进一步，所述院外支付系统至少包括银联、支付宝和微信。
本发明实施例提供的医院信息化系统的支付安全保障方法，针对医院信息化系统不同的故障状况，定义医院信息化系统不同故障状况对应的支付风险级别，并制定不同支付风险级别对应的风险处理预案。实时监控医院信息化系统当前的运行状态，当医院信息化系统发生故障时，判断医院信息化系统当前的支付风险级别，根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，从而在医院信息化系统发生故障时保障了系统的支付安全，同时也保障了医院收费业务的正常进行。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的医院信息化系统的支付安全保障方法流程图；
图2为本发明实施例提供的医院信息化系统的结构示意图；
图3为本发明实施例提供的五级支付风险的故障状况示例图；
图4为本发明实施例提供的三级支付风险的故障状况示例图；
图5为二级支付风险处理预案对应的客户端支付系统接入构架图；
图6为一级风险处理预案对应的云支付系统的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。
图1为本发明实施例提供的医院信息化系统的支付安全保障方法流程图，图2为本发明实施例提供的医院信息化系统的结构示意图，参照图1和图2,，本发明实施例提供的医院信息化系统包括院内支付平台、院内业务系统、院外支付系统和集成平台，所述院内支付平台一端通过集成平台连接所述院内业务系统，另一端与所述院外支付系统连接。院外支付系统是与院内支付平台对接的金融系统，院外支付系统至少包括“银联”、微信和支付宝。参照图2，院内支付平台还与院外支付应用对接，图2中的“医院自助机”、“微信公众号”、“支付宝生活号”和“医院APP”均是院外支付应用。本实施例中，院内是指医院内部，院外是指医院外部。院内业务系统包括HIS(Hospital Information System，医院信息系统)、LIS(Laboratory Information System，检验科信息系统)和PACS(Picture Archiving andCommunication Systems，影像归档和通信系统)。所述院外支付系统包括银联、支付宝和微信。
如图1所示，医院信息化系统的支付安全保障方法包括：
S1，监控医院信息化系统当前的运行状态；
S2，当医院信息化系统发生故障时，根据当前的故障状况以及预设的故障风险分级策略，判断医院信息化系统当前的支付风险级别；
S3，根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理。
具体地，在执行步骤S1之前，本发明提供的医院信息化系统的支付安全保障方法还包括：针对医院信息化系统不同的故障状况，设定故障风险分级策略。其中，设定故障风险分级策略具体包括：定义医院信息化系统不同故障状况对应的支付风险级别，并制定不同支付风险级别对应的风险处理预案。本发明实施例针对医院信息化系统不同的故障状况，将五类故障状况下的支付风险级别分为五级，并相应制定一级～五级的风险处理预案。
本实施例中，定义医院信息化系统不同故障状况对应的支付风险级别具体包括：
当故障状况为院外支付系统故障时，定义此时医院信息化系统的支付风险级别为五级支付风险；
当院内支付平台发生故障时，定义此时医院信息化系统的支付风险级别为四级支付风险；
当集成平台或业务接口出现故障时，定义此时医院信息化系统的支付风险级别为三级支付风险；此处，业务接口与院内支付平台和院外支付系统对接。
当院内业务系统发生故障时，定义此时医院信息化系统的支付风险级别为二级支付风险；
当医院信息化系统瘫痪时，定义此时医院信息化系统的支付风险级别为一级支付风险。
发生各级支付风险后，需要达到的支付安全保障目标如下：
五级支付风险：稍有危险，需要注意，不影响医院业务整体运行，基层人员可尽快处理。
四级支付风险：危险，需重点关注，不影响医院业务运行，但影响支付运行，可短时间恢复。
三级支付风险：中度风险，需控制整改；对业务系统有影响，启动预备方案，快速恢复。
二级支付风险：高度危险，重大风险，必须控制管理。业务系统出现严重故障，甚至崩溃，异常情况下支付后管理需求降级，保障支付服务提供，减缓医院应急状态的支付压力。
一级支付风险：巨大风险，极其危险，必须立即整改，所有系统通均无法正常使用，寻求一切手段保障收费基础能力提供，配合医院应急处理流程，确保业务流程能通行。
本发明实施例提供的医院信息化系统的支付安全保障方法，针对医院信息化系统不同的故障状况，定义医院信息化系统不同故障状况对应的支付风险级别，并制定不同支付风险级别对应的风险处理预案。实时监控医院信息化系统当前的运行状态，当医院信息化系统发生故障时，判断医院信息化系统当前的支付风险级别，根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，从而在医院信息化系统发生故障时保障了系统的支付安全，同时也保障了医院收费业务的正常进行。
在上述实施例的基础上，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，包括：
S31，若医院信息化系统的支付风险级别为五级支付风险，此时院外支付系统发生故障，按照五级风险处理预案进行处理。
当院内支付平台、院内业务系统和集成平台均运行稳定，但院外支付系统或院外支付应用发生故障时，例如某一支付通道故障导致交易频繁中断，支付失败；或某一院外支付应用故障，不能与平台进行交互，高频率的信息传输超时，应用不能使用。此时，患者使用某个院外支付系统或应用时，会出现支付失败，影响患者使用体验，长时间不处理，甚至可能引起患者投诉。
作为一种可选的实施实施方式，图3为本发明实施例提供的五级支付风险的故障状况示例图，图3中，“银联”、微信支付和支付宝支付均为院外支付系统。图3中的“医院自助机”、“微信公众号”、“支付宝生活号”和“医院APP”均是院外支付应用。图3中的HIS(Hospital Information System，医院信息系统)、LIS(Laboratory Information System，检验科信息系统)和PACS(Picture Archiving and Communication Systems，影像归档和通信系统)均是院内业务系统。参照图3，此时院外支付系统中的“银联”发生使用故障，导致用户通过院外支付应用“支付宝生活号”支付时出现支付失败的情况。此时按照五级风险处理预案进行处理。
具体地，此时采取的五级风险处理预案的处理流程包括：
监控发现院外支付系统发生故障后，预警通知系统管理员；
系统管理员停用发生故障的院外支付系统，并将故障上报相关部门进行故障修复；
故障修复后，系统管理员后台“启用”所述院外支付系统。
在上述各实施例的基础上，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，还包括：
S32，若医院信息化系统的支付风险级别为四级支付风险，此时院内支付平台发生故障，按照四级风险处理预案进行处理。
具体的，当支付风险级别为四级支付风险时，院内业务系统和院外支付系统运行稳定，但院内支付平台发生严重故障，导致接入的院外支付系统不能正常使用，影响到患者院外支付应用的使用。
此时采取的四级风险处理预案的处理流程具体包括：
预先部署院内支付平台的备用系统；其中，院内支付平台的数据服务器在医院内网部署，以保证数据服务器的安全。
预先将院内支付平台的核心数据存储备份在备用系统中，以防止数据丢失。
在院内支付平台发生故障时，预警通知管理人员，快速切至备用系统；
对发生故障的院内支付平台进行故障定位与修复，修复完成后转为备用系统。
在上述各实施例的基础上，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，还包括：
S33，若医院信息化系统的支付风险级别为三级支付风险，此时集成平台出现故障，按照三级风险处理预案进行处理。
具体的，当支付风险级别为三级支付风险时，院内支付平台及院外支付系统和院内业务系统均运行稳定，但集成平台出现故障，导致院内支付平台无法与院内业务系统进行正常的交互，造成院外支付系统有也无法正常使用。
作为一种可选的实施方式，图4为本发明实施例提供的三级支付风险的故障状况示例图，此时集成平台出现故障，致院内支付平台无法与院内业务系统进行正常的交互，对于此类故障状况，采取的三级风险处理预案进行处理。
具体地，此时采取的三级风险处理预案的处理流程包括：
预先部署院内支付平台与院内业务系统之间的两套对接方式，包括院内支付平台通过集成平台与院内业务系统对接的“间联模式”，以及院内支付平台直接与院内业务系统对接的“直联模式”；
当集成平台发生故障不能正常使用时，预警通知管理人员，将院内支付平台与院内业务系统的对接方式由“间联模式”切换为“直联模式”；
集成平台故障修复完成后，评估是否将对接方式还原为“间联模式”。
在上述实施例的基础上，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，还包括：
S34，若医院信息化系统的支付风险级别为二级支付风险，此时院内业务系统发生故障，按照二级风险处理预案进行处理。
具体地，当支付风险级别为二级支付风险时，院内业务系统运行出现问题，短时间内无法修复，医院已经无法按照标准流程运转，造成院内业务系统的相关业务无法正常进行。
此时采取的二级风险处理预案的处理流程具体包括：
预警通知管理人员，将院内支付平台与客户端支付系统对接；此时，院内支付平台不与院内业务系统交互，独立完成收费闭环，并且关闭退费以及与院内业务系统相关功能。
院内支付平台直接对接所述客户端支付系统进行收款业务；
除收款业务之外，其他业务均通过人工处理。
在上述各实施例的基础上，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，还包括：
S35，若医院信息化系统的支付风险级别为一级支付风险，此时医院信息化系统瘫痪，按照一级风险处理预案进行处理；所述一级风险处理预案的处理流程具体包括：
预警通知管理人员，启动云支付系统，采用智能pos终端收费；智能pos终端与微信支付网关和支付宝支付网关对接；
协调资源对医院信息化系统的故障进行全面排查与修复。
图6为一级风险处理预案对应的云支付系统的结构示意图；本实施例中，在医院信息化系统瘫痪时，启动云支付系统，采用智能pos终端收费，智能pos终端可以与微信支付网关和支付宝支付网关快速对接。缓解医院人工现金收费的压力。
当前，医院信息化系统建设情况不一，本发明实施例提供的医院信息化系统的支付安全保障方法，是基于医院信息化保障基础上的补充，目的是保障医院在各种极端情况下的支付机制运行，保障医院支付系统稳定运行，增强风险防控水平。
本发明实施例提供的医院信息化系统的支付安全保障方法，针对医院信息化系统不同的故障状况，定义医院信息化系统不同故障状况对应的支付风险级别，并制定不同支付风险级别对应的风险处理预案。实时监控医院信息化系统当前的运行状态，当医院信息化系统发生故障时，判断医院信息化系统当前的支付风险级别，根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，从而在医院信息化系统发生故障时保障了系统的支付安全，同时也保障了医院收费业务的正常进行。
以上所描述的系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种医院信息化系统的支付安全保障方法，其中，所述医院信息化系统包括院内支付平台、院内业务系统、院外支付系统和集成平台，所述院内支付平台一端通过集成平台连接所述院内业务系统，另一端与所述院外支付系统连接，其特征在于，所述方法包括：
S1，监控院内支付平台的运行状态，并监控院内支付平台与所述院外支付系统之间的联通状态；
S2，当医院信息化系统发生故障时，根据当前的故障状况以及预设的故障风险分级策略，判断医院信息化系统当前的支付风险级别；
S3，根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理。
2.根据权利要求1所述的医院信息化系统的支付安全保障方法，其特征在于，在所述步骤S1获取医院信息化系统当前的故障状况信息之前，所述方法还包括：
针对医院信息化系统不同的故障状况，设定故障风险分级策略；
所述设定故障风险分级策略具体包括：定义医院信息化系统不同故障状况对应的支付风险级别，并制定不同支付风险级别对应的风险处理预案。
3.根据权利要求2所述的医院信息化系统的支付安全保障方法，其特征在于，所述定义医院信息化系统不同故障状况对应的支付风险级别具体包括：
当故障状况为院外支付系统故障时，定义此时医院信息化系统的支付风险级别为五级支付风险；
当院内支付平台发生故障时，定义此时医院信息化系统的支付风险级别为四级支付风险；
当集成平台或业务接口出现故障时，定义此时医院信息化系统的支付风险级别为三级支付风险；
当院内业务系统发生故障时，定义此时医院信息化系统的支付风险级别为二级支付风险；
当医院信息化系统瘫痪时，定义此时医院信息化系统的支付风险级别为一级支付风险。
4.根据权利要求3所述的医院信息化系统的支付安全保障方法，其特征在于，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，包括：
S31，若医院信息化系统的支付风险级别为五级支付风险，此时院外支付系统发生故障，按照五级风险处理预案进行处理；五级风险处理预案的处理流程具体包括：
监控院内支付平台与所述院外支付系统之间的联通状态，发现故障后进行预警。
确定发生故障的院外支付系统并立即停用；
引导患者使用未发生故障的院外支付系统；
故障修复后，开启修复后的院外支付系统。
5.根据权利要求3所述的医院信息化系统的支付安全保障方法，其特征在于，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，还包括：
S32，若医院信息化系统的支付风险级别为四级支付风险，此时院内支付平台发生故障，按照四级风险处理预案进行处理；四级风险处理预案的处理流程具体包括：
预先部署院内支付平台的备用系统；其中，院内支付平台的数据服务器在医院内网部署；
预先将院内支付平台的核心数据存储备份在备用系统中；
在院内支付平台发生故障时，预警通知管理人员，快速切至备用系统；
对发生故障的院内支付平台进行故障定位与修复，修复完成后转为备用系统。
6.根据权利要求3所述的医院信息化系统的支付安全保障方法，其特征在于，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，还包括：
S33，若医院信息化系统的支付风险级别为三级支付风险，此时集成平台出现故障，按照三级风险处理预案进行处理；所述三级风险处理预案的处理流程具体包括：
预先部署院内支付平台与院内业务系统之间的两套对接方式，包括院内支付平台通过集成平台与院内业务系统对接的“间联模式”，以及院内支付平台直接与院内业务系统对接的“直联模式”；
当集成平台发生故障不能正常使用时，预警通知管理人员，将院内支付平台与院内业务系统的对接方式由“间联模式”切换为“直联模式”；
集成平台故障修复完成后，评估是否将对接方式还原为“间联模式”。
7.根据权利要求3所述的医院信息化系统的支付安全保障方法，其特征在于，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，还包括：
S34，若医院信息化系统的支付风险级别为二级支付风险，此时院内业务系统发生故障，按照二级风险处理预案进行处理；所述二级风险处理预案的处理流程具体包括：
预警通知管理人员，将院内支付平台与客户端支付系统对接；
院内支付平台直接对接所述客户端支付系统进行收款业务；
除收款业务之外，其他业务均通过人工处理。
8.根据权利要求3所述的医院信息化系统的支付安全保障方法，其特征在于，步骤S3中，所述根据医院信息化系统的支付风险级别，按照对应的风险处理预案进行处理，还包括：
S35，若医院信息化系统的支付风险级别为一级支付风险，此时医院信息化系统瘫痪，按照一级风险处理预案进行处理；所述一级风险处理预案的处理流程具体包括：
预警通知管理人员，启动云支付系统，采用智能pos终端收费；智能pos终端与微信支付网关和支付宝支付网关对接；
协调资源对医院信息化系统的故障进行全面排查与修复。
9.根据权利要求1所述的医院信息化系统的支付安全保障方法，其特征在于，所述院内业务系统至少包括HIS、LIS和PACS。
10.根据权利要求1所述的医院信息化系统的支付安全保障方法，其特征在于，所述院外支付系统至少包括银联、支付宝和微信。
CN202010451169.4A 2020-05-25 2020-05-25 一种医院信息化系统的支付安全保障方法 Active CN111681006B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010451169.4A CN111681006B (zh) 2020-05-25 2020-05-25 一种医院信息化系统的支付安全保障方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010451169.4A CN111681006B (zh) 2020-05-25 2020-05-25 一种医院信息化系统的支付安全保障方法

Publications (2)

Publication Number Publication Date
CN111681006A true CN111681006A (zh) 2020-09-18
CN111681006B CN111681006B (zh) 2023-07-25

Family

ID=72453608

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010451169.4A Active CN111681006B (zh) 2020-05-25 2020-05-25 一种医院信息化系统的支付安全保障方法

Country Status (1)

Country Link
CN (1) CN111681006B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112837053A (zh) * 2021-01-29 2021-05-25 支付宝(杭州)信息技术有限公司 支付处理方法及装置

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101211437A (zh) * 2006-12-31 2008-07-02 阿里巴巴公司 一种电子支付故障检测方法、装置和电子支付系统
JP2009087324A (ja) * 2007-09-13 2009-04-23 Ricoh Co Ltd 機器情報管理装置、機器方法管理方法、および機器情報管理プログラム
CN101556679A (zh) * 2009-05-21 2009-10-14 中国建设银行股份有限公司 一种综合前端系统故障处理方法及计算机设备
US20100211483A1 (en) * 2009-02-13 2010-08-19 Bank Of America Corporation Systems, methods and computer program products for managing payment processes in a comprehensive payment hub system
US20100324945A1 (en) * 2009-05-12 2010-12-23 Ronald Paul Hessing Data insurance system based on dynamic risk management
US20120239531A1 (en) * 2009-09-15 2012-09-20 Netsecure Innovations Inc Facilitating e-commerce payments using non-accepted customer payment methods
JP2013250704A (ja) * 2012-05-31 2013-12-12 Fujitsu Frontech Ltd 障害対応システム、自動取引装置、障害対応方法、および、障害対応プログラム
CN103473710A (zh) * 2013-08-20 2013-12-25 国家电网公司 一种集中运维系统的故障分级处理方法
CN106874136A (zh) * 2017-02-22 2017-06-20 郑州云海信息技术有限公司 一种存储系统的故障处理方法及装置
CN107844880A (zh) * 2017-07-17 2018-03-27 中国南方电网有限责任公司 一种基于多源数据融合的电网故障等级自动识别方法
WO2019225815A1 (ko) * 2018-05-23 2019-11-28 (주)누벤트 결제 단말 모니터링 시스템 및 결제 단말 모니터링 방법
CN111126985A (zh) * 2019-12-31 2020-05-08 武汉默联股份有限公司 一种医疗场景下的综合支付管理系统

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101211437A (zh) * 2006-12-31 2008-07-02 阿里巴巴公司 一种电子支付故障检测方法、装置和电子支付系统
JP2009087324A (ja) * 2007-09-13 2009-04-23 Ricoh Co Ltd 機器情報管理装置、機器方法管理方法、および機器情報管理プログラム
US20100211483A1 (en) * 2009-02-13 2010-08-19 Bank Of America Corporation Systems, methods and computer program products for managing payment processes in a comprehensive payment hub system
US20100324945A1 (en) * 2009-05-12 2010-12-23 Ronald Paul Hessing Data insurance system based on dynamic risk management
CN101556679A (zh) * 2009-05-21 2009-10-14 中国建设银行股份有限公司 一种综合前端系统故障处理方法及计算机设备
US20120239531A1 (en) * 2009-09-15 2012-09-20 Netsecure Innovations Inc Facilitating e-commerce payments using non-accepted customer payment methods
JP2013250704A (ja) * 2012-05-31 2013-12-12 Fujitsu Frontech Ltd 障害対応システム、自動取引装置、障害対応方法、および、障害対応プログラム
CN103473710A (zh) * 2013-08-20 2013-12-25 国家电网公司 一种集中运维系统的故障分级处理方法
CN106874136A (zh) * 2017-02-22 2017-06-20 郑州云海信息技术有限公司 一种存储系统的故障处理方法及装置
CN107844880A (zh) * 2017-07-17 2018-03-27 中国南方电网有限责任公司 一种基于多源数据融合的电网故障等级自动识别方法
WO2019225815A1 (ko) * 2018-05-23 2019-11-28 (주)누벤트 결제 단말 모니터링 시스템 및 결제 단말 모니터링 방법
CN111126985A (zh) * 2019-12-31 2020-05-08 武汉默联股份有限公司 一种医疗场景下的综合支付管理系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
黄卫忠: "医院信息化系统管理瘫痪应急预案的措施", 计算机产品与流通, vol. 10, pages 273 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112837053A (zh) * 2021-01-29 2021-05-25 支付宝(杭州)信息技术有限公司 支付处理方法及装置
CN112837053B (zh) * 2021-01-29 2022-08-09 支付宝(杭州)信息技术有限公司 支付处理方法及装置

Also Published As

Publication number Publication date
CN111681006B (zh) 2023-07-25

Similar Documents

Publication Publication Date Title
CN102998577B (zh) 检测和定位电网中的异常状况和电力故障的系统和方法
CN104104547B (zh) 一种网络设备配置文件的管理方法及网络控制器
CN102682361A (zh) 电梯维保管理系统及方法
CN209248549U (zh) 变电站工作票的智能审查装置和系统
CN111681006A (zh) 一种医院信息化系统的支付安全保障方法
CN101888284B (zh) 一种用于数据单向传输的方法及其装置
CN105812161B (zh) 一种控制器故障备份方法和系统
CN113760634A (zh) 一种数据处理方法和装置
US20040102178A1 (en) Emergency backup communications system
CN111224819A (zh) 分布式消息系统
CN117994944A (zh) 一种基于医疗设备巡检的智能监控与报警装置及方法
CN101242253A (zh) 软件故障应急处理方法及系统
CN106844078A (zh) 一种pcie故障的处理方法和装置
CN104754562A (zh) 数据复制异常的修复方法及装置
Petersen et al. Designing resilient critical infrastructure systems using risk and vulnerability analysis
CN104363111B (zh) 一种第三方系统接入的控制方法及设备
Pingel et al. World marrow donor association crisis response, business continuity, and disaster recovery guidelines
CN108153621A (zh) 一种云灾备应急切换管理系统
CN112884447A (zh) 一种民航机场数据协同方法及系统
Brotherton et al. Data center business continuity best practice
Lin et al. An analysis of using state of the art technologies to implement real-time continuous assurance
CN112634038A (zh) 银行交易平台的交易状态控制方法及装置
CN118118322A (zh) 远程视频银行对客服务中断问题解决方案
CN111192062A (zh) 一种it服务自助购买系统
CN112015590A (zh) 一种多层级灾备方法、装置及电子设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant