CN115440353A - 一种基于共享服务的数字化医疗系统及其实现方法 - Google Patents

Abstract

本发明提出一种基于共享服务的数字化医疗系统及其实现方法，系统包括：前台应用、中台和后台三部分，中台由共享服务中心、技术服务中心和数据服务中心组成。实现方法包括：调研，方案规划设计，基础共享服务构建，前台应用架构改造，共享服务中心构建，共享服务验证与优化。本系统采用共享服务架构，解决了传统前台应用采用单体架构，单体应用之间业务和数据割裂；通用功能的重复开发、维护，可扩展性差的系列问题。实现方法在兼容吸收现有信息化系统的固化成果的基础上，向开放式、兼容性的先进架构平滑演进。本发明逻辑清晰、层次分明，实现了医疗机构数字化建设的需求与成熟互联网架构的有机融合，具有广阔的应用前景。

Description

一种基于共享服务的数字化医疗系统及其实现方法

技术领域

本发明属于医疗信息化技术领域，涉及到一种基于共享服务的数字化医疗系统及其实现方法。

背景技术

早期由于医疗行业的手工业务电子化的需求，催生了大量以科室业务，特别是以收费为核心的烟囱林立的业务系统。在医院层面开发了医院信息系统(HospitalInformation System, HIS)，利用电子计算机和通讯设备，为医院所属各部门提供病人诊疗信息和行政管理信息的收集、存储、处理、提取和数据交换的能力，并满足所有授权用户的功能需求。科室层面包括：检验科的实验室信息管理系统(Laboratory InformationManagement System, LIS)，放射科的医学影像存档与通讯系统(Picture archiving andcommunication systems, PACS)和放射信息管理系统(Radioiogy information system,RIS)，专为耳鼻喉科设计的图像采集系统等。一方面业务系统分散建设、各自服务、互不相通，系统间缺乏兼容性和整合性，宏观上形成了区域之间、机构之间的“数据孤岛”，交互和协作成本高昂，而且共用功能和组件重复开发，无法实现核心能力的有效积累和持续提高，也造成了资源的极大浪费；另一方面，患者或医务工作者只能通过人工弥合信息化系统之间的割裂，导致医疗资源发挥效率不高，患者不得不花费大量的时间等待或在各个科室之间奔走。

尽管众多医院信息化厂商大力推广利用医院集成平台、信息平台、临床数据中心等方式来解决异构系统间交互及数据集成等问题，但是治标不治本，医院为打通各系统业务壁垒所花费的协调时间及开发费用依然高昂。中国发明专利公开说明书CN 112768047A公开了一种基于业务中台的医院信息一体化管理平台构建方法及系统，采用一体化业务中台设计理念，HIS、EMR、LIS、PACS等产品数据实时共享，业务互联互通。但采用统一患者注册入口来实现患者信息唯一性的方式过于简单，也不能兼容现有医疗机构信息化系统的现状；平台设计也是应用系统集成模式。中国发明专利公开说明书CN101751511A公开了新型数字化医疗信息软件门户集成系统，通过集成的方式实现向用户提供访问多种类型信息的单一入口，与已有信息化系统并存，并未解决已有信息化系统资源或能力复用的问题。中国发明专利公开说明书CN107948216A公开了一种基于SOA构架的医院集中数据分析应用云平台，有效解决了医院“信息孤岛”，同时不需要对原有系统推倒重建即可完成医院各信息系统的集成，同样属于过渡型技术方案，未能解决原有系统的资源或能力复用的问题。中国发明专利公开说明书CN110021413A公开了一种医院信息集成系统，提供了一个信息集成平台集成现有的医院信息化系统，实现了统一用户管理、统一门户管理和统一消息管理，为医院的各类用户提供了一站式的登录界面和即时消息通讯服务。同样属于过渡型技术方案，未涉及解决原有系统的资源或能力复用问题。

发明内容

为了解决上述技术问题，本发明提供一种基于共享服务的数字化医疗系统，实现以用户为中心基于全局视角规划业务需求，在共享服务的基础上实现业务流程，逐步把分散建设的多个信息化系统进行融合，避免了简单的系统集成模式缺乏可扩展性的问题，从整体架构上前瞻性的解决了当前医疗机构信息化系统分散建设、各自为政导致的烟囱式林立的根源问题。

