一种互联网医院服务的创建方法、装置及电子设备

本申请涉及互联网领域，具体而言，涉及一种互联网医院服务的创建方法、装置及电子设备。

现有的方式中，互联网医院服务依托于各个实体医院的不同需求进行创建，这就需要研发平台基于各个实体医院的不同要求，分别安排人力物力进行开发、配置与测试。当多家实体医院同时想要入驻创建互联网医院服务时，研发平台开发效率降低，容易出现错误，且消耗大量人力物力，难以满足不同地区建设互联网医院的要求以及大量医院的并行入驻。

本申请实施例提供了一种互联网医院服务的创建方法、装置、电子设备及存储介质，目的在于提升互联网医院服务的创建效率。

本申请实施例第一方面提供了一种互联网医院服务的创建方法，该方法包括：接收为互联网医院服务配置的基本信息；根据基本信息，判断互联网医院服务是否存在申请记录；若没有申请记录，根据基本信息，获取相应的入驻模板；根据入驻模板中多种配置项的配置信息，创建互联网医院服务。

于一实施例中，在根据基本信息，判断互联网医院服务是否存在申请记录之后，还包括：若存在申请记录，则发送已存在申请记录的相关提示信息。

于一实施例中，基本信息包括互联网医院服务对应的实体医院信息，以及互联网医院服务的服务地区。

于一实施例中，根据基本信息获取相应的入驻模板，包括：根据基本信息包含的服务地区，获取服务地区对应配置的入驻模板。

于一实施例中，多种配置项包括问诊业务、处方业务、云药房业务、支付业务和结薪业务；根据入驻模板中多种配置项的配置信息，创建互联网医院服务，包括：根据待开通应用对应的多种业务的配置信息，调用相应的业务接口提供业务服务；互联网医院服务包括多种应用的多种业务服务。

于一实施例中，根据入驻模板中多种配置项的配置信息，创建互联网医院服务，还包括：根据待开通应用对应的多种业务的配置信息，生成每种业务对应的业务标识；当接收到业务配置查询请求时，根据业务配置查询请求携带的业务标识，展示业务标识对应的配置信息。

于一实施例中，根据入驻模板中多种配置项的配置信息，创建互联网医院服务，还包括：根据页面模板展示所有已开通的应用；当接收发布指令时，开启互联网医院服务的访问权限。

本申请实施例第二方面提供了一种互联网医院服务的创建装置,包括：接收模块，用于接收为互联网医院服务配置的基本信息；判断模块，用于根据基本信息，判断互联网医院服务是否存在申请记录；获取模块，若没有申请记录，用于根据基本信息，获取相应的入驻模板；创建模块，用于根据入驻模板中多种配置项的配置信息，创建互联网医院服务。

本申请实施例第三方面提供了一种电子设备，包括：处理器以及用于存储处理器可执行指令的存储器。其中，处理器被配置为执行本申请实施例第一方面任一项所述的互联网医院服务的创建方法。

本申请实施例第四方面提供了一种计算机可读存储介质，存储介质存储有计算机程序，计算机程序可由处理器执行以完成本申请实施例第一方面任一项所述的互联网医院服务的创建方法。

本申请提供的互联网医院服务的创建方法、装置、电子设备及存储介质，将创建互联网医院服务所需的应用或业务，通过入驻模板中多种配置项的配置信息进行配置，并生成对应的业务标识，便于多方用户在创建完成后对业务中的具体信息进行查询与修改。本申请实施例实现了针对不同互联网医院服务的不同需求，快速准确地进行创建，节省了大量人力物力，帮助互联网医院服务在入驻平台实现高效开通。

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍。

图1为本申请一实施例提供的互联网医院服务的创建场景示意图；

图2为本申请一实施例提供的电子设备的结构示意图；

图3为本申请一实施例提供的互联网医院服务的创建流程示意图；

图4为本申请一实施例提供的互联网医院服务的创建流程示意图；

图5为本申请一实施例提供的互联网医院服务的应用开通流程示意图；

图6为本申请一实施例提供的互联网医院服务的创建装置结构示意图。

附图标记：1-电子设备；10-存储器；11-总线；12-处理器；100-客户端；200-网络；300-服务端；700-互联网医院服务的创建装置；710-接收模块；720-判断模块；730-获取模块；740-创建模块。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

