一种互联网医疗平台构架的制作方法

本发明涉及技术平台架构的搭建技术领域，具体为一种互联网医疗平台构架。

背景技术：

2018年9月14日，国家卫生健康委和国家中医药管理局联合发布了《互联网诊疗管理办法(试行)》、《互联网医院管理办法(试行)》以及《远程医疗服务管理规范(试行)》，3份配套文件的出台，意味着“互联网十医疗健康”进入落地实操阶段，新政明确鼓励医疗机构应用互联网等信息技术拓展医疗服务空间和内容，构建覆盖诊前、诊中和诊后的线上线下一体化医疗服务模式，根据中国专利cn206938478u和中国专利cn204576514u，因此如果一个医疗机构要开展互联网诊疗服务对于整个诊疗流程，可以包含以下业务，首先，在医疗服务体系建设方面，依托医疗机构建设互联网医院，打造线上线下一体化医疗闭环，新政明确，允许在线开展部分常见病、慢性病复诊，医师掌握患者病历资料后，允许在线开具部分常见病、慢性病处方，同时，支持医疗卫生机构、符合条件的第三方机构搭建互联网信息平台，开展远程医疗、健康咨询和健康管理服务，而不只是过去的预约、挂号等院前和院后外围服务，其次，针对院内业务全流程改造和医院信息系统的移动化部署，除院前、院后场景外，院中环节对互联网化需求更大，比如，医院日益流行的电子就诊卡，作为流程优化的核心内容，具有患者在就医过程的所有信息，能贯穿患者就医的整个流程，第三是针对患者预后的配套服务，包括处方药品配送、院后随访、健康管理和康复护理等。

技术实现要素：

(一)解决的技术问题

针对现有技术的不足，本发明提供了一种互联网医疗平台构建方法，具备报表生成高效化的优点，解决了传统技术平台架构的搭建效率低下的问题。

(二)技术方案

为实现上述报表生成高效化的目的，本发明提供如下技术方案：一种互联网医疗平台构建方法，包括以下内容：

s01:前台。

s02:接入控制。

s03:业务服务。

s04:基础服务。

s05:中间件服务。

s06:基础设施。

优选的，所述前台包括app、web和小程序。

优选的，所述接入控制包括医生接入入口、患者接入入口、运营管理端接入入口和监管接入入口，移动应用、网页、微信支付宝小程序都是属于这层，前台产品主要是根据业务形态和产品的定位来进行构建。

优选的，所述业务服务包括在线问诊、健康宣教、家庭医生、慢病治疗、智能导诊、处方流转、挂缴查、在线预约、运营管理和药品购买，专注于通过流程编排类的技术手段，将基础服务能力构建成业务的解决方案，解决共性和个性化的问题。

优选的，所述基础服务包括订单管理、支付管理、药品管理、工作流、cms、视语通信、报表服务、权限控制、用户中心、医疗字典、库存管理、物流管理、数据同步、im聊天和数据分析，这个层包含与具体落地业务场景无关的众多基础服务，它主要包括基础能力和通用的业务服务，这样做的好处是，基础服务层聚焦于稳定收敛的业务模型和基础服务本身，不会随着业务和前台产品的调整发生变化，可以简单理解为业务模型的dao。

优选的，所述中间件服务包括发布订阅服务、orm、队列服务、定时服务和缓存服务，中间件服务主要的功能是屏蔽基础层细节，提供统一调用，主要提供以下服务的统一调用：发布-订阅，于基础层消息队列，支持生产者消费者模式，屏蔽底层集群信息，只需关注上层业务服务即可，orm屏蔽数据库底层操作细节，对于上层业务调用来说，不用关注当前操作哪个数据库，不用编写底层sql语句，就可以直接操作底层数据库，队列服务，基于基础层消息队列，支持严格按照顺序消费任务，定时服务，提供定时任务服务，缓存服务，提供缓存服务。

优选的，所述基础设施包括docker、postgres集群、redis集群、kafaka集群和elasticsearch集群，平台采用容器化部署方法，容器消除了线上线下的环境差异，保证了应用生命周期的环境一致性标准化，开发人员使用镜像实现标准开发环境的构建，开发完成后通过封装着完整环境和应用的镜像进行迁移，由此，测试和运维人员可以直接部署软件镜像来进行测试和发布，大大简化了持续集成、测试和发布的过程，平台底层数据主要存储在数据库postgres中，如果需要缓存则存储在缓存服务redis中，搜索索引数据则保存在搜索引擎es集群中，另外消息队列kafka集群也属于基础层。

(三)有益效果

与现有技术相比，本发明提供了一种互联网医疗平台构建方法，具备以下有益效果：