与此相应，本发明另一个要解决的技术问题是提供一种能实现基于共享服务的数字化医疗系统的方法。

本发明解决上述技术问题的一种基于共享服务的数字化医疗系统包括：

前台应用，以App、浏览器、客户端和小程序的形式存在的应用系统；

中台，由共享服务中心、技术服务中心、数据服务中心三部分组成；

后台，由HIS、LIS、PACS、RIS、临床信息系统(Clinical Information System，CIS)、电子病例（Electronic Medical Record，EMR）、办公自动化（Office Automation，OA）等信息化系统的数据和专有服务（仅为一个前台应用所需要且仅提供给该前台应用的服务）组成。

本发明所述前台应用与传统的前台应用不同，传统前台应用是单体系统架构（一个程序里包含了一个系统或产品的所有业务功能，一个发布包、部署后运行在同一进程），传统前台应用之间业务隔离、数据独立，传统前台应用之间交互缺乏统一的标准规范，一般采用链接跳转、定制接口等后期弥补方式实现，导致交互方式的统一性、可靠性、通用性不佳；每个传统前台应用均需要开发、维护基本相同的用户管理、搜索等功能，传统前台应用的数据库专属专用，数据交换一般采用传统的物理存储介质导入导出模式，效率低、实时性差、安全性差。各传统前台应用间的重复功能建设和维护带来重复投资。实现传统前台应用间交互的集成和协作成本高昂。技术架构封闭、性能提升空间有限，导致扩展能力有限，无法快速响应业务需求。

本发明所述的前台应用基于统一标准规范，为用户在表现（视觉设计）、框架（界面设计、导航设计、信息设计）、结构（交互设计、信息框架）、范围（功能规格、内容需要）、战略（用户需求、前台应用需求）五个层面建立标准规范，不是传统前台应用各自为政、标准不同、规则不一、用户体验差异较大的情况。

本发明所述的前台应用是前后端分离后的前台应用，前台应用与后端解耦，专注于用户的交互业务流程，对后端采用服务调用模式，不依赖后端提供渲染、业务逻辑功能。

共享服务中心包括：

用户中心，以用户账户信息、用户基础档案信息及用户行为特征信息为基础的统一用户信息库，支撑用户一次登录，全部前台应用可用，满足医疗机构以用户为中心的价值创新要求，以及医疗机构内部管理的权限要求，用户中心提供的组织架构设置取代了传统应用系统均需要重复开发、维护的人员管理功能，实现一个组织架构覆盖所有科室人员，医务人员可以被赋予不同的角色和权限来使用不同的业务流程而不需要分别在各个应用系统注册，患者在各个应用系统的注册账户关联，实现任一注册账户均可登录所有应用系统，以及患者在各个应用系统产生的数据能够聚合；

医疗资源中心，以医疗机构提供的门诊、检验等资源为中心，围绕医疗资源的信息编辑、发布、撤销进行操作管理，医疗机构提供的挂号预约服务展示了出诊医生的介绍信息以及可预约的时限和名额，医疗资源的管理能力需要灵活提供给社交软件、网站、客户端等多种渠道，不需要每个前台应用单独开发、维护医疗资源的管理能力；

诊疗过程中心，围绕患者的医疗资源流转、处理运作，实现患者选择医疗资源接受诊疗的全流程管理，这种能力同样需要作为共享服务供多种渠道调用；

流程组件中心，以业务流程的通用环节为基础形成组件，组件之间通过搭配形成新的医疗资源或业务流程，目前的信息化是对业务流程的固化以及不同程度的自动化，业务流程变更或生成新的业务流程需要重新进行软件开发、上线，周期长、效率低、可靠性差，对于常见且通用的业务流程，如挂号、排队、缴费等环节可以分别做成组件，在需要产生或调整业务流程时，只需要拖拉拽组件，配置组件的参数即可实现业务流程的调整或生成，避免通用的业务流程环节的重复开发；

报表中心，提供常用报表模板和可用于自助生成新的报表模板的报表组件，目前各个传统前台应用自带报表，功能参次不齐、格式不一，管理维护工作复杂，可靠性差，把所有报表进行统计分析，去除冗余、统一格式，需要报表功能的前台应用直接调用，不需要重复开发报表功能，不但方便管理维护，而且也有利于节约大量资源；