下面将结合附图对本申请的技术方案进行清楚、完整地描述。

请参见图1，图1为本申请一实施例提供的互联网医院服务的创建场景示意图。如图1所示，该应用场景包括客户端100和服务端300，客户端100与服务端300之间通过网络200连接。客户端100可以是个人电脑、平板电脑、智能手机，机器人控制柜等。服务端300可以是服务器或服务器集。服务端300可以执行本申请实施例提供的互联网医院服务的创建方法并将相关数据通过网络200发送至客户端100。

在该应用场景中，客户端可以互联网医院服务的开通用户或互联网医院服务的患者。服务端300根据客户端发送的创建互联网医院服务的相关信息，判断该互联网医院是否存在后，从服务端300所在电子设备1的存储器10中获取入驻模板并开始创建互联网医院服务。服务端300创建完成后，可以给客户端开启访问权限，给求医患者提供线上问诊或其他服务。在上述过程中，服务端300还可以给部分客户端(例如开通用户)开启管理权限，以便客户端针对互联网医院服务的相关配置信息进行更新。服务端与客户端处于同一个广域网环境中，并实现网络连接和通信。

请参见图2，图2为本申请一实施例提供的电子设备1的结构示意图，该电子设备1可以作为上述服务端300或客户端100。如图2所示，电子设备1包括至少一个处理器12和存储器10，图2中以一个处理器12为例。处理器12和存储器10通过总线11连接，存储器10存储有可被至少一个处理器12执行的指令，指令被至少一处理器12执行，以使至少一个处理器12执行如下述实施例中的互联网医院服务的创建方法。为表述方便，后续以入驻平台作为服务端300，并作为执行主体进行描述。

请参见图3，图3为本申请一实施例提供的互联网医院服务的创建流程示意图。如图3所示，互联网医院服务的创建方法包括：

S410：接收为互联网医院服务配置的基本信息。

在该步骤中，服务端首先接收客户端发送的为互联网医院服务配置的基本信息。基本信息包括需要创建互联网医院服务的对应实体医院或实体医疗机构的相关配置信息。基本信息包括名称，或是名称对应的标识或代码，便于服务端基于基本信息进行下一步判断工作。

S420：根据基本信息，判断互联网医院服务是否存在申请记录。

在该步骤中，服务端基于基本信息查询该实体医院或实体医疗机构是否在本次申请之前申请过互联网医院服务，并依此判断互联网医院服务是否存在申请记录。

S430：若没有申请记录，根据基本信息，获取相应的入驻模板。

基本信息还可以包括互联网医院服务的服务地区，服务端根据地区要求，预先配置好符合要求的入驻模板并存储在数据库。互联网医院服务的服务地区可以包括对应实体医院或实体医疗机构的所在地，也可以包括针对患者线上问诊的对应服务开放地区，或根据互联网医院服务创建的需要定义为其他。入驻模板包括多种配置项及多种配置项的配置信息，且入驻模板可以根据地区要求预先配置为全国标准入驻模板以及地区平台入驻模板。

在该步骤中，服务端判断该互联网医院服务没有申请记录，则基于基本信息，或结合数据库中存储的地区要求，从数据库中获取到符合条件的模板。若针对各个地区对互联网医院服务的不同创建要求，基本信息中包含的服务地区目前不支持创建互联网医院服务，则对应的入驻模板不存在，服务端向客户端发出提示，提示目前该地区不支持创建互联网医院服务，例如：“目前不支持该地区医院建设”或“目前仅支持A地区建设”。

S440：根据入驻模板中配置信息，创建互联网医院服务。

配置信息可以包括互联网医院服务的多种业务相关信息，也可以包括其他信息，例如人员管理功能相关信息或是创建功能相关信息等。在该步骤之前，服务端获取到入驻模板后，将待补充的入驻模板发送至客户端，然后再次接收客户端发送的补充完成的入驻模板，并基于入驻模板中的配置信息创建互联网医院服务。

请参见图4，图4为本申请一实施例提供的互联网医院服务的创建流程示意图。如图4所示，互联网医院服务的创建方法包括：

S510：接收为互联网医院服务配置的基本信息。

互联网医院是依托于实体医疗机构，通过互联网为患者提供医疗服务的机构。它包括作为实体医疗机构第二名称的互联网医院，以及依托实体医疗机构独立设置的互联网医院。申请互联网医院主要分为三类：1、实体医疗机构独立申请互联网医院；2、实体医疗机构与第三方机构合作申请互联网医院；3、独立设置的互联网医院。

