一位医疗IT产品经理眼中的“中台”（1）

最近，很多媒体和厂商都谈到“中台”在医疗场景的应用。同时，关于医疗“中台”，网上也有不少质疑的声音。

医疗信息化领域的“中台”一般是指具备“中台”特征的新一代电子病历。很多文章讲“中台”，要么讲的肤浅，要么故弄玄虚，让广大医疗信息化从业者面对“中台”显得无所适从。甚至对“中台”增加了几分神秘感。

我作为一位医疗信息化产品经理，希望结合自身工作实际，从以下四个方面谈谈个人对于医疗“中台”的基本认识：1.为什么要上“中台”；2.“中台”上线前注意事项：业务、流程、数据标准化规范化；3.“中台”一些基础组件的设计介绍；4.“中台”技术方案特点与设计介绍。

为什么要上“中台”

1.推出“中台”解决方案的原因

1.1 内聚与耦合

说到医疗“中台”推出的原因就不得不提到内聚与耦合。内聚（Cohesion）是一个模块内部各成分之间相关联程度的度量。耦合（Coupling）是模块之间依赖程度的度量。内聚和耦合是密切相关的，与其他模块存在强耦合的模块通常意味着弱内聚，而强内聚的模块通常意味着与其它模块之间存在弱耦合。模块设计追求强内聚，弱耦合。软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。划分摸块的一个准则就是高内聚低耦合。（详见参考资料1）

但是目前，国内厂商前期在设计信息系统的时候，由于多方面的原因导致：基础组件耦合了太多个性化需求，以至于后续临床对信息化建设提出新需求时，或者监管要求有所变化时，新需求或者变化仍需要调用常用基础组件。由于之前软件设计没有采取结构化模块化思路基础组件耦合太多个性化需求。解耦的成本，远高于重新实施一套新系统的成本。为了响应需求或是变化只有把老系统废掉，重新组织人员实施一套全新的系统。为了大家理解这个过程，我用综合布线的例子来给介绍：综合布线的标准横平竖直遵守一定的规则来部署线缆。前期软件设计没遵守相应的规定，在布线的时候随意部署。当需要更换某一根线缆的时候发现所有的线缆已经打结成团了。到时候只能剪刀一剪换新线重新部署。“中台”思路就是在布线线缆的时候按照一定的规则去部署，以便于后续更新与维护。

为了让大家对基础组件耦合太多个性化需求有一个直观的了解，下面，笔者通过在工作中遇到的两个案例介绍，以便大家有个直观的认识。

案例一：体温单

图 1 体温单（截图来源：基础护理学第六版（人卫版）221页）

大多数医院信息系统住院护士工作站里面的体温单都如图1所示。一张体温单关联了脉搏、呼吸、血压、入量、出量、大便次数、体重、身高等多种属性，不同数据全部关联到一张体温单上。

这种表单的设计还停留在纸质时代设计思路，尽量在一张表单上关联更多的信息。信息化时代的产品经理也没考虑其背后的成因，直接把纸质表单电子化，却忽略了很重要的一点：电子化跟信息化是不能直接划等号的。

此处的关注点不仅仅是体温单，而是医疗信息系统里面涉及医疗数据录入、存储、查询模块设计。这个模块设计如何满足“中台”思路：能快速响应临床需求、同时做到结构化模块化。在传统设计当中无法满足未来一些应用场景。比如，CDSS（临床辅助决策系统）里面，涉及机器学习相关的某些对于患者处置措施的触发值是需要从生命体征模块抓取。

以脑卒中患者血糖管理为例：当血糖高于10.0mmol/L 时应该系统提醒医生给予降糖治疗，当血糖低于3.3mmol/L 时应该系统提醒医生尽快给予补糖治疗。当患者的血糖触发到阈值的时候，这个时候应该把患者血糖变化的可视化图形：血糖折线图作为附件以通知的形式推送给医生，让医生有个直观的认识，知道患者的血糖变化需要干预。

