医院信息化的健康生态体系结构

2019-05-27 11:11:10 爱德腕带 阅读

QQ截图20190527110839.png

最近在HIT专家网-KOL微信群里,“中台”这个概念非常火热。各种不同的思想、见解、观点,让我受益不浅,也有一些冲动想表达自己对“中台”的理解。

医院为何产生中台需求

        “中台”的概念是马云在2015年参观一个游戏公司后提出的,其核心思想是“大中台,小前台”。那到底什么是中台呢?不同的企业、不同的行业可能会有不同的定义或理解。那我们可以先抛开这一概念,去看看在医院信息化环境下遇到了哪些问题与挑战。

        为便于分析理解,以门诊预约挂号场景为例。

        最初,患者只能通过窗口进行挂号,这一过程包含一系列业务规则和流程。假设一个预约流程包含“患者信息校验”、“获取号源情况”、“分配号源”和“获取完整预约信息”4个逻辑(实际流程会复杂很多,这里简化流程以方便说明)。如下图所示:

QQ截图20190527110853.png


        后来,门诊预约从原来单一的窗口预约变得多样化,比如电话预约、网页预约、微信预约等。医院的系统的流程设计变成了下面的情况:

QQ截图20190527110900.png


        不同系统之间为了保持数据的一致性,不得不做各种各样的集成。比如,保持患者信息的统一、保证不同应用的排班一致等。而随着预约渠道越来越多,这样的集成也越来越复杂。正好集成平台应运而生,通过集成平台可以最大限度地保证各个应用之间的相对独立性。而将复杂的集成出现的各种需求,比如连接性、数据转换、过滤、路由、字典转换等放到集成平台中。于是医院信息化变成了下面的架构:

QQ截图20190527110911.png


        集成平台可以很好地解决医院历史遗留系统之间的互联互通问题。但当面临一个新需求时,系统的修改成本并没有太多改变。例如,当医院希望在预约流程中增加一个按患者级别(根据医院的定义)排预约优先级的需求时,就需要在各个业务系统中进行修改。同时由于业务逻辑的变化,各个系统之间的集成也会相应发生变化,因此集成平台的集成也需要做相应修改。

        增加一个新需求的修改成本是C *(N+1),C代表每一个系统修改的成本(以平均数来计算),N代表和该需求相关的业务系统,1代表的是集成平台。这时医院可能会认为这些成本都是乙方来承担,但其实不然,一个软件的成本是由甲乙双方共同组成。

        在乙方,软件开发商需要针对需求进行分析、开发、测试、打包、发布、实施、培训等。而且很多环节都是双倍成本,比如测试不仅需要进行新功能测试,还需要进行关联测试。如果一个产品的架构设计不合理,那么还需进行全量测试。否则任何一个人对于上线一个新功能都没有十足信心,这也是我们医院信息系统每一次升级都让大家提心吊胆的原因。打包也是同理,需要补丁包、全新包等。

        而在甲方,每一个业务系统开发商针对新需求进行需求分析时,需要安排特定人员一起进行分析。当这些系统准备上线时,医院同样需要投入大量的人力和时间进行协调、测试、培训等,这些都是一个新功能带来的成本。除了这些人力成本以外,医院还需要为重复数据进行买单,包括重复存储,重复服务器等。

        那么,如何降低成本?如何让每一次新需求或者一个新政策在实施时不那么提心吊胆,做到心里有数呢?这是每一个HIT人需要思考的问题(当然有些人不考虑成本,那就另当别论)。

多元化的IT需求凸显“中台”价值

        不管“数字化转型”这个词是不是又一个“花哨”的概念,有一点不可否认,医院正在面临信息化建设的多元化需求。压力不仅来自医院内部需求,越来越多的需求来自于医院外,比如互联网医疗、分级诊疗、区域信息平台、医疗大数据等。所有这些需求都需要对医院的数据进行访问,包括患者、就诊、医嘱、检查、检验、医务人员、设备等。

        那么医院该如何利用和保护这些资产,以提升医院的服务并适应多变的信息化环境呢?来看一种理想的情况:

