医疗健康应用程序框架构建方法、系统、设备及介质技术方案

本申请提供了一种医疗健康应用程序框架构建方法、系统、设备及介质，首先对多个服务产品进行标准化封装，得到多个基础服务，然后基于基础服务和组合服务进行组装，得到企业客户服务；最后，针对基础服务、组合服务和/或企业客户服务，经客户化封装后统一输出至个人客户端或企业客户端。可见，通过对各个基础服务进行标准化封装，可在相同或不同的履约平台复用履约链路，避免针对不同用户在不同履约平台的履约服务重复开发，实现能力共享，为不同用户群体、不同企业、不同履约平台提供高可配的服务能力。务能力。务能力。

【技术实现步骤摘要】
医疗健康应用程序框架构建方法、系统、设备及介质


[0001]本申请涉及数字医疗
，尤其是涉及到一种医疗健康应用程序框架构建方法、系统、设备及介质。

技术介绍

[0002]随着智慧医疗的发展，越来越多的医疗健康应用程序应运而生。用户(个人用户或企业用户)可以在应用程序上进行挂号、体检、陪诊、购药、咨询等医疗健康方面的操作。
[0003]医疗健康履约服务作为标准化程度较低的服务产品，对于一家面向C端(Consumer端，个人用户端)的医疗健康服务应用程序，可以重点打磨自己的服务产品，统一通过自有的应用终端输出给C端用户；对于一家面向B端(Business端，企业用户端)的应用程序，可以各履约服务标准化接入至B端SAAS(Software as a Service，软件服务化)平台，统一输出给B端企业，也可以各履约服务直接对接B端企业客户。但对于一家从C端向B端战略升级的应用程序，如何将原本研发服务于C端的几十项医疗健康履约服务快速并高质量得输出给企业客户的员工或企业客户自有的C端用户，目前业内并没有特别契合的应用程序架构可以直接复用。
[0004]因此，如何实现C端用户和B端用户在相同或不同的履约平台复用履约链路，避免针对不同用户在不同履约平台的履约服务重复开发、实现能力共享，是医疗健康应用程序架构设计时需要考虑的一个技术问题。

技术实现思路