而现实当中，图1体温单包含了不同属性医疗数据，作为附件展示给医生，医生关注点是血糖本身？还是其他医疗数据呢？

当然，还有一种声音，通过集成平台去抓取一个数值弹框提醒医生。这种解决方案无法直观向医生展示血糖的动态变化趋势。医生还需要去查看血糖变化趋势。这样增加医生的工作量，时间长了医生就会弃用。

在患者转运交接（ISBAR）其中的A（Assessment）评估涉及的生命体征，按照互联互通的思路应该是：自动从生命体征模块里面抓取数据填充。然而，现实是系统无法自动获取数据填充，护士还需要手动再次录入生命体征数据。在某些场景手术恢复室内，麻醉医生和护士在同一时刻录入的患者生命体征数据都存在不一致的问题。

案例二：压疮不良事件上报

图 2 某家医院系统内压疮不良事件上报表单

图2是某家医院信息系统内不良事件上报表单截图。一张表单里面包含压疮评估以及对应处置措施，还有不良事件上报以及不良事件原因分析，而且数据和流程没有分开。这是典型的基础组件耦合太多个性化需求的例子。如果按照高内聚和低耦合的思路，这张表单其实涉及压疮评估、压疮护理、不良事件上报、不良事件原因分析这四部分的内容其实应该分开。每部分作为附件数据单独提交，流程和数据分开来实现相应的功能。传统的设计一旦需求有所变更那么表单甚至流程就需要重新设计，这样维护成本就增加了。 

到此，大家不必太多纠结这两个案例。我举例只是为了让大家对基础组件耦合太多个性化需求这个问题有一个全新认知。在后面第三篇文章—《“中台”一些基础组件设计》中，我会为大家详细介绍以“中台”思路如何解决这些问题。至此得出一个结论：推出“中台”解决方案的原因，是为了解决基础组件耦合太多个性化需求导致的系统无法升级和满足一些新的应用场景，而推出“中台”解决方案。

2.“中台”的定义与理解

2.1 “中台”定义

网络上对“中台”的定义：“中台”是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构），它存在的唯一目的就是更好地服务前台规模化创新，进而更好得响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。（详见参考资料2）

2.2 个人对”中台”（医疗）的理解

通过对医疗业务数据标准化规范化之后，按照一定规程设计常用基础组件，以便快速响应临床提出的新需求，以及监管部门对信息化要求，最终实现多业务数据之间的互联互通，降低开发与维护的成本。避免出现由于系统无法升级只能废掉的窘境。

当然，医疗“中台”不是个大染缸，什么都能往里面装。很多厂商设计的中台系统一个比一个复杂，总想着蛇吞象，什么都做，这样很容易消化不良。但真正考验一家公司或是产品经理能力的，是怎么在满足监管要求的前提下，把系统设计的简单，让一线医护人员能快速上手。系统简单，能快速上手，最终节省下来的时间对于医院来说也是一笔不小的成本。

2.3 “中台”与集成平台的关系

说到这里，可能会有信息科的朋友问：医院系统通过集成平台实现了互联互通，为何还需要“中台”？

这是因为，现有集成平台实现的互联互通，本质上是多系统中心点式的信息共享。它是一种中转式的互联互通。而医院最终想要实现的互联互通是一种跨多系统业务流程和数据自动化互联互通。集成平台是满足不了这个需求的。所以还是需要靠中台来实现。通过重新设计这些可以复用的基础组件来支持相关数据业务流程自动化，从而降低成本增加效率。

参考资料：

1.百度百科：高内聚低耦合（https://baike.baidu.com/item/%E9%AB%98%E5%86%85%E8%81%9A%E4%BD%8E%E8%80%A6%E5%90%88/5227009?fr=aladdin）

2.简书：白话中台战略-1开篇：中台是个什么鬼？

（https://www.jianshu.com/p/86dc7ad52ad6）

（未完待续）