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

医院为何产生“中台”需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        在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构建医疗信息化的“中台”，后续有机会和大家分享。