[0005]有鉴于此，本申请提供了一种医疗健康应用程序框架构建方法、系统、设备及介质，主要目的在于打通各履约平台复用履约链路，为不同用户群体、不同企业、不同履约平台提供高可配的服务能力。
[0006]依据本申请的一个方面，提供了一种医疗健康应用程序框架构建方法，包括：基于医疗健康服务产品履约流程，对多个服务产品进行标准化封装，得到多个基础服务；对所述多个基础服务进行关联性分析，得到由至少两个基础服务组成的至少一个组合服务，以及，针对基础服务和组合服务，根据企业客户诉求信息分析，对至少一个基础服务和至少一个组合服务进行组装，得到至少一个企业客户服务；针对基础服务、组合服务和/或企业客户服务，经客户化封装后统一输出至个人客户端或企业客户端。
[0007]依据本申请的一个方面，提供了一种医疗健康应用程序框架构建系统，包括：医疗健康履约服务系统，用于基于医疗健康服务产品履约流程，对多个服务产品进行标准化封装，得到多个基础服务；产品服务中台，用于对所述多个基础服务进行关联性分析，得到由至少两个基础服务组成的至少一个组合服务，以及，针对基础服务和组合服务，根据企业客户诉求信息分析，对至少一个基础服务和至少一个组合服务进行组装，得到至少一个企业客户服务；企业健康管理云平台，用于针对基础服务、组合服务和/或企业客户服务，经客户化封装后统一输出至个人客户端或企业客户端。
[0008]依据本申请的一个方面，提供了一种计算机设备，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述医疗健康应用程序框架构建方法。
[0009]依据本申请的一个方面，提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述医疗健康应用程序框架构建方法。
[0010]借由上述技术方案，本申请提供的一种医疗健康应用程序框架构建方法、系统、设备及介质，首先对多个服务产品进行标准化封装，得到多个基础服务，然后基于基础服务和组合服务进行组装，得到企业客户服务；最后，针对基础服务、组合服务和/或企业客户服务，经客户化封装后统一输出至个人客户端或企业客户端。可见，通过对各个基础服务进行标准化封装，可在相同或不同的履约平台复用履约链路，避免针对不同用户在不同履约平台的履约服务重复开发，实现能力共享，为不同用户群体、不同企业、不同履约平台提供高可配的服务能力。
[0011]上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。
附图说明
[0012]此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
[0013]图1示出了本申请实施例提供的一种医疗健康应用程序框架构建场景示意图；
[0014]图2示出了本申请实施例提供的一种医疗健康应用程序框架构建方法流程图；
[0015]图3示出了本申请实施例提供的一种医疗健康应用程序框架构建系统示意图；
[0016]图4示出了本申请实施例提供的一种医疗健康应用程序框架构建计算机设备结构示意图；
[0017]图5示出了本申请实施例提供的另一种医疗健康应用程序框架构建计算机设备结构示意图。
具体实施方式
[0018]为了使本
的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
[0019]如前分析的，为了实现C端用户和B端用户在相同或不同的履约平台复用履约链路，避免针对不同用户在不同履约平台的履约服务重复开发、实现能力共享，本申请实施例提供一种医疗健康应用程序框架构建方法及系统。在该医疗健康应用程序框架中，为不同用户群体、不同企业、不同履约平台提供高可配的服务能力。
[0020]参见图1，为本申请实施例提供的一种医疗健康应用程序框架构建场景示意图。该
医疗健康应用程序框架中，主要包括医疗健康履约服务系统、产品服务中台和企业健康管理云平台三大模块，实现过程主要包括：1.医疗健康履约服务系统的服务产品通过标准化SOP(Standard Operation Procedure，标准作业程序)定义上架至产品服务中台，由产品服务中台基于各标准服务包装出可对企业客户销售的客户产品。2.医疗健康履约服务系统的标准H5履约链路及标准API接口对接至企业健康管理云平台。3.企业健康管理云平台和产品服务中台打通联动，通过客户化封装，统一对B端企业输出高可配的履约服务能力。由此，实现了将医疗健康应用程序从C端向B端的融合开发，实现战略升级。
[0021]参见图2，示出了本申请实施例提供的一种医疗健康应用程序框架构建方法流程图，包括如下步骤S201
‑
S204。
[0022]S201：基于医疗健康服务产品履约流程，对多个服务产品进行标准化封装，得到多个基础服务。
[0023]基础服务，是指医疗健康应用程序所提供的各个基础性医疗健康的功能模块，每个基础服务可理解为完成一个医疗健康的功能，例如，基础服务包本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种医疗健康应用程序框架构建方法，其特征在于，包括：基于医疗健康服务产品履约流程，对多个服务产品进行标准化封装，得到多个基础服务；对所述多个基础服务进行关联性分析，得到由至少两个基础服务组成的至少一个组合服务，以及，针对基础服务和组合服务，根据企业客户诉求信息分析，对至少一个基础服务和至少一个组合服务进行组装，得到至少一个企业客户服务；针对基础服务、组合服务和/或企业客户服务，经客户化封装后统一输出至个人客户端或企业客户端。2.根据权利要求书1所述的方法，其特征在于，所述基于医疗健康服务产品履约流程，对多个服务产品进行标准化封装，得到多个基础服务，包括：基于医疗健康服务产品标准作业程序SOP、标准H5履约页面、标准配置参数、标准化履约链接拼接规范，对多个服务产品进行标准化封装，得到多个基础服务。3.根据权利要求2所述的方法，其特征在于，在所述得到多个基础服务之后，还包括：对所述基础服务进行登记、审核；具体包括：针对所述基础服务的医疗健康服务产品履约流程SOP、标准H5履约页面、标准配置参数、标准化履约链接拼接规范，进行登记，并对登记的基础服务进行审核，审核通过后将基础服务上架。4.根据权利要求1所述的方法，其特征在于，所述基于所述多个基础服务的关联性分析，得到由至少两个基础服务组合得到的至少一个组合服务，包括：分析各个基础服务之间的关联关系，从所述多个基础服务中进行选择，确定具有关联关系的任意至少两个基础服务；对所述任意至少两个基础服务进行组合，得到组合服务。5.根据权利要求1所述的方法，其特征在于，所述针对基础服务、组合服务和/或企业客户服务，经客户化封装后统一输出至个人客户端或企业客户端，包括：针对个人客户端，将基础服务或组合服务通过标准H5履约流程输出至个人客户端，所...

【专利技术属性】
技术研发人员：刘冬，
申请(专利权)人：康键信息技术深圳有限公司，
类型：发明
国别省市：