QQ截图20190527110919.png


        假设将医院所有数据变成了一个个细粒度的资源,并将这些资源通过统一API方式“暴露”给业务逻辑层。业务逻辑再根据医院需求将这些资源进行组装,并通过服务的形式“暴露”给第三方应用。

        在这样的架构下,所有第三方应用通过统一的预约服务进行预约。当医院的业务逻辑需要改变时,只需对业务逻辑层进行修改,而不需要改变预约服务和数据访问层,并且这种改变对于所有的应用来说是统一的。例如,当需要在预约规则中加入对患者级别的判断时,只需要在业务逻辑层加上这个节点,一旦完成,这一业务规则就会对所有应用端同时生效。如果在业务逻辑层加入流程引擎和规则引擎,就可以相对自由地进行业务流程编排。

        在这样的架构下,一个新需求的引入,只需要对业务逻辑层进行修改、测试、实施,而客户端需要修改的也只是界面端对新业务逻辑判断返回的处理,这减少了大量的后台业务逻辑修改。对于医院来说,新需求的实现是单线程管理,不需要做大量的重复劳动和集成协调的工作,这就大大降低了新需求上线的风险。

医院需要一个健壮的IT生态体系架构

        上面谈到的理想架构适合一个全新的医院信息化建设,而对于一个已有很多业务系统的医院来说,不可能全部抛弃所有的信息系统。应该如何保护以往的投资,并在引入新技术、新系统时与旧系统能很好地无缝连接?

        下图说明了如何利用ESB将已有系统转换为可重复使用的数字资产的架构图(在这里并不是说ESB就是平台本身,而只是将现有系统转换为服务的一种实现方式)。

QQ截图20190527110927.png


        在ESB中,通过适配器访问现有系统的数据,并通过流程引擎将不同的业务逻辑编排在一起,形成一个有效的业务流程,比如预约流程。然后将这样的业务流程封装成一个个可执行的服务,将这一层称之为“API”层。

        API,顾名思义,未来所有新的应用可以基于API进行开发。从IT市场上不难发现,大部分的IT大企业们都会提供各种各样的服务层,这些服务有基于Webservice的,也有基于RESTful的,比如亚马逊AWS、Google Cloud、微软Azure、微软Office 365、Saleforce、阿里的中台、微信小程序等。所有这些IT企业的一个共同特点就是将企业的IT资源以服务的形式开放出来供第三方使用。这种方式不仅可以降低本企业创新的成本,还可以建立一套围绕着企业本身数字资源的生态体系。

        生态的构建需要标准。之所以亚马逊AWS能够构建其云计算的生态体系,是它的市场地位决定的,从而形成了云计算平台服务的事实标准。在中国,医疗信息化还是一个“群雄逐鹿”的时代,为了实现应用能无缝地嵌入到医院生态体系中,需要完善的标准来支撑。比如预约服务,如果所有厂商提供的预约服务是标准的,那么不管预约的应用是由哪个厂商开发,都可以很容易地嵌入到平台中,而不用担心底层的预约流程是如何实现的。

        这一问题也一直困扰着全世界的HIT市场,而HL7 FHIR的出现就是为了解决这一问题。FHIR定义了医疗领域的各种资源,比如患者、就诊、检查、观察、用药、医嘱等,并通过RESTful的API将这些资源开放出来。未来的应用只要满足标准的FHIR API,都可以很容易地嵌入到医院的信息化生态中。由于篇幅原因,这里就不展开FHIR标准的相关探讨。

【小结】

        “中台”是一个概念,和亚马逊AWS、微信小程序等一样,其核心思想是将组织内部的资源进行统一管理和抽象,并开放给最终用户或合作伙伴。而不管是内部用户还是外部客户,最终将形成围绕着组织核心资源的生态体系。通过这样的方式,可以大大降低应用的开发成本,这是值得医院信息化建设借鉴之处。 “中台”的构建是一个系统工程,需要考虑行业开放的平台的标准支撑,FHIR提供了这样的机会和技术的可能。如何利用FHIR构建医疗信息化的“中台”,后续有机会和大家分享。


点击这里给我发消息
点击这里给我发消息