为互联网医院服务配置的基本信息包括：互联网医院服务对应的实体医院信息，以及互联网医院服务的服务地区等，该步骤与上述步骤S410相似，具体细节可以参考步骤S410中的内容。

S520：根据基本信息，判断互联网医院服务是否存在申请记录。

基于上述步骤S510，基本信息可以包括例如互联网医院的名称、服务地区、域名、或待开通应用等信息。

该步骤与上述步骤S420相似，具体细节可以参考步骤S420中的内容。若存在申请记录，则执行下述步骤S531；若不存在申请记录，则执行下述步骤S530。

S530：若不存在申请记录，根据基本信息包含的服务地区，获取服务地区对应配置的入驻模板。

创建互联网医院服务涉及问诊、处方、药房、支付、医保、监管等多个应用或项目的多个业务模块，每家医院针对每个功能都有不同的要求。入驻模板是服务端根据实体医院各业务领域当前已有业务，梳理出通用业务功能的不同实现方式，通过模块要素化的方式进行配置化改造由此生成的模板。服务端根据不同地区创建互联网医院服务的要求，配置不同的模板，以支持各地区根据各自的需求快速建设互联网医院。

获取到对应配置的入驻模板后，执行下述步骤S540。该步骤与上述步骤S430相似，具体细节请参考步骤S430对应内容。

S531：若存在申请记录，则发送已存在申请记录的相关提示信息。

若服务端基于基本信息判断该互联网医院服务存在申请记录，服务端中止互联网医院服务的创建过程，并向客户端发送提示信息提示该互联网医院服务已申请创建过，例如“该实体医院已创建过互联网医院”。

于一实施例中，申请记录包括创建完成与创建未完成两种情况，服务端基于不同情况可以向客户端发送具体提示信息。

S540：根据待开通应用对应的多种业务的配置信息，调用相应的业务接口提供业务服务。

入驻模板中包括多种配置项，多种配置项包括问诊业务、处方业务、云药房业务、支付业务和结薪业务，互联网医院服务包括多种应用的多种业务服务。配置项是由各业务抽离出来的颗粒化元素，每个入驻流程的页面中都由若干个配置项组合而成，各个配置项与各个业务及待开通应用对应。

待开通应用是互联网医院服务中，基于多种业务先后处理顺序，综合而成的项目或是应用。例如，在创建完成后，患者使用互联网医院服务时，待开通应用可以为发热门诊服务。患者就医过程中包括互联网医院提供的问诊、医生开处方、药方通过供药渠道给患者提供药品，患者向医院支付就医费用以及向互联网医院医生结薪等多项业务服务。

于一实施例中，待开通应用可以为基本信息中的内容。服务端基于步骤S510中客户端已经填写好的基本信息，获取到入驻模板并基于基本信息中的待开通应用进行入驻模板的调整，则入驻模板中已经包含客户端补充的待开通应用，后续步骤中客户端可以直接针对待开通应用中多种配置项(即各个业务)中的配置信息进行补充即可。服务端基于多种配置项(即各个业务)中的配置信息，进行各个业务接口的调用，便于互联网医院服务创建完成后，患者线上就医时服务端执行对应业务的内部逻辑。

于一实施例中，待开通应用也可以作为配置项，在服务端获取到入驻模板以后发送至客户端并由客户端补充，客户端补充待开通应用及相关业务配置项后发送至服务端，服务端接收后开始创建互联网医院服务的基本功能，具体包括：

S541：注册创建实体医院或医疗机构账户，并生成对应ID。

S542：生成对应的互联网医院服务的基本信息，包括对应ID与管理标识及相关密钥等，便于作为服务端的入驻平台针对多家互联网医院服务进行管理。

S543：配置互联网医院服务对应的信息，若客户端在配置项中未选择该项服务，则服务端创建互联网医院服务时不会建立，后续患者就医时直接通过入驻平台的页面进入互联网医院的服务功能。

S544：基于待开通应用及对应的多种业务配置项，服务端向客户端授予科室管理及医生管理菜单权限，并授予待开通应用的管理权限。