该互联网医疗平台构建方法，搭建基础设施，平台基于linux操作系统，系统配置配置如下：至少8核cpu，至少16g内存，至少1tssd，然后在linux系统上面安装容器工具及容器编排工具，编写好容器编排文件，然后进行镜像的构建及启动，编写或者选取通用的中间件服务，对于发布-订阅及队列服务，需要进行封装，屏蔽底层集群细节,对上层服务来说,开箱即用，orm中间件除了可以对数据库进行操作外，还要实现数据库的简单切换，甚至需要根据业务的情况是否实现数据库的动态路由；定时服务实现特定时间执行某一任务或者周期性执行某一任务的功能；缓存服务也是经过封装后对上层提供统一的缓存操作，基础服务，对于基础组件，可使用开源工具或者使用云服务，如音视频通信，im聊天等，对于通用的服务来说，支持通用的业务流程，让业务平台为日后的类似的业务系统提供灵活多变的基础业务实现方案，至于特殊的业务流程就单独开发一个特殊的业务系统，两者共同结合提供完整的服务，业务服务，将不同下层服务进行编排来完成某一个具体的业务。对于不同的具体业务来说，下层服务保持不变，变的只是下层服务的组合和业务逻辑，接入控制服务，接入控制主要通过api网关来完成，api网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过api网关这一层。在这层实现监控、统一鉴权、负载均衡等功能，前台服务，移动应用、网页、微信支付宝小程序都是属于这层，前台产品主要是根据业务形态和产品的定位来进行构建，同时平台采用分层架构，各层之间高内聚、低耦合，整个平台全面容器化,解决了安全性以及私有化部署问题，在容器化的基础上,系统采用微服务的架构,利用模块复用解决客户定制化需求多的问题。

附图说明

图1为本发明系统流程步骤图。

具体实施方法

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

请参阅图1，一种互联网医疗平台构架，包括以下内容：

s01:前台，所述前台包括app、web和小程序。

s02:接入控制，所述接入控制包括医生接入入口、患者接入入口、运营管理端接入入口和监管接入入口，移动应用、网页、微信支付宝小程序都是属于这层，前台产品主要是根据业务形态和产品的定位来进行构建。

s03:业务服务，所述业务服务包括在线问诊、健康宣教、家庭医生、慢病治疗、智能导诊、处方流转、挂缴查、在线预约、运营管理和药品购买，专注于通过流程编排类的技术手段，将基础服务能力构建成业务的解决方案，解决共性和个性化的问题。

s04:基础服务，所述基础服务包括订单管理、支付管理、药品管理、工作流、cms、视语通信、报表服务、权限控制、用户中心、医疗字典、库存管理、物流管理、数据同步、im聊天和数据分析，这个层包含与具体落地业务场景无关的众多基础服务，它主要包括基础能力和通用的业务服务，这样做的好处是，基础服务层聚焦于稳定收敛的业务模型和基础服务本身，不会随着业务和前台产品的调整发生变化，可以简单理解为业务模型的dao。

s05:中间件服务，所述中间件服务包括发布订阅服务、orm、队列服务、定时服务和缓存服务，中间件服务主要的功能是屏蔽基础层细节，提供统一调用，主要提供以下服务的统一调用：发布-订阅，于基础层消息队列，支持生产者消费者模式，屏蔽底层集群信息，只需关注上层业务服务即可，orm屏蔽数据库底层操作细节，对于上层业务调用来说，不用关注当前操作哪个数据库，不用编写底层sql语句，就可以直接操作底层数据库，队列服务，基于基础层消息队列，支持严格按照顺序消费任务，定时服务，提供定时任务服务，缓存服务，提供缓存服务。

s06:基础设施，所述基础设施包括docker、postgres集群、redis集群、kafaka集群和elasticsearch集群，平台采用容器化部署方法，容器消除了线上线下的环境差异，保证了应用生命周期的环境一致性标准化，开发人员使用镜像实现标准开发环境的构建，开发完成后通过封装着完整环境和应用的镜像进行迁移，由此，测试和运维人员可以直接部署软件镜像来进行测试和发布，大大简化了持续集成、测试和发布的过程，平台底层数据主要存储在数据库postgres中，如果需要缓存则存储在缓存服务redis中，搜索索引数据则保存在搜索引擎es集群中，另外消息队列kafka集群也属于基础层。

工作原理:搭建基础设施，平台基于linux操作系统，系统配置配置如下：至少8核cpu，至少16g内存，至少1tssd，然后在linux系统上面安装容器工具及容器编排工具，编写好容器编排文件，然后进行镜像的构建及启动，编写或者选取通用的中间件服务，对于发布-订阅及队列服务，需要进行封装，屏蔽底层集群细节,对上层服务来说,开箱即用，orm中间件除了可以对数据库进行操作外，还要实现数据库的简单切换，甚至需要根据业务的情况是否实现数据库的动态路由；定时服务实现特定时间执行某一任务或者周期性执行某一任务的功能；缓存服务也是经过封装后对上层提供统一的缓存操作，基础服务，对于基础组件，可使用开源工具或者使用云服务，如音视频通信，im聊天等，对于通用的服务来说，支持通用的业务流程，让业务平台为日后的类似的业务系统提供灵活多变的基础业务实现方案，至于特殊的业务流程就单独开发一个特殊的业务系统，两者共同结合提供完整的服务，业务服务，将不同下层服务进行编排来完成某一个具体的业务。对于不同的具体业务来说，下层服务保持不变，变的只是下层服务的组合和业务逻辑，接入控制服务，接入控制主要通过api网关来完成，api网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过api网关这一层。在这层实现监控、统一鉴权、负载均衡等功能，前台服务，移动应用、网页、微信支付宝小程序都是属于这层，前台产品主要是根据业务形态和产品的定位来进行构建。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。