支付中心，支付中心整合第三方支付平台能力，实现统一支付平台、统一银行接入，把各种支付渠道进行聚合，有利于管理维护，方便快速接入新的支付渠道；

技术服务中心包括：

媒体中心，提供文字、语音、视频和图像的编辑发布能力和通讯通道，例如群发短信通知、社交软件公众号运营等；

知识库，提供专家辅助决策能力；

AI中心，提供机器学习算法、模型、数据集；

数字孪生中心，提供数字孪生平台、工具、组件，支持数字孪生体的生成与运行；

设备交互中心，获取医疗设备业务数据、运行数据，并向医疗设备发出指令，实现医疗设备的统一管理、运行，现在的医疗设备是由不同的科室分散管理，供应商的服务水平参差不齐、标准不一，通过医疗设备物理层面和业务逻辑层面分离，实现物理层面的统一管理维护，业务逻辑层面不需要关注具体的物理设备信息，只需要满足业务需求即可，与使用云计算服务而无须关注具体实现云计算服务的物理服务器模式类似；

文档中心，提供文档处理的工具和管理空间；

与业务系统分散建设、各自为政一样，技术工具存在同样的问题，导致工具和能力不能共享，重复购置或开发，不但浪费资源，而且管理维护困难，通过技术服务中心可以实现技术工具的共享。

数据服务中心包括：

数据集成，提供对多源异构数据的实时或批量集成能力和工具，传统前台应用中数据依附业务系统，缺乏独立存在的机制与能力，数据分散导致数据价值低、管理维护困难、安全可靠性差，通过数据集成实现数据资产化的基础；

数据治理，提供数据治理工具和存储治理规则，数据质量决定了数据的可用性及价值，通过数据清洗、结构转换、类型转换、缺失值填充等环节实现数据的完整性、一致性和准确性；

数据开发，提供数据开发功能和工具；

数据交换，提供安全可控的数据交换能力，数据通过流动创造价值，有限的数据创造的价值有限，通过安全可控的数据交换可以补充或扩展数据的维度或数据量，提高数据的价值，例如医疗机构之间做共同就诊或同一病重的患者的诊疗数据交换，扩展研究范围；

数据管理，提供数据分级保护、敏感数据保护、标签管理功能，例如按照数字0、1、2、3设置数据保护等级，对访问数据的同样设置与数据保护等级对应的权限，具有一定权限的人员只能访问不高于该权限对应等级的数据；

数据服务，基于Open-API提供数据服务，不再向前台应用提供直接的数据库访问功能。

后台包括：

HIS、LIS、PACS、RIS、CIS、EMR、OA等信息化系统均为垂直业务系统，在基于共享服务的数字化医疗系统中不需要持续以独立完整的单体形态存在，随着共享服务能力的抽取，仅保留其作为垂直业务系统对应的数据和专有服务。后台的特点是用于医疗机构的内部的业务流程，后台应用系统的功能、性能、扩展性有限，不适合处理复杂多变的前台应用，只需要把相关功能和能力赋予中台，由中台实现缓冲与隔离。

本发明提供一种基于共享服务的数字化医疗系统实现方法，该方法包括：

调研，制作调研计划、调研提纲、确定调研对象，并实施调研，形成调研报告，充分掌握当前业务系统的难点、痛点和待改进点；

方案规划设计，基于共享服务架构规划设计方案；

基础共享服务构建，用户中心和支付中心均为成熟通用的共享服务，行业特征不明显，可以直接使用，避免从零开始构建共享服务中心；

前台应用架构改造，对前台应用的单体架构做服务化改造；

共享服务中心构建，抽取前台应用的共享服务，构建新的共享服务中心；

共享服务验证与优化。

前台应用架构改造可进一步具体为：

确定对象与目标，

制定路线图，

前后端分离，

前后端网关隔离，

新功能服务化，

微服务化改造。

共享服务中心构建可进一步具体为：

功能模块对比，

功能点统计分析，

领域模型设计，

微服务实施，

微服务验收，

微服务优化。