在该步骤中，授予待开通应用的管理权限是为了保证待开通应用与实体医院的具体科室与相关信息对应，例如在实体医院科室名称为脑神经外科，而入驻平台在服务端配置为神经外科时，授予科室管理及医生管理菜单权限以及授予待开通应用的管理权限，便于实体医院将自有的应用相关信息与互联网医院服务相匹配，或是做相关修改。

S545：保存当前进度相关信息至自有存储器，当前进度相关信息包括申请记录相关信息及相关配置信息等内容，同时入驻平台作为服务端将新增互联网医院服务的信息同步至自有数据库或存储器，服务端还可以将新增互联网医院服务的信息同步至与网络连接的其他第三方服务端数据库，便于执行下述步骤S547。

S546：根据待开通应用生成对应的医生池，并将相关信息对应存储在关联待开通应用信息的位置，或直接在存储器中独立存储。

S547：若待开通应用中包括医保或医保监管等关联第三方的业务配置项，则根据配置信息中的医保类型等信息，调用对应的医保接口，或根据上报医保监管的机构调用对应的医保监管接口。

例如，当待开通应用存在医保业务时，需要客户端填写医保相关的配置信息，并由服务端生成医保相关配置。

于一实施例中，在完成上述基本功能体系的创建后，如果已经生成配置，入驻模板就已经固定无法修改，后续步骤将会使用该入驻模板展示所有的配置项相关细节，客户端需要再次补充待开通应用的多种业务的细节配置信息。并执行下述步骤S548：

S548：入驻平台作为服务端，根据待开通应用对应的多种业务的细节配置信息，调用相应的业务接口提供业务服务。多种业务包括问诊业务、处方业务、云药房业务、支付业务和结薪业务等。并执行下述步骤S550。

S550：根据待开通应用对应的多种业务的配置信息，生成每种业务对应的业务标识。

在该步骤中，服务端根据待开通应用对应的多种业务的配置信息，将各个业务领域的配置通过各自的唯一标识进行关联，当后续接收到相关业务配置的查询请求时，根据业务配置查询请求携带的业务标识，展示业务标识对应的配置信息。

针对上述步骤S547、S548、S550，对于待开通应用对应的多种业务的配置信息，每个应用以单独标签的形式展示，客户端需要点击每个应用进行补充。服务端根据入驻模板中的配置项名称、配置项类型、是否展示、是否可修改、是否必填、默认值、是否禁用、排序、备注、输入框提示、样式等。在入驻流程里会根据各配置项的属性展示在页面上，以展示所有的配置项。当用户点击生成配置后，各业务会产生唯一标识，并在新增接口中返回。服务端记录各个业务的唯一标识后，在客户端再次查询业务配置时，服务端将会根据唯一标识查询各业务对配置项的当前配置并展示在客户端对应终端上，避免出现多个客户端同时修改配置项的值被错误覆盖的情况。上述步骤以具体名称为发热门诊服务的应用为例，在图5中介绍相关步骤S610至S680的执行流程。

S560：根据页面模板展示所有已开通的应用。

所有应用都已生成配置后，即完成开通后才允许进入该步骤，在该步骤中，入驻平台作为服务端，基于上述待开通应用及其他信息的配置搭建互联网医院页面，向客户端展示医院主页的配置模板，该模板展示所有已开通的应用，实体医院作为客户端可根据自身需求修改主页的配置模板包括的页面组件。

S570：当接收发布指令时，开启互联网医院服务的访问权限。

服务端接收发布指令后，基于修改后的主页配置模板将其存储至存储器，并开启互联网医院服务的访问权限，此时互联网医院服务的链接就可以被外网访问并看到经实体医院修改后的页面，互联网医院创建完成。

请参见图5，图5为本申请一实施例提供的互联网医院服务的应用开通流程示意图。如图5所示，以具体名称为发热门诊服务的应用为例，下述步骤S610至S680介绍相关应用开通流程，包括：

S610：根据入驻模板，接收待开通应用对应的多种业务服务的配置信息。

例如，实体医院设置发热门诊服务作为其中一个待开通应用，该发热应用包括问诊、处方、药房、供药、审查处方、支付费用以及结薪等依次执行的相关业务作为各个配置项，实体医院作为客户端需要补充多种业务服务的细节性配置信息。

S620：调用问诊接口，生成问诊标识。

