CN110517761A - 医疗卡的关联方法、装置、设备和存储介质 - Google Patents
医疗卡的关联方法、装置、设备和存储介质 Download PDFInfo
- Publication number
- CN110517761A CN110517761A CN201910812288.5A CN201910812288A CN110517761A CN 110517761 A CN110517761 A CN 110517761A CN 201910812288 A CN201910812288 A CN 201910812288A CN 110517761 A CN110517761 A CN 110517761A
- Authority
- CN
- China
- Prior art keywords
- medical card
- institute
- medical
- card
- target
- 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
Links
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
Landscapes
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Health & Medical Sciences (AREA)
- Engineering & Computer Science (AREA)
- Biomedical Technology (AREA)
- Epidemiology (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Primary Health Care (AREA)
- Public Health (AREA)
- Medical Treatment And Welfare Office Work (AREA)
Abstract
本申请提供了医疗卡的关联方法、装置、设备和存储介质。所述方法包括：显示第一医院帐号的医疗卡管理界面；获取在第一医院帐号的医疗卡管理界面中输入的医疗卡关联指令；根据医疗卡关联指令，显示医疗卡跨院服务平台的医疗卡授权关联界面；获取在医疗卡授权关联界面中输入的对应于目标跨院医疗卡的授权关联指令；显示第一医院帐号的医疗卡管理界面，在第一医院帐号的医疗卡管理界面中显示目标跨院医疗卡。本申请实施例提供的技术方案，用户在不同医院就诊时，直接进行跨院医疗卡关联，不需要重复输入手机号、姓名、年龄、身份证号、家庭住址等个人基本信息进行注册，操作简洁高效。
Description
技术领域
本申请实施例涉及计算机和互联网技术领域，特别涉及一种医疗卡的关联方法、装置、设备和存储介质。
背景技术
随着互联网技术的发展，互联网技术与医疗的结合能够为用户的就诊提供更加便捷的方式，如网上预约挂号、网上就诊缴费、网上预约取药等。
在相关技术中，每个医院都拥有独立的一套用户注册-登录系统，用户输入手机号、姓名、年龄、身份证号、家庭住址等个人基本信息，以在该医院的系统中进行帐号注册，然后通过该帐号关联医院的医疗卡。用户到不同医院就诊需要办理多张医疗卡，如：用户在A医院就诊需办理A医院的医疗卡，到B医院就诊时要办理B医院的医疗卡。
在上述相关技术中，用户到不同的医院就诊，需要重复进行帐号注册办理医疗卡，而每一次注册都需要输入手机号、姓名、年龄、身份证号、家庭住址等个人基本信息，操作复杂低效。
发明内容
本申请实施例提供了一种医疗卡的关联方法、装置、设备和存储介质，可用于解决相关技术中，由于每一次注册都需要输入手机号、姓名、年龄、身份证号、家庭住址等个人基本信息，导致操作复杂低效的问题。所述技术方案如下：
一方面，本申请实施例提供了一种医疗卡的关联方法，所述方法包括：
显示第一医院帐号的医疗卡管理界面；
获取在所述第一医院帐号的医疗卡管理界面中输入的医疗卡关联指令；
根据所述医疗卡关联指令，显示医疗卡跨院服务平台的医疗卡授权关联界面；
获取在所述医疗卡授权关联界面中输入的对应于目标跨院医疗卡的授权关联指令，所述医疗卡授权关联界面中包括已申请创建的至少一个跨院医疗卡；
显示所述第一医院帐号的医疗卡管理界面，在所述第一医院帐号的医疗卡管理界面中显示所述目标跨院医疗卡，所述目标跨院医疗卡用于在所述第一医院帐号对应的第一医院就诊时使用。
另一方面，本申请实施例提供了一种医疗卡的关联方法，所述方法包括：
接收客户端发送的医疗卡关联请求，所述医疗卡关联请求用于请求将第一医院帐号与在医疗卡跨院服务平台中已申请创建的跨院医疗卡进行关联；
根据所述医疗卡关联请求，向所述医疗卡跨院服务平台发送医疗卡授权请求，所述医疗卡授权请求中包括所述客户端中登录的目标用户帐号，所述医疗卡授权请求用于请求获取经所述目标用户帐号授权的、与所述第一医院帐号相关联的目标跨院医疗卡；
接收所述医疗卡跨院服务平台发送的所述目标跨院医疗卡的相关信息；
向所述客户端发送医疗卡关联响应，所述医疗卡关联响应用于指示已成功将所述第一医院帐号与所述目标跨院医疗卡进行关联。
又一方面，本申请实施例提供了一种医疗卡的关联方法，所述方法包括：
接收第一医院帐号对应的服务器发送的医疗卡授权请求，所述医疗卡授权请求中包括客户端中登录的目标用户帐号，所述医疗卡授权请求用于请求获取经所述目标用户帐号授权的、与所述第一医院帐号相关联的目标跨院医疗卡；
向所述客户端发送医疗卡授权指示，所述医疗卡授权指示中包括所述目标用户帐号在医疗卡跨院服务平台中已申请创建的至少一个跨院医疗卡；
接收所述客户端发送的对应于所述目标跨院医疗卡的授权确认指示；
向所述第一医院帐号对应的服务器发送所述目标跨院医疗卡的相关信息，所述目标跨院医疗卡用于在所述第一医院帐号对应的第一医院就诊时使用。
还一方面，本申请实施例提供了一种医疗卡的关联装置，所述装置包括：
管理界面显示模块，用于显示第一医院帐号的医疗卡管理界面；
关联指令获取模块，用于获取在所述第一医院帐号的医疗卡管理界面中输入的医疗卡关联指令；
关联界面显示模块，用于根据所述医疗卡关联指令，显示医疗卡跨院服务平台的医疗卡授权关联界面；
授权指令获取模块，用于获取在所述医疗卡授权关联界面中输入的对应于目标跨院医疗卡的授权关联指令，所述医疗卡授权关联界面中包括已申请创建的至少一个跨院医疗卡；
所述管理界面显示模块，用于显示所述第一医院帐号的医疗卡管理界面，在所述第一医院帐号的医疗卡管理界面中显示所述目标跨院医疗卡，所述目标跨院医疗卡用于在所述第一医院帐号对应的第一医院就诊时使用。
还一方面，本申请实施例提供了一种医疗卡的关联装置，所述装置包括：
关联请求接收模块，用于接收客户端发送的医疗卡关联请求，所述医疗卡关联请求用于请求将第一医院帐号与在医疗卡跨院服务平台中已申请创建的跨院医疗卡进行关联；
授权请求发送模块，用于根据所述医疗卡关联请求，向所述医疗卡跨院服务平台发送医疗卡授权请求，所述医疗卡授权请求中包括所述客户端中登录的目标用户帐号，所述医疗卡授权请求用于请求获取经所述目标用户帐号授权的、与所述第一医院帐号相关联的目标跨院医疗卡；
相关信息接收模块，用于接收所述医疗卡跨院服务平台发送的所述目标跨院医疗卡的相关信息；
关联响应发送模块，用于向所述客户端发送医疗卡关联响应，所述医疗卡关联响应用于指示已成功将所述第一医院帐号与所述目标跨院医疗卡进行关联。
还一方面，本申请实施例提供了一种医疗卡的关联装置，所述装置包括：
授权请求接收模块，用于接收第一医院帐号对应的服务器发送的医疗卡授权请求，所述医疗卡授权请求中包括客户端中登录的目标用户帐号，所述医疗卡授权请求用于请求获取经所述目标用户帐号授权的、与所述第一医院帐号相关联的目标跨院医疗卡；
授权指示发送模块，用于向所述客户端发送医疗卡授权指示，所述医疗卡授权指示中包括所述目标用户帐号在医疗卡跨院服务平台中已申请创建的至少一个跨院医疗卡；
确认指示接收模块，用于接收所述客户端发送的对应于所述目标跨院医疗卡的授权确认指示；
相关信息发送模块，用于向所述第一医院帐号对应的服务器发送所述目标跨院医疗卡的相关信息，所述目标跨院医疗卡用于在所述第一医院帐号对应的第一医院就诊时使用。
再一方面，本申请实施例提供了一种计算机设备，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上述方面所述的医疗卡的关联方法。
再一方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如上述方面所述的医疗卡的关联方法。
还一方面，本申请实施例提供了一种计算机程序产品，所述计算机程序产品被处理器执行时，用于实现上述方面所述的医疗卡的关联方法。
本申请实施例提供的技术方案可以包括如下有益效果：
通过在第一医院的医疗卡管理界面中进行跨院医疗卡关联授权，将第一医院帐号与已申请创建的目标跨院医疗卡进行关联，以使得用户可以在第一医院帐号对应的第一医院就诊时直接使用该目标跨院医疗卡。相比于相关技术中，用户到不同的医院就诊，需要重复输入个人信息进行帐号注册办理医疗卡，操作繁琐，本申请实施例提供的技术方案，用户在不同医院就诊时，直接进行跨院医疗卡关联，不需要重复输入手机号、姓名、年龄、身份证号、家庭住址等个人基本信息进行注册，操作简洁高效。
附图说明
图1是本申请一个实施例提供的实施环境的示意图；
图2是本申请一个实施例提供的医疗卡的关联方法的流程图；
图3示例性示出了本申请中一种医疗卡管理界面的示意图；
图4示例性示出了本申请中另一种医疗卡管理界面的示意图；
图5是本申请另一个实施例提供的医疗卡的关联方法的流程图；
图6示例性示出了本申请中一种医疗卡创建界面的示意图；
图7示例性示出了本申请中一种医疗卡授权关联界面的示意图；
图8示例性示出了本申请中一种医疗卡列表的示意图；
图9示例性示出了本申请中一种详情界面的示意图；
图10示例性示出了本申请中另一种详情界面的示意图；
图11示例性示出了本申请中一种卡券管理界面的示意图；
图12是本申请另一个实施例提供的医疗卡的关联方法的流程图；
图13是本申请又一个实施例提供的医疗卡的关联方法的流程图；
图14示例性示出了本申请中一种跨院医疗卡关联的流程示意图；
图15是本申请一个实施例提供的医疗卡的关联装置的框图；
图16是本申请另一个实施例提供的医疗卡的关联装置的框图；
图17是本申请又一个实施例提供的医疗卡的关联装置的框图；
图18是本申请又一个实施例提供的医疗卡的关联装置的框图；
图19是本申请又一个实施例提供的医疗卡的关联装置的框图；
图20是本申请又一个实施例提供的医疗卡的关联装置的框图；
图21是本申请一个实施例提供的终端的结构框图；
图22是本申请一个实施例提供的服务器的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
请参考图1，其示出了本申请一个实施例提供的实施环境的示意图。该实施环境可以包括：终端10、医院服务器20和医疗卡跨院服务平台30。
终端10中安装运行有客户端，该客户端可以是即时通信应用的客户端。该客户端中登录有普通用户的用户帐号。
医院服务器20是指医院帐号对应的服务器，用于为医院帐号提供后台服务。医院服务器20可以有多个，每个医院具有各自的医院服务器。医院帐号是指医院在公众平台上申请的用户帐号，通常医院帐号也可以称为公众号。其中，公众平台是指用于与用户帐号的关注者进行线上线下互动的开放平台。公众平台通常基于即时通信类应用或者社交类应用实现。用户账号运营者在应用中申请用户帐号后，应用中的普通用户便可关注该用户帐号，或者与该用户帐号成为好友关系。之后，普通用户和用户帐号对应的用户可以以应用为媒介，进行文本、图片、语音、视频等信息交互。公众号是指机构(如医院)或个人在公众平台上申请的帐号。该公众号能够为用户提供一些服务。如医院公众号，能够为用户提供线上获取就诊服务，如线上挂号、线上缴费、线上等；也可以是线下获取就诊服务，如线下挂号、线下缴费、线下取药等等。
医疗卡跨院平台30用于创建跨院医疗卡，该跨院医疗卡可以在不用的医院就诊时使用。每个跨院医疗卡对应于一个就诊人，每个用户帐号可以对应于至少一个跨院医疗卡。例如，该用户帐号对应的跨院医疗卡可以包括该用户帐号对应的用户的跨院医疗卡，还可以包括与用户帐号对应的用户相关的其它用户的跨院医疗卡。例如，用户帐号对应的用户为小王，该用户帐号对应的跨院医疗卡可以包括小王的跨院医疗卡，也可以包括小王儿子的跨院医疗卡，还可以包括小王老婆的跨院医疗卡。
上述医院服务器20和医疗卡跨院平台30可以为相同的服务器，也可以为不同的服务器。
终端10可以是诸如手机、平板电脑、可穿戴设备、PC(Personal Computer，个人计算机)等电子设备。服务器(如医院服务器20和医疗卡跨院平台30)可以是一台服务器，也可以是由多台服务器组成的服务器集群，或者是一个云计算服务中心。终端10、医院服务器20和医疗卡跨院平台30可以通过有线或者无线网络进行通信。
下面，通过几个实施例对本申请技术方案进行介绍说明。
请参考图2，其示出了本申请一个实施例提供的医疗卡的关联方法的流程图。在本实施例中，主要以该方法应用于图1所示实施环境的终端中安装运行的客户端中来举例说明。该方法可以包括如下几个步骤：
步骤201，显示第一医院帐号的医疗卡管理界面。
终端中安装运行有客户端，该客户端可以是即时通信应用的客户端，如×信客户端；也可以是社交应用的客户端，还可以是医院专属客户端。用户可以运行该客户端，然后从该客户端中进入第一医院帐号的医疗卡管理界面。
上述第一医院帐号的医疗卡管理界面是用于管理第一医院帐号下的医疗卡的界面。用户可以在该医疗卡管理界面中对医疗卡进行管理，如添加医疗卡、关联医疗卡等。该医疗卡管理界面中包括医疗卡添加控件和医疗卡关联控件。其中，医疗卡添加控件是用于添加医疗卡的操作控件；医疗卡关联控件是用于关联医疗卡的操作控件。在本申请实施例中，对医疗卡添加控件和医疗卡关联控件在医疗卡管理界面中显示位置以及显示形式不作限定。
示例性地，如图3所示，其示例性示出了一种医疗卡管理界面的示意图。在该医疗卡管理界面30中显示有医疗卡添加控件31，如“添加健康卡”，还显示有医疗卡关联控件32，如“已有健康卡，一键快速关联”。
可选地，在上述显示第一医院帐号的医疗卡管理界面之前，还包括：显示第一医院帐号的用户界面。该第一医院帐号的用户界面中包括进入医疗卡管理界面的控件。
在本申请实施例中，用户帐号(如上文介绍的第一医院帐号)是用于唯一标识用户(如医院)的标识符，用户帐号通常是由数字、字母、符号或者其组合所形成的字符串。不同用户(如医院)具有不同的用户帐号(如医院帐号)。
步骤202，获取在第一医院帐号的医疗卡管理界面中输入的医疗卡关联指令。
用户可以点击上述医疗卡管理界面中医疗卡关联控件，以获取医疗卡关联指令。上述医疗卡关联指令用于指示将第一医院帐号与在医疗卡跨院服务平台中已申请创建的跨院医疗卡进行关联。
步骤203，根据医疗卡关联指令，显示医疗卡跨院服务平台的医疗卡授权关联界面。
在获取到上述医疗卡关联指令后，可以显示医疗卡跨院服务平台的医疗卡授权关联界面。该医疗卡授权关联界面是用于授权将第一医院帐号与跨院医疗卡进行关联的界面。
步骤204，获取在医疗卡授权关联界面中输入的对应于目标跨院医疗卡的授权关联指令。
上述医疗卡授权关联界面中包括已申请创建的至少一个跨院医疗卡。上述已申请创建的至少一个跨院医疗卡，是指在医疗卡跨院服务平台中已申请创建的至少一个跨院医疗卡。上述跨院医疗卡是指支持在多个不同医院使用的医疗卡。
在显示上述医疗卡授权关联界面后，可以获取在该医疗卡授权关联界面中输入的对应于目标跨院医疗卡的授权关联指令。其中，该目标跨院医疗卡可以是已申请创建的至少一个跨院医疗卡中的任一跨院医疗卡。
步骤205，显示第一医院帐号的医疗卡管理界面，在第一医院帐号的医疗卡管理界面中显示目标跨院医疗卡，上述目标跨院医疗卡用于在第一医院帐号对应的第一医院就诊时使用。
在获取到上述对应于目标跨院医疗卡的授权关联指令后，跳转显示第一医院帐号的医疗卡管理界面，该第一医院帐号的医疗卡管理界面中可以显示有目标跨院医疗卡，也就是说，第一医院帐号与目标跨院医疗卡已关联成功。此时，目标跨院医疗卡可以在第一医院帐号对应的第一医院就诊时使用。第一医院帐号与目标跨院医疗卡关联成功，表示第一医院帐号对应的服务器中已经记录有该目标跨院医疗卡的相关信息，如该目标跨院医疗卡对应的就诊人的信息、该目标跨院医疗卡的标识。当目标跨院医疗卡对应的就诊人在第一医院帐号对应的第一医院就诊时，可以直接使用该目标跨院医疗卡的标识来标识就诊人。
如图4所示，其示出了另一种医疗卡管理界面的示意图。该医疗卡管理界面30中包括目标跨院医疗卡33；该目标跨院医疗卡33可以在第一医院帐号对应的第一医院就诊时使用。
可选地，上述就诊可以是线上获取就诊服务，如线上挂号、线上缴费、线上等；也可以是线下获取就诊服务，如线下挂号、线下缴费、线下取药等。本申请实施例对此不作限定。
需要说明的一点是，在本申请实施例中，医疗卡是指在医院就诊时使用的，用于标识用户身份的电子卡片，医疗卡也可以称为健康卡、就诊卡、诊疗卡等等，本申请实施例对此不作限定。
还需要说明的一点是，本申请实施例中提及的界面(如医疗卡管理界面、医疗卡授权关联界面)可以是网页形式的用户界面，也可以是非网页形式的用户界面。
还需要说明的一点是，本申请实施例中仅以从第一医院帐号进行跨院医疗卡的关联操作为例，在一些其它实施例中，还可以从医院小程序或者医院网页进行跨院医疗卡的关联操作。本申请实施例对此不作限定。
综上所述，本申请实施例提供的技术方案，通过在第一医院的医疗卡管理界面中进行跨院医疗卡关联授权，将第一医院帐号与已申请创建的目标跨院医疗卡进行关联，以使得用户可以在第一医院帐号对应的第一医院就诊时直接使用该目标跨院医疗卡。相比于相关技术中，用户到不同的医院就诊，需要重复输入个人信息进行帐号注册办理医疗卡，操作繁琐，本申请实施例提供的技术方案，用户在不同医院就诊时，直接进行跨院医疗卡关联，不需要重复输入手机号、姓名、年龄、身份证号、家庭住址等个人基本信息进行注册，操作简洁高效。
请参考图5，其示出了本申请另一个实施例提供的医疗卡的关联方法的流程图。在本实施例中，主要以该方法应用于图1所示实施环境的终端中安装运行的客户端中来举例说明。该方法可以包括如下几个步骤：
步骤501，显示第二医院帐号的医疗卡管理界面。
第二医院是与第一医院不同的医院。上述第二医院帐号用于标识该第二医院。客户端可以显示第二医院帐号的医疗卡管理界面。
上述第二医院帐号的医疗卡管理界面是用于管理第二医院帐号下的医疗卡的界面。用户可以在该第二医院帐号的医疗卡管理界面中对医疗卡进行管理，如添加医疗卡、关联医疗卡等等。
第二医院的医疗卡管理界面与第一医院的医疗卡管理界面相同或类似，此处不再赘述。
步骤502，获取在第二医院帐号的医疗卡管理界面中输入的医疗卡创建指令。
用户可以点击上述第二医院帐号的医疗卡管理界面中的医疗卡添加控件，以获取医疗卡创建指令。该医疗卡创建指令用于指示创建医疗卡。
步骤503，根据医疗卡创建指令，显示医疗卡跨院服务平台的医疗卡创建界面。
在获取到上述医疗卡创建指令后，可以显示医疗卡跨院服务平台的医疗卡创建界面。上述医疗卡创建界面用于获取目标用户信息，目标用户信息包括目标用户的姓名、身份证号码、民族、居住地址、手机号码等等。
步骤504，获取在医疗卡创建界面中输入的目标用户信息。
上述医疗卡创建界面中显示有手动输入控件、照片输入控件、步骤跳转控件和医疗卡关联控件。上述手动输入控件是用于展示手动输入信息项目的操作控件，当获取到对应于上述手动输入控件的触发信号后，显示手动输入信息项目，如姓名、身份证号码、民族、居住地址等等。上述照片输入控件是用于展示照片上传界面的操作控件。在获取到对应于照片输入控件的触发信号时，显示照片上传界面，该照片上传界面中包括照片上传控件；当获取到对应于上述照片上传控件的触发信号后，上传照片，客户端接收用户上传的身份证照片，以从该身份证照片中提取目标用户信息。
上述步骤跳转控件用于在医疗卡创建界面中显示下一个步骤中需要输入的目标用户的信息，如手机号码。
如图6所示，其示例性示出了一种医疗卡创建界面的示意图。如图6中的(a)部分，用户选择手动输入用户信息，用户在医疗卡创建界面60中点击手动输入控件61，如“输入身份证号码”，显示手动输入信息项目62，如姓名、身份证号码、民族、居住地址等，用户在各个信息项目中输入相应用户信息；之后，用户可以点击步骤跳转控件63，如图6中的(a)部分，在医疗卡创建界面60中显示下一个步骤中需要输入的目标用户的信息64，如电话号码。可选地，客户端还可以获取手机号验证码65，该手机号验证码用于验证所填写的手机号码是属于目标用户。
步骤505，根据目标用户信息创建目标跨院医疗卡。
在获取到上述目标用户信息后，可以根据该目标用户信息创建目标跨院医疗卡，该目标跨院医疗卡用于在第二医院帐号对应的第二医院就诊时使用。
步骤506，显示第一医院帐号的医疗卡管理界面。
此步骤与图2实施例中步骤201相同或类似，此处不再赘述。
步骤507，获取在第一医院帐号的医疗卡管理界面中输入的医疗卡关联指令。
此步骤与图2实施例中步骤202相同或类似，此处不再赘述。
步骤508，根据医疗卡关联指令，显示医疗卡跨院服务平台的医疗卡授权关联界面。
此步骤与图2实施例中步骤203相同或类似，此处不再赘述。
上述医疗卡授权关联界面中包括授权确认控件和授权取消控件。其中，授权确认控件用于确认授权第一医院帐号与已申请创建的跨院医疗卡进行关联；授权取消控件用于取消第一医院帐号与已申请创建的跨院医疗卡进行关联。
示例性地，如图7所示，其示例性示出了一种医疗卡授权关联界面的示意图。该医疗卡授权关联界面70中包括授权确认控件71，如“确认授权”，和授权取消控件72，如“暂不授权”。
步骤509，接收对应于医疗卡授权关联界面中的授权确认控件的触发信号。
用户点击上述医疗卡授权关联界面中的授权确认控件，对应地，客户端接收对应于医疗卡授权关联界面中的授权确认控件的触发信号。该触发信号用于触发显示医疗卡列表。
步骤510，根据触发信号显示医疗卡列表。
在获取到上述触发信号之后，可以根据该触发信号在医疗卡授权关联界面中显示医疗卡列表，该医疗卡列表中包括至少一个跨院医疗卡。该至少一个跨院医疗卡是医疗卡授权关联界面中包括已申请创建的至少一个跨院医疗卡。
示例性地，如图8所示，其示例性示出了一种医疗卡列表的示意图。该医疗卡授权关联界中显示的医疗卡列表包括2个跨院医疗卡，如第一个医疗卡73和第二个医疗卡74，每个跨院医疗卡对应于一个就诊人。如第一个医疗卡对应的就诊人为白小白，第二个医疗卡对应的就诊人为赵铁柱。
可选地，医疗卡列表中还包括每个跨院医疗卡对应的关联标识，该关联标识用于指示是否已授权关联第一医院。
示例性地，继续参考图8，第二个医疗卡74的右上角中显示有关联标识75，如“已关联”，表示第二个医疗卡74已与第一医院帐号进行了关联；第一医疗卡中未显示关联标识，则表示第一个医疗卡73还未与第一医院帐号进行关联。
可选地，上述医疗卡列表中，跨院医疗卡的显示样式，可以是卡片的样式，也可以是就诊人条目的样式。本申请实施例对此不作限定。
可选地，继续参考图8，上述医疗卡授权关联界70中包括添加就诊人控件76，该添加就诊人控件用于添加除医疗卡列表中的就诊人之外的其它就诊人。
若医疗卡列表中不存在目标就诊人对应的跨院医疗卡，接收对应于添加就诊人控件的触发信号；在接收到对应于添加就诊人控件的触发信号后，显示医疗卡跨院服务平台的医疗卡创建界面；获取在医疗卡创建界面中输入的就诊人信息；根据就诊人信息创建目标跨院医疗卡。
上述在医疗卡授权关联界面显示添加就诊人控件，可以在没有合适的就诊人的情况下，直接通过该添加就诊人控件进行就诊人添加，并创建该就诊人的目标跨院医疗卡，从而不需要回退到初始的医疗卡管理界面后再进行添加，简化了用户操作。
步骤511，在接收到对应于医疗卡列表中的目标跨院医疗卡的选择信号之后，获取对应于目标跨院医疗卡的授权关联指令。
用户可以选择医疗卡列表中的任意一个医疗卡作为目标跨院医疗卡。在接收到对应于目标跨院医疗卡的选择信号之后，获取对应于目标跨院医疗卡的授权关联指令。上述授权关联指令用于指示将第一医院帐号与目标跨院医疗卡进行关联。
示例性地，继续参考图8，用户选择目标跨院医疗卡，如第一个医疗卡73，以获取对应于该目标跨院医疗卡的授权关联指令。
步骤512，显示第一医院帐号的医疗卡管理界面，在第一医院帐号的医疗卡管理界面中显示目标跨院医疗卡，上述目标跨院医疗卡用于在第一医院帐号对应的第一医院就诊时使用。
此步骤与图2实施例中步骤205相同或类似，此处不再赘述。
步骤513，在接收到对应于目标跨院医疗卡的详情显示指令之后，显示目标跨院医疗卡对应的详情界面。
上述目标跨院医疗卡对应的详情界面是用于显示目标跨院医疗卡的详细信息的界面。该详情界面中包括以下至少一项：目标跨院医疗卡对应的二维码、目标跨院医疗卡对应的目标用户信息。
如图9所示，其示例性示出了一种详情界面的示意图。该详情界面90中可以包括目标跨院医疗卡对应的二维码91、目标跨院医疗卡对应的目标用户信息92，如姓名、身份证号、就诊卡号、手机号等。
可选地，详情界面中还包括医疗卡收藏控件。该医疗卡收藏控件是将医疗卡收藏在卡券管理界面中的操作控件。上述卡券管理界面是用于管理收藏的卡券的界面。
此时，上述显示目标跨院医疗卡对应的详情界面之后，还包括：在接收到对应于医疗卡收藏控件的触发信号之后，在卡券管理界面中添加目标跨院医疗卡。
示例性地，如图10所示，其示例性示出了另一种详情界面的示意图。该详情界面90中还包括医疗卡收藏控件93，如“领取到卡包”，以在卡券管理界面中添加目标跨院医疗卡。之后，如图11所示，可以在卡券管理界面11中显示该目标跨院医疗卡。用户可以从该卡券管理界面11中选择使用该目标跨院医疗卡。
综上所述，本申请实施例提供的技术方案，通过在第二医院帐号的医疗卡管理界面中申请创建目标跨院医疗卡，并在第一医院帐号的医疗卡授权关联界面中将该目标跨院医疗卡与第一医院帐号进行关联，以便在第一医院帐号对应的第一医院就诊时使用。相比于相关技术中，用户到不同的医院就诊，需要重复进行帐号注册办理医疗卡。本申请实施例提供的技术方案，将跨院医疗卡与不同的医院帐号进行关联，使得用户在不同医院就诊时，直接使用该跨院医疗卡就诊，实现快速跨医院办理医疗卡。
另外，在医疗卡授权关联界面显示添加就诊人控件，可以在没有合适的就诊人的情况下，直接通过该添加就诊人控件进行就诊人添加，并创建该就诊人的目标跨院医疗卡，从而不需要回退到初始的医疗卡管理界面后再进行添加，简化了用户操作。
另外，通过医疗卡收藏控件可以将关联的医疗卡添加到卡券管理界面，使得用户之后需要使用跨院医疗卡时，可以直接从该卡券管理管理界面中打开跨院医疗卡，无需进入医院帐号，节省了操作步骤。
请参考图12，其示出了本申请另一个实施例提供的医疗卡的关联方法的流程图。在本实施例中，主要以该方法应用于图1所示实施环境中来举例说明。该方法可以包括如下几个步骤：
步骤1201，客户端向第一医院帐号对应的服务器发送医疗卡关联请求。
上述医疗卡关联请求用于请求将第一医院帐号与在医疗卡跨院服务平台中已申请创建的跨院医疗卡进行关联。上述医疗卡关联请求中包括客户端中登录的目标用户帐号。
客户端中可以显示第一医院帐号的医疗卡管理界面，该医疗卡管理界面中包括医疗卡关联控件，客户端在获取到对应于该医疗卡关联控件的触发信号后，向第一医院帐号对应的服务器发送医疗卡关联请求，以请求将第一医院帐号与在医疗卡跨院服务平台中已申请创建的跨院医疗卡进行关联。
对应地，第一医院帐号对应的服务器接收医疗卡关联请求。
步骤1202，第一医院帐号对应的服务器根据医疗卡关联请求，向医疗卡跨院服务平台发送医疗卡授权请求。
上述医疗卡授权请求中包括客户端中登录的目标用户帐号，医疗卡授权请求用于请求获取经目标用户帐号授权的、与第一医院帐号相关联的目标跨院医疗卡。
对应地，医疗卡跨院服务平台接收第一医院帐号对应的服务器发送的医疗卡授权请求。
步骤1203，医疗卡跨院服务平台向客户端发送医疗卡授权指示。
上述医疗卡授权指示用于用户在客户端中进行医疗卡授权确认。该医疗卡授权指示中包括目标用户帐号在医疗卡跨院服务平台中已申请创建的至少一个跨院医疗卡。
对应地，客户端接收医疗卡跨院服务平台发送的医疗卡授权指示。客户端在接收到上述医疗卡跨院服务平台发送的医疗卡授权指示后，显示医疗卡授权关联界面，该医疗卡关联界面中显示有医疗卡列表，该医疗卡列表中包括至少一个跨院医疗卡。
步骤1204，客户端向医疗卡跨院服务平台发送对应于目标跨院医疗卡的授权确认指示。
上述对应于目标跨院医疗卡的授权确认指示确认将第一医院帐号与目标跨院医疗卡进行关联。该对应于目标跨院医疗卡的授权确认指示中包括目标跨院医疗卡的相关信息，该目标跨院医疗卡的相关信息包括该目标跨院医疗卡对应的就诊人的信息、目标跨院医疗卡的标识和目标跨院医疗卡的二维码等等。
对应地，医疗卡跨院服务平台接收所述客户端发送的对应于所述目标跨院医疗卡的授权确认指示。
步骤1205，医疗卡跨院服务平台向第一医院帐号对应的服务器发送目标跨院医疗卡的相关信息，目标跨院医疗卡用于在第一医院帐号对应的第一医院就诊时使用。
医疗卡跨院服务平台在获取到上述对应于目标跨院医疗卡的授权确认指示后，可以获取目标跨院医疗卡的相关信息，并将该目标跨院医疗卡的相关信息发送给第一医院帐号对应的服务器。
对应地，第一医院帐号对应的服务器接收医疗卡跨院服务平台发送的目标跨院医疗卡的相关信息。
步骤1206，第一医院帐号对应的服务器向客户端发送医疗卡关联响应。
第一医院帐号对应的服务器在接收到上述医疗卡跨院服务平台发送的目标跨院医疗卡的相关信息后，根据该目标跨院医疗卡的相关信息将第一医院帐号与目标跨院医疗卡进行关联，并向客户端发送医疗卡关联响应。该医疗卡关联响应用于指示已成功将第一医院帐号与目标跨院医疗卡进行关联。
综上所述，本申请实施例提供的技术方案，通过第一医院帐号对应的服务器将客户端发送的医疗卡关联请求转发给跨院医疗卡平台，并在跨院医疗卡平台接收到客户端发送的对应于目标跨院医疗卡的授权确认指示后，将第一医院帐号与目标跨院医疗卡进行关联，以便目标跨院医疗卡可以在第一医院帐号对应的第一医院就诊时使用。相比于相关技术，本申请实施例提供的技术方案，通过跨院医疗卡平台将跨院医疗卡与不同的医院进行关联，从而使得在不同的医院中可以使用同一张跨院医疗卡就诊，无需重复办理医疗卡，减少了重复办理的环节，简化了就诊流程。
请参考图13，其示出了本申请又一个实施例提供的医疗卡的关联方法的流程图。在本实施例中，主要以该方法应用于图1所示实施环境中来举例说明。该方法可以包括如下几个步骤：
步骤1301，客户端向第一医院帐号对应的服务器发送医疗卡关联请求。
医疗卡关联请求用于请求将第一医院帐号与在医疗卡跨院服务平台中已申请创建的跨院医疗卡进行关联。
对应地，第一医院帐号对应的服务器接收医疗卡关联请求。
步骤1302，第一医院帐号对应的服务器根据医疗卡关联请求，向医疗卡跨院服务平台发送医疗卡授权请求。
医疗卡授权请求中包括客户端中登录的目标用户帐号，医疗卡授权请求用于请求获取经目标用户帐号授权的、与第一医院帐号相关联的目标跨院医疗卡。
对应地，医疗卡跨院服务平台接收第一医院帐号对应的服务器发送的医疗卡授权请求。
可选地，医疗卡跨院服务平台接收第一医院帐号对应的服务器发送的医疗卡授权请求之后，向客户端对应的服务器发送数据接口调用请求，该数据接口调用请求中包括用于表示目标数据接口的标识信息，该目标数据接口用于提供上述目标用户帐号的公众标识，该目标用户帐号的公众标识用于标识医疗卡跨院服务平台下的目标用户帐号；医疗卡跨院服务平台接收客户端对应的服务器发送的数据包，该数据包中包括上述目标用户帐号的公众标识。
上述公众标识可以是医疗卡跨院服务平台下的目标用户帐号的unionid，也可以是客户端的userid。
在获取到上述目标用户帐号的公众标识后，可以根据该目标用户帐号的公众标识获取经目标用户帐号授权的、与第一医院帐号相关联的目标跨院医疗卡。
步骤1303，医疗卡跨院服务平台向客户端发送医疗卡授权指示。
医疗卡授权指示中包括目标用户帐号在医疗卡跨院服务平台中已申请创建的至少一个跨院医疗卡。
对应地，客户端接收医疗卡跨院服务平台发送的医疗卡授权指示。
步骤1304，客户端向医疗卡跨院服务平台发送对应于目标跨院医疗卡的授权确认指示。
对应地，医疗卡跨院服务平台接收客户端发送的对应于目标跨院医疗卡的授权确认指示。
步骤1305，医疗卡跨院服务平台获取目标跨院医疗卡对应的验证信息。
医疗卡跨院服务平台在接收到客户端发送的对应于目标跨院医疗卡的授权确认指示后，根据该授权确认指示获取目标跨院医疗卡对应的验证信息。
可选地，医疗卡跨院服务平台还可以将该目标跨院医疗卡对应的验证信息与目标跨院医疗卡的相关信息进行关联存储。
步骤1306，医疗卡跨院服务平台向第一医院帐号对应的服务器发送验证信息。
对应地，第一医院帐号对应的服务器接收医疗卡跨院服务平台发送的目标跨院医疗卡对应的验证信息。
步骤1307，第一医院帐号对应的服务器向医疗卡跨院服务平台发送医疗卡信息获取请求。
上述医疗卡信息获取请求用于请求获取目标跨院医疗卡的相关信息。该医疗卡信息获取请求中包括验证信息。
对应地，医疗卡跨院服务平台接收第一医院帐号对应的服务器发送的医疗卡信息获取请求。
步骤1308，医疗卡跨院服务平台对验证信息进行校验。
医疗卡跨院服务平台在接收上述第一医院帐号对应的服务器发送的医疗卡信息获取请求，并对医疗卡信息获取请求中包括的验证信息进行校验。
可选地，上述对验证信息进行校验包括但不限于以下至少一项：真实性校验、来源校验、有效性校验。其中，真实性校验是指将验证信息与医疗卡跨院服务平台中的验证信息库进行比对，若该验证信息属于验证信息库，则该验证信息通过真实性校验。来源校验是指检测验证信息是否来源于目标用户帐号授权的第一医院帐号，若验证信息是来源于目标用户帐号授权的第一医院帐号，则该验证信息通过来源校验。有效性校验是指检测验证信息的存在时长是否小于预设时长，若验证信息的存在时长小于预设时长，则验证信息通过有效性校验。
通过对验证信息进行校验，能够确保信息的安全性，保证用户授权行为的安全，实现当次授权当次有效。
步骤1309，医疗卡跨院服务平台向第一医院帐号对应的服务器发送目标跨院医疗卡的相关信息，目标跨院医疗卡用于在第一医院帐号对应的第一医院就诊时使用。
医疗卡跨院服务平台在验证信息校验通过之后，向第一医院帐号对应的服务器发送目标跨院医疗卡的相关信息。
对应地，第一医院帐号对应的服务器接收医疗卡跨院服务平台发送的目标跨院医疗卡的相关信息，并根据该目标跨院医疗卡的相关信息将第一医院帐号与目标跨院医疗卡进行关联。
可选地，上述第一医院帐号对应的服务器接收医疗卡跨院服务平台发送的目标跨院医疗卡的相关信息之后，还可以执行以下步骤：
(1)第一医院帐号对应的服务器生成与目标跨院医疗卡的标识相对应的院内标识。
上述院内标识用于标识目标跨院医疗卡对应的就诊人在第一医院。
(2)第一医院帐号对应的服务器存储目标跨院医疗卡的标识与院内标识之间的映射关系。
上述映射关系用于关联目标跨院医疗卡对应的就诊人在第一医院的不同部门的医疗信息。
可选地，在上述第一医院帐号对应的服务器生成与目标跨院医疗卡的标识相对应的院内标识之前，第一医院帐号对应的服务器还可以查询目标跨院医疗卡对应的就诊人是否已经在第一医院建立医疗档案，该医疗档案包括就诊人信息、医疗信息和院内标识。若就诊人为在第一医院建立医疗档案，则第一医院帐号对应的服务器生成与目标跨院医疗卡的标识相对应的院内标识。
可选地，第一医院帐号对应的服务器还可以向医疗卡跨院服务平台发送该映射关系，以便就诊人在其它医院就诊时，其它医院帐号对应的服务器能够通通过医疗卡跨院服务平台，向第一医院帐号对应的服务器请求获取就诊人在第一医院的医疗档案。
步骤1310，第一医院帐号对应的服务器向客户端发送医疗卡关联响应。
第一医院帐号对应的服务器可以根据该目标跨院医疗卡的相关信息将第一医院帐号与目标跨院医疗卡进行关联，并向客户端发送医疗卡关联响应。该医疗卡关联响应用于指示已成功将第一医院帐号与目标跨院医疗卡进行关联。
需要说明的一点是，在相关技术中，各个医院拥有各自的医疗卡(也称为就诊卡)，且只能在各自的医院就诊时使用。在本申请实施例中，通过用户帐号在医疗卡跨院服务平台(也称为健康卡开放平台)的公众标识(如unionid)，该用户帐号的公众标识用于标识医疗卡跨院服务平台下的用户帐号，将跨院医疗卡(也称为健康卡)与各个医院帐号进行关联，从而使得跨院医疗卡可以在各个医院就诊时使用。
综上所述，本申请实施例提供的技术方案，通过第一医院帐号对应的服务器将客户端发送的医疗卡关联请求转发给跨院医疗卡平台，并在跨院医疗卡平台接收到客户端发送的对应于目标跨院医疗卡的授权确认指示后，获取目标跨院医疗卡对应的验证信息，并在该验证信息通过校验后，将第一医院帐号与目标跨院医疗卡进行关联，以便目标跨院医疗卡可以在第一医院帐号对应的第一医院就诊时使用。相比于相关技术，本申请实施例提供的技术方案，通过跨院医疗卡平台将跨院医疗卡与不同的医院进行关联，从而使得在不同的医院中可以使用同一张跨院医疗卡就诊，无需重复办理医疗卡，减少了重复办理的环节，简化了就诊流程。
另外，跨院医疗卡平台获取目标跨院医疗卡对应的验证信息，并在该验证信息通过校验后，将第一医院帐号与目标跨院医疗卡进行关联。从而保证了信息的安全性，保证用户授权行为的安全性，实现当次授权当次有效。
结合参考图14，其示例性示出了一种跨院医疗卡关联的流程示意图。如图14的(a)部分，客户端显示第一医院帐号的医疗卡管理界面，该医疗卡管理界面30中显示有医疗卡添加控件31，如“添加健康卡”，还显示有医疗卡关联控件32，如“已有健康卡，一键快速关联”。用户可以点击该医疗卡添加控件31，客户端在接收到对应于该医疗卡添加控件的触发信号后，跳转显示如图14的(b)部分的医疗卡授权关联界面，医疗卡授权关联界面70中包括授权确认控件71，如“确认授权”，和授权取消控件72，如“暂不授权”。用户点击上述医疗卡授权关联界面中的授权确认控件71，对应地，客户端接收对应于医疗卡授权关联界面中的授权确认控件的触发信号之后，跳转显示如图14的(c)部分的医疗卡授权关联界面70。该医疗卡授权关联界面70中显示有医疗卡列表，如第一个医疗卡73和第二个医疗卡74，用户可以选择该医疗卡列表中的任意一个医疗卡作为目标跨院医疗卡(如第一个医疗卡73)，与第一医院帐号进行关系，在获取到对应于目标跨院医疗卡的选择信号之后，客户端跳转显示如图14的(d)部分的医疗卡管理界面，在该医疗卡管理界面30中包括目标跨院医疗卡33；该目标跨院医疗卡33可以在第一医院帐号对应的第一医院就诊时使用。
下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。
请参考图15，其示出了本申请一个实施例提供的医疗卡的关联装置的框图。该装置具有实现上述终端侧的方法示例的功能，所述功能可以由硬件实现，也可以由硬件执行相应的软件实现。该终端中安装运行有客户端。该装置可以是上文介绍的终端，也可以设置在终端上。该装置1500可以包括：
管理界面显示模块1510，用于显示第一医院帐号的医疗卡管理界面。
关联指令获取模块1520，用于获取在所述第一医院帐号的医疗卡管理界面中输入的医疗卡关联指令。
关联界面显示模块1530，用于根据所述医疗卡关联指令，显示医疗卡跨院服务平台的医疗卡授权关联界面。
授权指令获取模块1540，用于获取在所述医疗卡授权关联界面中输入的对应于目标跨院医疗卡的授权关联指令，所述医疗卡授权关联界面中包括已申请创建的至少一个跨院医疗卡。
所述管理界面显示模块1510，用于显示所述第一医院帐号的医疗卡管理界面，在所述第一医院帐号的医疗卡管理界面中显示所述目标跨院医疗卡，所述目标跨院医疗卡用于在所述第一医院帐号对应的第一医院就诊时使用。
综上所述，本申请实施例提供的技术方案，通过在第一医院的医疗卡管理界面中进行跨院医疗卡关联授权，将第一医院帐号与已申请创建的目标跨院医疗卡进行关联，以使得用户可以在第一医院帐号对应的第一医院就诊时直接使用该目标跨院医疗卡。相比于相关技术中，用户到不同的医院就诊，需要重复输入个人信息进行帐号注册办理医疗卡，操作繁琐，本申请实施例提供的技术方案，用户在不同医院就诊时，直接进行跨院医疗卡关联，不需要重复输入手机号、姓名、年龄、身份证号、家庭住址等个人基本信息进行注册，操作简洁高效。
在一些可能的设计中，所述授权指令获取模块1540，用于接收对应于所述医疗卡授权关联界面中的授权确认控件的触发信号；根据所述触发信号显示医疗卡列表，所述医疗卡列表中包括所述至少一个跨院医疗卡；在接收到对应于所述医疗卡列表中的所述目标跨院医疗卡的选择信号之后，获取对应于所述目标跨院医疗卡的授权关联指令。
在一些可能的设计中，如图16所示，所述装置1500还包括：创建指令获取模块1550、创建界面显示模块1560、用户信息获取模块1570和医疗卡创建模块1580。
所述管理界面显示模块1510，用于显示第二医院帐号的医疗卡管理界面。
创建指令获取模块1550，用于获取在所述第二医院帐号的医疗卡管理界面中输入的医疗卡创建指令。
创建界面显示模块1560，用于根据所述医疗卡创建指令，显示所述医疗卡跨院服务平台的医疗卡创建界面。
用户信息获取模块1570，用于获取在所述医疗卡创建界面中输入的目标用户信息。
医疗卡创建模块1580，用于根据所述目标用户信息创建所述目标跨院医疗卡，所述目标跨院医疗卡用于在所述第二医院帐号对应的第二医院就诊时使用。
在一些可能的设计中，如图16所示，所述装置1500还包括：详情界面显示模块1590。
详情界面显示模块1590，用于在接收到对应于所述目标跨院医疗卡的详情显示指令之后，显示所述目标跨院医疗卡对应的详情界面；其中，所述详情界面中包括以下至少一项：所述目标跨院医疗卡对应的二维码、所述目标跨院医疗卡对应的目标用户信息。
在一些可能的设计中，所述详情界面中还包括医疗卡收藏控件；所述装置1500还包括医疗卡添加模块1590，用于在接收到对应于所述医疗卡收藏控件的触发信号之后，在所述卡券管理界面中添加所述目标跨院医疗卡。
请参考图17，其示出了本申请又一个实施例提供的医疗卡的关联装置的框图。该装置具有实现上的第一医院帐号对应的服务器侧方法示例的功能，所述功能可以由硬件实现，也可以由硬件执行相应的软件实现。该装置可以是上文介绍的第一医院帐号对应的服务器，也可以设置在第一医院帐号对应的服务器上。该装置1700可以包括：关联请求接收模块1710、授权请求发送模块1720、相关信息接收模块1730和关联响应发送模块1740。
关联请求接收模块1710，用于接收客户端发送的医疗卡关联请求，所述医疗卡关联请求用于请求将第一医院帐号与在医疗卡跨院服务平台中已申请创建的跨院医疗卡进行关联。
授权请求发送模块1720，用于根据所述医疗卡关联请求，向所述医疗卡跨院服务平台发送医疗卡授权请求，所述医疗卡授权请求中包括所述客户端中登录的目标用户帐号，所述医疗卡授权请求用于请求获取经所述目标用户帐号授权的、与所述第一医院帐号相关联的目标跨院医疗卡。
相关信息接收模块1730，用于接收所述医疗卡跨院服务平台发送的所述目标跨院医疗卡的相关信息。
关联响应发送模块1740，用于向所述客户端发送医疗卡关联响应，所述医疗卡关联响应用于指示已成功将所述第一医院帐号与所述目标跨院医疗卡进行关联。
综上所述，本申请实施例提供的技术方案，通过在第二医院帐号的医疗卡管理界面中申请创建目标跨院医疗卡，并在第一医院帐号的医疗卡授权关联界面中将该目标跨院医疗卡与第一医院帐号进行关联，以便在第一医院帐号对应的第一医院就诊时使用。相比于相关技术中，用户到不同的医院就诊，需要重复进行帐号注册办理医疗卡。本申请实施例提供的技术方案，将跨院医疗卡与不同的医院帐号进行关联，使得用户在不同医院就诊时，直接使用该跨院医疗卡就诊，实现快速跨医院办理医疗卡。
在一些可能的设计中，如图18所示，所述装置1700还包括：验证信息接收模块1750和相关信息请求模块1760。
验证信息接收模块1750，用于接收所述医疗卡跨院服务平台发送的所述目标跨院医疗卡对应的验证信息。
相关信息请求模块1760，用于向所述医疗卡跨院服务平台发送医疗卡信息获取请求，所述医疗卡信息获取请求用于请求获取所述目标跨院医疗卡的相关信息，所述医疗卡信息获取请求中包括所述验证信息。
请参考图19，其示出了本申请又一个实施例提供的医疗卡的关联装置的框图。该装置具有实现上述医疗卡跨院服务平台侧的方法示例的功能，所述功能可以由硬件实现，也可以由硬件执行相应的软件实现。该装置可以是上文介绍的医疗卡跨院服务平台，也可以设置在医疗卡跨院服务平台上。该装置1900可以包括：授权请求接收模块1910、授权指示发送模块1920、确认指示接收模块1930和相关信息发送模块1940。
授权请求接收模块1910，用于接收第一医院帐号对应的服务器发送的医疗卡授权请求，所述医疗卡授权请求中包括客户端中登录的目标用户帐号，所述医疗卡授权请求用于请求获取经所述目标用户帐号授权的、与所述第一医院帐号相关联的目标跨院医疗卡。
授权指示发送模块1920，用于向所述客户端发送医疗卡授权指示，所述医疗卡授权指示中包括所述目标用户帐号在医疗卡跨院服务平台中已申请创建的至少一个跨院医疗卡。
确认指示接收模块1930，用于接收所述客户端发送的对应于所述目标跨院医疗卡的授权确认指示。
相关信息发送模块1940，用于向所述第一医院帐号对应的服务器发送所述目标跨院医疗卡的相关信息，所述目标跨院医疗卡用于在所述第一医院帐号对应的第一医院就诊时使用。
综上所述，本申请实施例提供的技术方案，通过在第二医院帐号的医疗卡管理界面中申请创建目标跨院医疗卡，并在第一医院帐号的医疗卡授权关联界面中将该目标跨院医疗卡与第一医院帐号进行关联，以便在第一医院帐号对应的第一医院就诊时使用。相比于相关技术中，用户到不同的医院就诊，需要重复进行帐号注册办理医疗卡。本申请实施例提供的技术方案，将跨院医疗卡与不同的医院帐号进行关联，使得用户在不同医院就诊时，直接使用该跨院医疗卡就诊，实现快速跨医院办理医疗卡。
在一些可能的设计中，如图20所示，所述装置1900还包括：验证信息获取模块1950、验证信息发送模块1960、获取请求接收模块1970和验证信息校验模块1980。
验证信息获取模块1950，用于获取所述目标跨院医疗卡对应的验证信息。
验证信息发送模块1960，用于向所述第一医院帐号对应的服务器发送所述验证信息。
获取请求接收模块1970，用于接收所述第一医院帐号对应的服务器发送的医疗卡信息获取请求，所述医疗卡信息获取请求用于请求获取所述目标跨院医疗卡的相关信息，所述医疗卡信息获取请求中包括所述验证信息。
验证信息校验模块1980，用于对所述验证信息进行校验。
所述相关信息发送模块1940，用于在所述验证信息校验通过之后，执行所述向所述第一医院帐号对应的服务器发送所述目标跨院医疗卡的相关信息的步骤。
需要说明的是，上述实施例提供的装置，在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
请参考图21，其示出了本申请一个实施例提供的终端的结构框图。通常，终端2100包括有：处理器2101和存储器2102。
处理器2101可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器2101可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(FieldProgrammable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器2101也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器2101可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器2101还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。
存储器2102可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器2102还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器2102中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器2101所执行以实现本申请中方法实施例提供的医疗卡的关联方法。
在一些实施例中，终端2100还可选包括有：外围设备接口2103和至少一个外围设备。处理器2101、存储器2102和外围设备接口2103之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口2103相连。具体地，外围设备可以包括：通信接口2104、显示屏2105、音频电路2106、摄像头组件2107、定位组件2108和电源2109中的至少一种。
本领域技术人员可以理解，图21中示出的结构并不构成对终端2100的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。
请参考图22，其示出了本申请一个实施例提供的服务器的结构示意图。该服务器用于实施上述实施例中提供的医疗卡的方法。例如，该服务器可以是图1所示实施环境中的服务器20。具体来讲：
所述服务器2200包括CPU 2201、包括RAM(Random Access Memory，随机存取存储器)2202和ROM(Read Only Memory，只读存储器)2203的系统存储器2204，以及连接系统存储器2204和中央处理单元2201的系统总线2205。所述服务器2200还包括帮助计算机内的各个器件之间传输信息的基本I/O(Input/Output输入/输出)系统2206，和用于存储操作系统2213、应用程序2214和其他程序模块2212的大容量存储设备2207。
所述基本输入/输出系统2206包括有用于显示信息的显示器2208和用于用户输入信息的诸如鼠标、键盘之类的输入设备2209。其中所述显示器2208和输入设备2209都通过连接到系统总线2205的输入输出控制器2210连接到中央处理单元2201。所述基本输入/输出系统2206还可以包括输入输出控制器2210以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器2210还提供输出到显示屏、打印机或其他类型的输出设备。
所述大容量存储设备2207通过连接到系统总线2205的大容量存储控制器(未示出)连接到中央处理单元2201。所述大容量存储设备2207及其相关联的计算机可读介质为服务器2200提供非易失性存储。也就是说，所述大容量存储设备2207可以包括诸如硬盘或者CD-ROM驱动器之类的计算机可读介质(未示出)。
不失一般性，所述计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、EPROM(Erasable Programmable Read Only Memory，可擦除可编程只读存储器)、EEPROM(Electrically Erasable Programmable read only memory，带电可擦可编程只读存储器)、闪存或其他固态存储其技术，CD-ROM、DVD或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知所述计算机存储介质不局限于上述几种。上述的系统存储器2204和大容量存储设备2207可以统称为存储器。
根据本申请的各种实施例，所述服务器2200还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即服务器2200可以通过连接在所述系统总线2205上的网络接口单元2211连接到网络2212，或者说，也可以使用网络接口单元2211来连接到其他类型的网络或远程计算机系统(未示出)。
所述存储器还包括至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集存储于存储器中，且经配置以由一个或者一个以上处理器执行，以实现上述医疗卡的关联方法。
在示例性实施例中，还提供了一种计算机设备。该计算机设备可以是终端或服务器。所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现上述医疗卡的关联方法。
在示例性实施例中，还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或所述指令集在被处理器执行时实现上述医疗卡的关联方法。
在示例性实施例中，还提供了一种计算机程序产品，当该计算机程序产品被处理器执行时，其用于实现上述医疗卡的关联方法。
应当理解的是，在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
以上所述仅为本申请的示例性实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。
Claims (15)
1.一种医疗卡的关联方法，其特征在于，所述方法包括：
显示第一医院帐号的医疗卡管理界面；
获取在所述第一医院帐号的医疗卡管理界面中输入的医疗卡关联指令；
根据所述医疗卡关联指令，显示医疗卡跨院服务平台的医疗卡授权关联界面；
获取在所述医疗卡授权关联界面中输入的对应于目标跨院医疗卡的授权关联指令，所述医疗卡授权关联界面中包括已申请创建的至少一个跨院医疗卡；
显示所述第一医院帐号的医疗卡管理界面，在所述第一医院帐号的医疗卡管理界面中显示所述目标跨院医疗卡，所述目标跨院医疗卡用于在所述第一医院帐号对应的第一医院就诊时使用。
2.根据权利要求1所述的方法，其特征在于，所述获取在所述医疗卡授权关联界面中输入的对应于目标跨院医疗卡的授权关联指令，包括：
接收对应于所述医疗卡授权关联界面中的授权确认控件的触发信号；
根据所述触发信号显示医疗卡列表，所述医疗卡列表中包括所述至少一个跨院医疗卡；
在接收到对应于所述医疗卡列表中的所述目标跨院医疗卡的选择信号之后，获取对应于所述目标跨院医疗卡的授权关联指令。
3.根据权利要求1所述的方法，其特征在于，所述显示第一医院帐号的医疗卡管理界面之前，还包括：
显示第二医院帐号的医疗卡管理界面；
获取在所述第二医院帐号的医疗卡管理界面中输入的医疗卡创建指令；
根据所述医疗卡创建指令，显示所述医疗卡跨院服务平台的医疗卡创建界面；
获取在所述医疗卡创建界面中输入的目标用户信息；
根据所述目标用户信息创建所述目标跨院医疗卡，所述目标跨院医疗卡用于在所述第二医院帐号对应的第二医院就诊时使用。
4.根据权利要求1至3任一项所述的方法，其特征在于，所述显示所述第一医院帐号的医疗卡管理界面，在所述第一医院帐号的医疗卡管理界面中显示所述目标跨院医疗卡之后，还包括：
在接收到对应于所述目标跨院医疗卡的详情显示指令之后，显示所述目标跨院医疗卡对应的详情界面；
其中，所述详情界面中包括以下至少一项：所述目标跨院医疗卡对应的二维码、所述目标跨院医疗卡对应的目标用户信息。
5.根据权利要求4所述的方法，其特征在于，所述详情界面中还包括医疗卡收藏控件；
所述显示所述目标跨院医疗卡对应的详情界面之后，还包括：
在接收到对应于所述医疗卡收藏控件的触发信号之后，在所述卡券管理界面中添加所述目标跨院医疗卡。
6.一种医疗卡的关联方法，其特征在于，所述方法包括：
接收客户端发送的医疗卡关联请求，所述医疗卡关联请求用于请求将第一医院帐号与在医疗卡跨院服务平台中已申请创建的跨院医疗卡进行关联；
根据所述医疗卡关联请求，向所述医疗卡跨院服务平台发送医疗卡授权请求，所述医疗卡授权请求中包括所述客户端中登录的目标用户帐号，所述医疗卡授权请求用于请求获取经所述目标用户帐号授权的、与所述第一医院帐号相关联的目标跨院医疗卡；
接收所述医疗卡跨院服务平台发送的所述目标跨院医疗卡的相关信息；
向所述客户端发送医疗卡关联响应，所述医疗卡关联响应用于指示已成功将所述第一医院帐号与所述目标跨院医疗卡进行关联。
7.根据权利要求6所述的方法，其特征在于，所述接收所述医疗卡跨院服务平台发送的所述目标跨院医疗卡的相关信息之前，还包括：
接收所述医疗卡跨院服务平台发送的所述目标跨院医疗卡对应的验证信息；
向所述医疗卡跨院服务平台发送医疗卡信息获取请求，所述医疗卡信息获取请求用于请求获取所述目标跨院医疗卡的相关信息，所述医疗卡信息获取请求中包括所述验证信息。
8.根据权利要求6或7所述的方法，其特征在于，所述接收所述医疗卡跨院服务平台发送的所述目标跨院医疗卡的相关信息之后，包括：
生成与所述目标跨院医疗卡的标识相对应的院内标识；
存储所述目标跨院医疗卡的标识与所述院内标识之间的映射关系。
9.一种医疗卡的关联方法，其特征在于，所述方法包括：
接收第一医院帐号对应的服务器发送的医疗卡授权请求，所述医疗卡授权请求中包括客户端中登录的目标用户帐号，所述医疗卡授权请求用于请求获取经所述目标用户帐号授权的、与所述第一医院帐号相关联的目标跨院医疗卡；
向所述客户端发送医疗卡授权指示，所述医疗卡授权指示中包括所述目标用户帐号在医疗卡跨院服务平台中已申请创建的至少一个跨院医疗卡；
接收所述客户端发送的对应于所述目标跨院医疗卡的授权确认指示；
向所述第一医院帐号对应的服务器发送所述目标跨院医疗卡的相关信息，所述目标跨院医疗卡用于在所述第一医院帐号对应的第一医院就诊时使用。
10.根据权利要求9所述的方法，其特征在于，所述接收所述客户端发送的对应于所述目标跨院医疗卡的授权确认指示之后，还包括：
获取所述目标跨院医疗卡对应的验证信息；
向所述第一医院帐号对应的服务器发送所述验证信息；
接收所述第一医院帐号对应的服务器发送的医疗卡信息获取请求，所述医疗卡信息获取请求用于请求获取所述目标跨院医疗卡的相关信息，所述医疗卡信息获取请求中包括所述验证信息；
对所述验证信息进行校验；
在所述验证信息校验通过之后，执行所述向所述第一医院帐号对应的服务器发送所述目标跨院医疗卡的相关信息的步骤。
11.一种医疗卡的关联装置，其特征在于，所述装置包括：
管理界面显示模块，用于显示第一医院帐号的医疗卡管理界面；
关联指令获取模块，用于获取在所述第一医院帐号的医疗卡管理界面中输入的医疗卡关联指令；
关联界面显示模块，用于根据所述医疗卡关联指令，显示医疗卡跨院服务平台的医疗卡授权关联界面；
授权指令获取模块，用于获取在所述医疗卡授权关联界面中输入的对应于目标跨院医疗卡的授权关联指令，所述医疗卡授权关联界面中包括已申请创建的至少一个跨院医疗卡；
所述管理界面显示模块，用于显示所述第一医院帐号的医疗卡管理界面，在所述第一医院帐号的医疗卡管理界面中显示所述目标跨院医疗卡，所述目标跨院医疗卡用于在所述第一医院帐号对应的第一医院就诊时使用。
12.一种医疗卡的关联装置，其特征在于，所述装置包括：
关联请求接收模块，用于接收客户端发送的医疗卡关联请求，所述医疗卡关联请求用于请求将第一医院帐号与在医疗卡跨院服务平台中已申请创建的跨院医疗卡进行关联；
授权请求发送模块，用于根据所述医疗卡关联请求，向所述医疗卡跨院服务平台发送医疗卡授权请求，所述医疗卡授权请求中包括所述客户端中登录的目标用户帐号，所述医疗卡授权请求用于请求获取经所述目标用户帐号授权的、与所述第一医院帐号相关联的目标跨院医疗卡；
相关信息接收模块，用于接收所述医疗卡跨院服务平台发送的所述目标跨院医疗卡的相关信息；
关联响应发送模块，用于向所述客户端发送医疗卡关联响应，所述医疗卡关联响应用于指示已成功将所述第一医院帐号与所述目标跨院医疗卡进行关联。
13.一种医疗卡的关联装置，其特征在于，所述装置包括：
授权请求接收模块，用于接收第一医院帐号对应的服务器发送的医疗卡授权请求，所述医疗卡授权请求中包括客户端中登录的目标用户帐号，所述医疗卡授权请求用于请求获取经所述目标用户帐号授权的、与所述第一医院帐号相关联的目标跨院医疗卡；
授权指示发送模块，用于向所述客户端发送医疗卡授权指示，所述医疗卡授权指示中包括所述目标用户帐号在医疗卡跨院服务平台中已申请创建的至少一个跨院医疗卡；
确认指示接收模块，用于接收所述客户端发送的对应于所述目标跨院医疗卡的授权确认指示；
相关信息发送模块，用于向所述第一医院帐号对应的服务器发送所述目标跨院医疗卡的相关信息，所述目标跨院医疗卡用于在所述第一医院帐号对应的第一医院就诊时使用。
14.一种计算机设备，其特征在于，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1至5任一项所述的方法，或者实现如权利要求6至8任一项所述的方法，或者实现如权利要求9或10所述的方法。
15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如权利要求1至7任一项所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910812288.5A CN110517761B (zh) | 2019-08-30 | 2019-08-30 | 医疗卡的关联方法、装置、设备和存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910812288.5A CN110517761B (zh) | 2019-08-30 | 2019-08-30 | 医疗卡的关联方法、装置、设备和存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110517761A true CN110517761A (zh) | 2019-11-29 |
| CN110517761B CN110517761B (zh) | 2023-08-18 |
Family
ID=68628188
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910812288.5A Active CN110517761B (zh) | 2019-08-30 | 2019-08-30 | 医疗卡的关联方法、装置、设备和存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110517761B (zh) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120205441A1 (en) * | 2011-02-14 | 2012-08-16 | Carefusion 303, Inc. | System and method for monitoring progress of delivery of a patent-specific medication in a healthcare facility |
| CN202948450U (zh) * | 2012-11-28 | 2013-05-22 | 徐州医学院 | 医疗一卡通系统 |
| JP2016048553A (ja) * | 2014-08-25 | 2016-04-07 | 直美 洪 | 共通する患者ｉｄ番号を使用した医療・健康情報一元管理システム |
| CN107292597A (zh) * | 2017-05-26 | 2017-10-24 | 深圳医畅科技发展有限公司 | 基于社保卡实现就诊支付的方法、移动终端及存储设备 |
| CN109994192A (zh) * | 2019-04-10 | 2019-07-09 | 祝田奇奇 | 一种智能向导装置及系统 |
| CN209183272U (zh) * | 2018-12-14 | 2019-07-30 | 刘磊 | 一种医疗服务系统 |
-
2019
- 2019-08-30 CN CN201910812288.5A patent/CN110517761B/zh active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120205441A1 (en) * | 2011-02-14 | 2012-08-16 | Carefusion 303, Inc. | System and method for monitoring progress of delivery of a patent-specific medication in a healthcare facility |
| CN202948450U (zh) * | 2012-11-28 | 2013-05-22 | 徐州医学院 | 医疗一卡通系统 |
| JP2016048553A (ja) * | 2014-08-25 | 2016-04-07 | 直美 洪 | 共通する患者ｉｄ番号を使用した医療・健康情報一元管理システム |
| CN107292597A (zh) * | 2017-05-26 | 2017-10-24 | 深圳医畅科技发展有限公司 | 基于社保卡实现就诊支付的方法、移动终端及存储设备 |
| CN209183272U (zh) * | 2018-12-14 | 2019-07-30 | 刘磊 | 一种医疗服务系统 |
| CN109994192A (zh) * | 2019-04-10 | 2019-07-09 | 祝田奇奇 | 一种智能向导装置及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110517761B (zh) | 2023-08-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10811124B2 (en) | Device-driven non-intermediated blockchain system over a social integrity network | |
| CN105659558B (zh) | 计算机实现的方法、授权服务器以及计算机可读存储器 | |
| US20170278117A1 (en) | Customer experience personalisation management platform | |
| CN108595641B (zh) | 一种处方信息存储方法、设备、系统及存储介质 | |
| CN107993697A (zh) | 医疗服务平台及系统 | |
| CN107113326A (zh) | 基于规则的设备注册 | |
| CN104331669B (zh) | 智慧医疗敏感数据加密技术的应用 | |
| US11710132B2 (en) | User controlled event record system | |
| CN108351933A (zh) | 最终用户启动的访问服务器真实性检查 | |
| CN106164917B (zh) | 用于远程会话的用户特定应用激活 | |
| CN106716404A (zh) | 计算机子网内的代理服务器 | |
| CN101517557A (zh) | 用于管理虚拟房间内的资源的方法和装置 | |
| WO2020192342A1 (zh) | 一种医疗服务管理方法及装置 | |
| CN111563145B (zh) | 一种在线咨询方法、装置 | |
| US20230291740A1 (en) | Systems and Methods for Providing Support Services in a Virtual Environment | |
| CN108734580A (zh) | 一种数据处理方法、系统和计算机可读存储介质 | |
| CN110555692A (zh) | 一种虚拟资源转移方法、装置和存储介质 | |
| JP2008234109A (ja) | 自己申告方式クリニックのネットワークシステム | |
| CN108335191A (zh) | 金融账户的开户方法、金融服务系统端及计算机存储介质 | |
| CN107408261A (zh) | 对所形成的线上声誉的持续管理 | |
| CN110517761A (zh) | 医疗卡的关联方法、装置、设备和存储介质 | |
| CN103761698A (zh) | 一种真实世界临床研究患者管理系统 | |
| CN106506606A (zh) | 医用信息交互方法 | |
| CN107301615A (zh) | 一种在线医疗服务的实现方法 | |
| JP2013235419A (ja) | 高度在宅サービス調整プラットフォームをサポートする方法 |
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 |