与现有技术相比，本发明的有益效果为：采用整体架构设计并兼顾现有信息化系统的演进需求，避免了集成方案的过渡模式。开放式的整体架构从根源上解决了传统烟囱式垂直业务系统相互之间割裂的问题，并对其逐步做服务化改造，不但实现了业务和数据的整体融合，而且能够适应数字经济时代高速发展的需求。

附图说明

图1为一个实施例中基于共享服务的数字化医疗系统结构示意图；

图2为一个实施例中传统烟囱式垂直业务系统交互示意图；

图3为一个实施例中基于共享服务的数字化医疗系统的实现方法流程示意图；

图4 为一个实施例中前台应用服务化改造方法示意图；

图 5为一个实施例中共享服务中心构建方法示意图。

具体实施方式

为了便于理解本发明，下面将对本发明进行更全面的描述，本发明可以以许多不同的形式来实现，并不限于本文所描述的实施例。相反地，提供这些实施例的目的是使本发明公开内容更加透彻全面。

除非另有定义，本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在本发明的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本发明。

本发明提供一种基于共享服务的数字化医疗系统及其实现方法，本文中所描述的具体实施例仅是对本发明精神的举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。

在一个实施例中，本发明提供一种基于共享服务的数字化医疗系统，该系统结构如图1所示，整体分为三个层面：前台应用、中台、后台。中台由共享服务中心、技术服务中心和以数据资产为基础、统一提供数据服务的数据服务中心组成。后台由HIS、LIS、PACS、RIS、CIS、EMR、OA等信息化系统的数据和专有服务组成。

前台应用，以App、浏览器、客户端和小程序的形式存在的应用系统；前台应用需要快速响应用户的需求，快速创新、快速迭代。

中台，由业务共享服务中心、技术服务中心、数据服务中心三部分组成；中台是共享能力中心，中台既可以将前台应用的稳定通用业务能力“沉降”到中台层，恢复对前台应用的响应力；又可以将后台系统中需要频繁变化或是需要被前台应用直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本，从而为前台应用提供更强大的支援。可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷，最大限度减少重复造车轮。

后台，由HIS、LIS、PACS、RIS、CIS、EMR、OA等信息化系统的数据和专有服务组成。

本发明所述前台应用与传统的前台应用不同，传统前台应用是单体系统架构，如图2所示，应用之间业务隔离、数据独立，前台应用之间交互缺乏统一的标准规范，一般采用链接跳转、定制接口等后期弥补方式实现，导致交互方式的统一性、可靠性、通用性不佳，并且每个新接入的前台应用存在与前面N-1个前台应用进行交互的可能性，连接上存在N平方难题，协调工作量大；每个前台应用均需要开发、维护基本相同的用户管理、搜索等功能，前台应用的数据库专属专用，数据交换一般采用传统的物理存储介质导入导出模式，效率低、实时性差、安全性差。各系统间的重复功能建设和维护带来重复投资。实现系统间交互的集成和协作成本高昂。技术架构封闭、性能提升空间有限，导致扩展能力有限，无法快速响应业务需求。本发明所述的前台应用应优先使用业务中台提供的共享服务，各个前台应用不需要再开发共享服务中心可以提供的服务。如用户中心统一了企业各个业务线分散的用户体系，统一了用户数据、存储和服务接口，简化了前台应用的使用，方便了对用户的大数据分析；实现了用户在医疗机构层级应用的唯一标识。实现了对用户的精准识别和跨业务系统的行为掌控；前台应用聚焦业务逻辑和用户体验，前台应用不要求共享服务中心提供专有服务，前台应用之间不应有接口或数据服务直接交互。本发明所述的前台应用基于统一标准规范，为用户在表现（视觉设计）、框架（界面设计、导航设计、信息设计）、结构（交互设计、信息框架）、范围（功能规格、内容需要）、战略（用户需求、前台应用需求）五个层面建立标准规范，不再是传统前台应用各自为政、标准不同、规则不一、用户体验差异较大的情况。本发明所述的前台应用是前后端分离后的前台应用，前台应用与后端解耦，专注于用户的交互业务流程，对后端采用服务调用模式，不依赖后端提供渲染、业务逻辑功能。

业务共享服务中心包括：