在该步骤中，服务端根据客户端选择的问诊业务调用相关业务接口，例如在发热门诊服务中，可能根据时间不同互联网医院会安排不同医生工作，还可能根据医生级别具体区分各个问诊类型等。服务端基于客户端匹配的各项配置信息，调用不同的发热问诊接口，并生成对应的唯一问诊标识。后续如果相关信息发生变动，例如某问诊服务的医生变动，实体医院可以基于对应的问诊标识查询并修改该配置信息。

S630：调用处方接口，生成处方标识。

在该步骤中，服务端根据客户端选择的处方业务调用相关业务接口，例如医生需要开具的针对发热病情的处方，可能根据发热病因与病情程度等，开具包括问诊医院、日期，病情，相关诊断、药方、问诊医生、费用等多方面信息的处方，并生成对应的唯一标识，便于后续步骤的执行或者患者等多方客户端进行查看或修改。

S640：调用云药房接口、供药关系接口、审方接口。

基于上述步骤中的内容与相关配置信息，服务端根据客户端选择的业务调用云药房接口及供药关系接口，保证后续提供互联网医院服务执行内部逻辑时，可以顺利向患者提供药品；服务端还会根据客户端选择的审方业务调用审方接口，便于后续互联网医院服务执行内部逻辑时，审查团队对医生开具的处方进行再次检查，确认最开始医生诊断与开具药品无误，保证患者就医质量。

S650：调用支付接口。

基于上述步骤中的内容与相关配置信息，服务端根据客户端选择的支付业务调用支付接口，便于后续向患者提供互联网医院服务并执行内部逻辑时，患者可以向互联网医院服务支付就诊相关费用。

S660：调用结薪接口。

基于上述步骤中的内容与相关配置信息，服务端根据客户端选择的结薪业务调用结薪接口，便于后续执行内部逻辑时，可以和医生结薪。

于一实施例中，针对互联网医院服务中的结薪业务，患者费用直接付款给医院时，入职平台作为服务端不需要和医生结薪，无需配置结薪业务与结薪信息。而患者付款给微医时，微医需要根据实体医疗机构之前补充必填项中的结薪信息，和对应医生结薪。

于本申请其他实施例中，上述步骤中包括的配置项并非局限于问诊、处方、药房、供药、审查处方、支付费用以及结薪业务，可能根据实际互联网医院服务的创建需要进行变动。

S670：应用开通成功。

应用开通成功后，保存当前进度并自动执行步骤S560至步骤S570。

S680：应用开通失败，自动存储当前进度与相关信息。

在上述步骤S610至S660中的任一步骤执行失败时，后续互联网医院服务创建完成后都无法执行内部逻辑或进行查询与修改。因此任一步骤失败，服务端都会自动终止互联网医院创建过程，同时自动存储当前进度与相关信息。入驻平台作为服务端，在相关人员查看失败信息中包括的当前进度与相关信息并进行分析后，将错误原因反馈至客户端，便于后续客户端在当前步骤继续创建互联网医院服务。

本申请实施例提供的一种互联网医院服务的创建方法，通过一个自动化入驻的平台，不同实体医院只需要按照医院的不同建设需求，补充页面所需要的配置信息，即可通过自动化、可视化的方式进行快速准确地创建，同时本申请便于多方用户在创建完成后对业务中的具体信息进行查询与修改，不需要再投入人力开发、配置、测试。具有可复用性强、效率高等特点，帮助互联网医院服务在入驻平台中实现高效开通。

请参见图6，图6为本申请一实施例提供的互联网医院服务的创建装置700结构示意图。如图6所示，互联网医院服务的创建装置700包括：接收模块710，用于接收为互联网医院服务配置的基本信息；判断模块720，用于根据基本信息，判断互联网医院服务是否存在申请记录；获取模块730，若没有申请记录，用于根据基本信息，获取相应的入驻模板；创建模块740，用于根据入驻模板中多种配置项的配置信息，创建互联网医院服务。

上述装置中各个模块的功能和作用的实现过程具体详见上述互联网医院服务的创建方法中对应步骤的实现过程，在此不再赘述。

在本申请所提供的几个实施例中，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依据所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

本申请实施例提供了一种计算机可读存储介质，存储介质存储有计算机程序。计算机程序可由处理器12执行，以完成本申请任一实施例中互联网医院服务的创建方法。

功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-On ly Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。