共享服务中心架构通过业务拆分来降低系统的复杂性，通过服务共享来提供可重用性，通过服务化来达到业务支持的敏捷性。以服务为核心，共享服务中心需要具有持续优化更新的生命力，承载业务逻辑、沉淀业务数据、产生业务价值，并随着医疗机构的业务不断发展进化。共享服务中心是业务需求驱动，从业务需求出发，在业务目标和需求推动下进行服务规划和设计。医疗机构层级应用系统应打破组织架构和应用系统的边界，实现医疗机构层级业务协同以及数据的共享，共享服务中心主要通过服务编排、流程编排、规则调整来支持应用系统的业务和创新。

基于共享服务的前台应用系统，避免点对点的集成方式，而是通过服务调用、服务编排、流程编排、规则配置、数据资产化等，从而实现面向服务的集成。任何应用系统之间的交互、衔接均需要通过共享服务中心完成，避免前台应用间直连式通道的接口模式。这样会破坏了共享服务体系建设，而且不能脱离垂直烟囱式的建设模式。

用户中心，以用户账户信息、用户基础档案信息及用户行为特征信息为基础的统一用户信息库，支撑用户一次登录，全部前台应用可用，满足医疗机构以用户为中心的价值创新要求，以及组织机构内部管理的权限要求，用户中心提供的组织架构设置取代了传统前台应用均需要重复开发、维护的人员管理功能，实现一个组织架构覆盖所有科室人员，医务人员可以被赋予不同的角色和权限来使用不同的业务流程而不需要分别在各个应用系统注册，患者在各个应用系统的注册账户关联，实现任一注册账户即可登录所有应用系统，以及患者在各个应用系统产生的数据能够聚合；

医疗资源中心，以医疗机构提供的门诊、检验等资源为中心，围绕医疗资源的信息编辑、发布、撤销进行操作管理，医疗机构提供的挂号预约服务展示了出诊医生的介绍信息以及可预约的时限和名额，医疗资源的管理能力需要灵活提供给社交软件、网站、客户端等多种渠道，不需要每个前台应用单独开发、维护医疗资源的管理能力；

诊疗过程中心，围绕患者的医疗资源流转、处理运作，实现患者选择医疗资源接受诊疗的全流程管理，这种能力同样需要作为共享服务供多种前台应用调用；

流程组件中心，以业务流程的通用环节为基础形成组件，组件之间通过搭配形成新的医疗资源或业务流程，目前的信息化是对业务流程的固化以及不同程度的自动化，业务流程变更或生成新的业务流程需要重新进行软件开发、上线，周期长、效率低、可靠性差，对于常见且通用的业务流程，如挂号、排队、缴费等环节可以分别做成组件，在需要产生或调整业务流程时，只需要拖拉拽组件，配置组件的参数即可实现业务流程的调整或生成，避免通用业务流程环节的重复开发；

报表中心，提供常用报表模板和可用于自助生成新的报表模板的报表组件，目前各个前台应用的自带报表功能参次不齐、格式不一，管理维护工作复杂，可靠性差，把所有报表进行统计分析，去除冗余、统一格式，需要报表功能的前台应用直接调用，不需要重复开发报表功能，不但方便管理维护，而且也节约大量的开发、维护资源；

支付中心，支付中心整合第三方支付平台能力，实现统一支付平台、统一银行接入，把各种支付渠道进行聚合，有利于管理维护，方便快速接入新的支付渠道；

技术服务中心包括：

媒体中心，提供文字、语音、视频和图像的编辑发布能力和通讯通道，例如短信群发、社交软件公众号运行维护；

知识库，提供专家辅助决策能力；

AI中心，提供机器学习算法、模型、数据集；

数字孪生中心，提供数字孪生平台、工具、组件，支持数字孪生体的生成与运行；

设备交互中心，获取医疗设备业务数据、运行数据，并向医疗设备发出指令，实现医疗设备的统一管理、运行，现在的医疗设备是由不同的科室分散管理，供应商的服务水平参差不齐、标准不一，通过医疗设备的物理层面和业务逻辑层面分离，实现物理层面的统一管理维护，业务逻辑层面不需要关注具体的物理设备信息，只需要满足业务需求即可，与使用云计算服务而无须关注具体实现云计算服务的物理服务器模式类似；

文档中心，提供文档处理的工具和管理空间；

与业务系统分散建设、各自为政一样，技术工具存在同样的问题，导致工具和能力不能共享，重复购置或开发，不但浪费资源，而且管理维护困难。

数据服务中心包括：

数据集成，提供对多源异构数据的实时或批量集成能力，目前数据依附各个业务系统，缺乏独立存在的机制与能力，数据分散导致数据价值低、管理维护困难、安全可靠性差，通过数据集成实现数据资产化的基础；

数据治理，提供数据治理工具和存储治理规则，数据质量决定了数据的可用性及价值，通过数据清洗、结构转换、类型转换、缺失值填充等环节实现数据的完整性、一致性和准确性；

数据开发，提供数据开发功能，包括数据归一化、；

数据交换，提供安全可控的数据交换能力，数据通过流动创造价值，有限的数据创造的价值有限，通过安全可控的数据交换可以补充或扩展数据的维度或数据量，提高数据的价值；

数据管理，提供数据分级保护、敏感数据保护、标签管理功能；

数据服务，基于Open-API提供数据服务。

后台包括：

HIS、LIS、PACS、RIS、CIS、EMR、OA等信息化系统均为垂直业务系统，在基于共享服务的数字化医疗系统中不需要持续以独立完整的单体形态存在，随着共享服务能力的抽取，仅保留其作为垂直业务系统对应的数据和专有服务。后台的特点是用于医疗机构的内部的业务流程，后台应用系统的功能、性能、扩展性有限，不适合处理复杂多变的前台应用，只需要把相关功能和能力赋予中台，由中台实现缓冲与隔离。

本发明提供一种基于共享服务的数字化医疗系统实现方法，如图3所示，该方法包括：

S301，调研，制作调研计划、调研提纲、确定调研对象，并实施调研，形成调研报告，充分掌握当前业务系统的难点、痛点和待改进点，内容包括不限于：业务范围、用户情况、运作模式、技术架构、功能模块、开发管理机制等；

S302，方案规划设计，基于共享服务架构规划设计方案；

S303，基础共享服务构建，用户中心和支付中心均为成熟通用的共享服务，行业特征不明显，可以直接使用，避免从零开始构建共享服务中心；

S304，前台应用架构改造，对前台应用的单体架构做服务化改造；

S305，共享服务中心构建，抽取前台应用的共享服务，构建新的共享服务中心；

S306，共享服务验证与优化。

前台应用改造是个持续迭代、优化的过程，在已有功能服务的基础上为了保证服务质量需要陆续引入服务鉴权、服务可靠性（降级、限流）、服务依赖关系调整、服务的聚合拆分等机制。并根据需要形成新的共享服务中心或者共享服务中心的功能调整。前台应用改造优化具体要求为：增加服务鉴权；服务可靠性（限流、降级等）；服务关系依赖调整；服务聚合拆分。产出物应包括：共享服务中心的功能调整优化；新的共享服务中心。

在一个实施例中，如图4所示，前台应用架构改造可进一步具体为：

S401，确定对象与目标，明确改造业务领域（原则、项目、人员、技术和成效），明确每个改造业务领域所涉及到的主要内容；

S402，制定路线图，根据前期调研的结果，制定从开始到改造目标实现的操作路线图，以指导前台应用改造的实施。确定短期、中期和长期目标。；

S403，前后端分离，前后端分离是指前台应用本身运行在用户侧的前端和运行在服务器侧的后端分离；架构层面分离解耦，前后端分开部署，通过服务接口传递数据，前端承担承担相应业务逻辑，不同前台应用的前端后端均可无差别通过标准接口交互；

S404，前后端网关隔离，前后端网关隔离是指前台应用本身运行在用户侧的前端和运行在服务器侧的后端通过网关进行隔离。通过在前端与后端之间部署服务网关，前端原来对于业务系统的直接访问均通过服务网关实施。

前后端分离示例：

前端、后端分离后仍存在直接关联关系，后端的变化是可以被前端感知甚至影响前端的运行。为了保证业务的平稳运行以及前台应用改造的稳步推进、阶段性成果验证。在前端与后端之间部署服务网关，通过服务网实现前端与后端耦合度进一步降低。

服务网关提供一个代理功能，前端原来对于业务系统的直接访问均通过服务网关实施。服务网关将单体应用的功能隐藏在其后，当单体应用被拆分或者重构的时候，整个系统对外提供的功能保持不变。服务网关需要能够灵活的适配前台应用业务原有的通讯协议，同时要能够适应拆分后的微服务协议，并且能够根据用户的请求，灵活的定制路由规则，将请求的流量按需转移到拆分后的服务。

服务网关能够收集系统运行监控数据并作为微服务拆分的依据，比如接口的时延、用户请求数、系统瓶颈等。进行微服务拆分的依据分为两类：基于业务逻辑划分和基于运维数据划分，前者和微服务功能相关，实现不同功能的模块可以独立为一个微服务；后者是处于性能方面的考虑，从而为接口单独分配更多的处理实例，或者将有状态任务单独拆分出来，提供更好的硬件资源来运行，提高单实例处理能力。通过服务网关来适配内部服务的协议差异和定制化路由转发，并收集系统的运行状态，为微服务拆分、改造提供了技术基础和改造依据。

S405，新功能服务化，前台应用改造过程中不可避免出现新的功能需求，对于新功能应直接采用服务化方式实现，避免重复开发、重复改造；新功能服务化要求为：微服务架构，分层设计，代码解耦、独立开发，独立部署、维护，降级控制、平滑切入；

S406，微服务化改造。

在又一个实施例中，按照业务领域模型作为改造目标选择从前台应用中抽取某些模块成为独立微服务。每抽取一个模块并改造成微服务，前台应用就会变的简单一些；随着模块的不断改造成微服务，前台应用原来的后端越来越小，最后消失或简单到成为一个遗留服务。

在又一个实施例中，在前端，前台应用改造也会面临从围绕一个前台应用进行的改造在部分设计和实现与其他前台应用改造存在冲突、重合的情况。需要采用合理的兼容并存机制来从全局视角解决不断增加的问题。前台应用受医疗机构聚合流量、强化品牌认知的需求驱动构建OneApp。实现OneApp的过程不可避免地存在已经聚合成OneApp与暂时不具备条件进行聚合的单个App并存的情况。这种变化对共享服务架构的需求没有明显的影响。

在后端与共享服务并存的环节，前台应用改造的重点是对相对零散的抽取服务基于全局视角审视进行优化，仅为某个前端服务的抽取服务继续保留，仅作针对该服务的性能和服务质量方面优化。对于两个或两个以上抽取服务存在功能重叠或大部分功能重叠的情况，可以考虑进行抽取服务的组合优化，整合为一个抽取服务，提高服务的质量和降低开发、维护的成本。对于服务多个前端的抽取服务从业务视角考虑组合为一个新的共享服务中心或者成为已有共享服务中心的一部分，从作为抽取服务的过渡状态成为共享服务的沉淀状态。在数据库层面从直接的数据调用逐步转化为数据服务模式，对于单体式应用中两个功能模块存在数据引用关系，在拆解微服务时停止外键引用，改造成通过RESTful HTTPAPI方式获取原先外键关联的信息模式，对于基础数据提炼出专门的领域模型并封装为微服务，通过微服务来访问这些共享的基础数据。服务化带来的好处就是彼此之间仅仅依赖服务契约。实现路径是每个微服务具有独立的数据表，与其他模块或系统不共享数据表，随着微服务业务量的增加逐步具有独立的数据库。前后端分离也符合微服务架构对系统架构解耦的必然趋势。为服务共享奠定了基础。在前后端分离的应用模式中，后端仅返回前端所需的数据，不再渲染HTML页面，不再控制前端的效；。前端决定用户的视觉效果、数据加载，对于Web、App处理数据的方式不同，但所需数据基本相同，后端仅需开发一套逻辑对外提供数据；前端后端分离后，前端与后端耦合度大大降低。

在一个实施例中，如图5所示，共享服务中心构建可进一步具体为：

S501，功能模块对比，列出每个前台应用的功能模块，并对实现相同或相近功能的模块作比较；

S502，功能点统计分析，统计每个功能模块所包含的功能点；

S503，领域模型设计，DDD（Domain-Driven Design ,领域驱动设计）作为一种软件设计方法，帮助架构师设计高质量的软件模型，DDD作为方法论可以同时指导中台业务建模和微服务建设，通过DDD战略设计指导共享服务中心设计，可以清晰地划分共享服务中心。通过DDD战术设计指导微服务的设计，可以清晰划分微服务架构的逻辑边界和物理边界；

S504，微服务实施，包括基于领域模型的微服务设计、微服务开发、部署；

S505，微服务验收，基于设计目标和验收规范对上线运行的微服务验收；

S506，微服务优化，前台应用微服务改造是个持续迭代、优化的过程，在已有功能服务的基础上为了保证服务质量需要陆续引入服务鉴权、服务可靠性（降级、限流）、服务依赖关系调整、服务的聚合拆分等机制；并根据需要形成新的共享服务中心或者共享服务中心的功能调整。

应该理解的是，虽然如上所述的实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (8)

1.一种基于共享服务的数字化医疗系统，系统包括：

前台应用，以App、浏览器、客户端和小程序的形式存在的应用系统；

中台，由共享服务中心、技术服务中心、数据服务中心三部分组成；

后台，由前台应用的数据和专有服务组成；

其特征在于：所述前台应用聚焦业务逻辑和用户体验，前台应用之间无直接交互；中台通过抽取前台应用或后台的业务能力生成共享服务，实现对前台应用的快速响应，中台不向前台应用提供专有服务。

2.根据权利要求1所述的一种基于共享服务的数字化医疗系统，其特征在于，所述共享服务中心包括：

用户中心，以用户账户信息、用户基础档案信息及用户行为特征信息为基础的统一用户信息库，支持用户一次登录，全部前台应用可用；

医疗资源中心，以医疗机构提供的门诊、检验等医疗资源为中心，围绕医疗资源的信息编辑、发布、撤销做操作管理；

诊疗过程中心，围绕患者的医疗资源流转、处理运作，实现患者选择医疗资源接受诊疗的全流程管理；

流程组件中心，以业务流程的通用环节为基础形成组件，组件之间通过搭配形成新的医疗资源或业务流程；

报表中心，提供报表模板和可用于自助生成新的报表模板的报表组件；

支付中心，支付中心整合第三方支付平台能力，实现统一支付平台、统一银行接入。

3.根据权利要求1所述的一种基于共享服务的数字化医疗系统，其特征在于，所述技术服务中心包括：

媒体中心，提供文字、语音、视频和图像的编辑发布能力和通讯通道；

知识库，提供专家辅助决策能力；

AI中心，提供机器学习算法、模型、数据集；

数字孪生中心，提供数字孪生平台、工具、组件，支持数字孪生体的生成与运行；

设备交互中心，获取医疗设备业务数据、运行数据，并向医疗设备发出指令，实现医疗设备的统一管理、运行；

文档中心，提供文档处理的工具和管理空间。

4.根据权利要求1所述的一种基于共享服务的数字化医疗系统，其特征在于，所述数据服务中心包括：

数据集成，提供对多源异构数据的实时或批量集成能力；

数据治理，提供数据治理工具和存储治理规则；

数据开发，提供数据开发功能和工具；

数据交换，提供安全可控的数据交换能力；

数据管理，提供数据分级保护、敏感数据保护、标签管理功能；

数据服务，基于Open-API提供数据服务。

5.根据权利要求1所述的一种基于共享服务的数字化医疗系统，所述后台由前台应用的数据和专有服务组成，

其特征在于：传统前台应用为垂直业务系统，在基于共享服务的数字化医疗系统中不需要持续以独立完整的单体形态存在，随着共享服务能力的抽取，后台仅保留传统前台应用的数据和专有服务。

6.一种实现权利要求1所述的基于共享服务的数字化医疗系统的实现方法，其特征在于，所述方法包括：

调研，

方案规划设计，

基础共享服务构建，

前台应用架构改造，

共享服务中心构建，

共享服务验证与优化。

7.根据权利要求6所述的基于共享服务的数字化医疗系统的实现方法，其特征在于，所述前台应用架构改造包括：

确定对象与目标，

制定路线图，

前后端分离，

前后端网关隔离，

新功能服务化，

微服务化改造。

8.根据权利要求6所述的基于共享服务的数字化医疗系统的实现方法，其特征在于，所述共享服务中心构建包括：

功能模块对比，

功能点统计分析，

领域模型设计，

微服务实施，

微服务验收，

微服务优化。

Images