医院信息化-5 集成平台和数据中心

1 集成平台

1.1 技术上为什么要集成平台

我们抛开评级等因素，单单聊一下为什么医院需要集成平台。
首先什么是集成平台？集成平台是一个支持系统之间集成的软件平台，说到底就是连接两个或更多的应用程序。因为如果系统与系统之间的连接是点对点的话，那么会造成一个问题就是随着系统增加，系统之间的连接就会成几何数增长；解决的办法就是使用一个总线，将系统提供的数据以服务或者消息队列的方式发给总线，由总线管理和提供给其它系统使用。

1.2 集成平台包括什么

一个集成平台负责联通各个系统，而各个系统数据标准不统一，采用技术框架有不一致，因此需要具备以下的功能（当然还要评级必备功能）：
在这里插入图片描述

1.2.1 ESB（服务总线）

集成平台需要做联通，就需要消息交互，而用于集成平台使用消息交互就是ESB，这个在金融、工业等传统行业都有大量成熟案例。

1.2.2 IE（集成引擎）

由于各个系统统数据标准不统一，采用技术框架有不一致，在实施过程中，我们需要对接这些技术框架不一致的系统，那么需要一个能可视化、快速的配置引擎，以便我们能简单的落地规范和接口

1.2.3 ETL工具

在医院内部可能存在一些必要的数据但是之前并非有交互，这些数据存在某些系统之中，而在做互联互通过程中，可能需要将数据采集出来，那么就需要做必要的数据采集。

1.2.4 患者主索引EMPI

一个患者在就诊过程中，会使用到很多信息化系统，而将一大串流程串联起来的就是这个患者主索引EMPI。它包括：主索引生成、主索引合并与拆分、主索引同步及后台管理等。实施步骤包括：

这部分功能大都用于门诊、住院的登记系统，需要做的是先将旧数据全部归并后通过一定规则（身份证、姓名、性别等信息）做主索引生成，对于无法通过机器辨认的可以通过人工标记。
将与门诊和住院做登记系统通过集成平台做交互，以便生成新的患者EMPI。
提供给其它系统如LIS、PACS等患者EMPI信息，这样就可以将所有系统的主索引匹配起来。

1.2.5 主数据MDM

系统之间的交互也好，数据应用也罢，这些都需要一个标准，那就是数据标准，比如性别、字典等，在各个系统建设过程中会导致千奇百怪，而这时候需要将规范化的数据做好标准，以便能让系统之间更好的交互。主数据包括：领域定义、实体定义、字典管理、数据映射、数据发布、版本管理、发布与订阅等。实施步骤包括：

梳理医院内部使用的主数据包括哪些？比如性别、诊断、检查项目、医嘱项目、药品等等
参照标准（国际标准或者国家标准）代码
映射，已在使用的系统可能并非按照统一标准定义，这时候既不改变原先系统数据，也不影响系统与其他系统交互，需要做好映射关系
颁布标准，在定义交互接口时，需要颁布统一规则和标准。

1.2.6 闭环管理

所谓的闭环就是能够通过系统化将医院各个流程做线上管理，同时通过线上管理发现问题，再去优化，形成一个良性的闭环。闭环管理包括：闭环总览、详情展现、闭环分析、节点分析、预警以及配置管理等功能。闭环的系统更多是一个数据采集后做数据分析的工具化，闭环更多要求是落地，在实施闭环落地步骤如下：

确定需要做的闭环要哪些？药品、手术、检查、检验等等
根据国家标准，医疗闭环包括哪些环节。
收集目前达到标准的信息化，如未完成或未达标的需要信息化改造
数据应用，将已完成数据展现并提供给医务处等管理运营部门分析

1.2.7 CDA共享文档

CDA是HL7中的一个关于临床文档的标准，全程是Clinical Document Architecture临床文档结构。临床文档的标准最终的目的是用于共享，也就是患者的医疗信息（特别是以前非结构化的病历文书）能够结构化共享。目前使用情况来看，这种初衷是好的，但是实施效果不高，而“互联互通”标准还继续包含这部分内容，导致医院在建设过程中还是需要做好这部分内容。CDA共享文档包括：CDA共享文档、CDA共享文档配置、共享文档服务、审计功能等。在实施过程中由如下步骤：

根据国家标准（55份文书）梳理各个文书所属信息系统
对比标准与现实系统中实现的文书差异（包括字段缺失或者文书缺失等不规范）
督促信息系统完成改造
文书采集，将文书通过集成平台采集到一起
统一展现提供给全息视图使用

1.2.8 单点登录

我们知道医院内部系统很多，包括C/S结构、B/S结构等都有，那么统一登录就不想很多互联网公司那么好做，当然底层技术还是一样，只不过更多的是考虑兼容一些浏览器和操作系统。单点登录包括：登录、用户管理、应用管理、权限管理、验证对接等。单点登录实施过程：

梳理接入系统的架构、要求的浏览器等信息
梳理用户信息（可采集医护人员工号等）
梳理登录方式（工号、手机等）
对接各个系统统一登录
完成统一门户配置

1.2.9 临床全息视图

什么是临床全息视图，就是可以以一个患者为中心，展现患者的全部信息，包括就诊记录、诊断、检查、检验、手术、用药等等信息，全方位了解一个患者多次就诊的情况。这部分可以让医生无需在多个系统之间来回切换就可以完成对患者历史就诊信息及当前就诊信息的概览，也同时能够提供多次就诊的一些指标比较、趋势图等信息。临床全息视图包括：患者列表、就诊信息、诊断信息、检查检验信息、医嘱信息、护理信息、时间轴、比对趋势图等。临床全息视图实施过程包括：

确认患者各项数据来源
通过集成平台，无论是消息交互、ETL抽取方式采集到数据中心来
配置展现
对接业务系统入口，展现临床全息视图

1.3 目前业内情况

从1.2中可以看出去，一个集成平台需要一个很好的基础平台和应用平台，大部分信息化厂商如东软、创业惠康、东华、医慧、卫宁健康等都是采用采购基础平台+自研应用平台，基础平台基本上采用ESB总线的模式，这部分国外比较成熟产品有：Orion、IBM、oracle、Intersystem、odin等。而信息化厂商基本上就是采用这些成熟的平台再自己研发上层应用。
基础平台：分为2种，一种是针对医疗做了很深入化的定制，如orion、odin、intersystem等，一种是纯ESB组件，如IBM、oracle。首先纯ESB组件有叫广泛的验证，且产品成熟的非常高，缺点就是需要自己做一些业务的配备；而定制化的ESB就需要时间验证，不过目前也有如orion这般成熟的软件。

1.4 如何构建集成平台

假如一个企业想从0开始打造自己的集成平台产品为医院服务，需要配对什么东西？我认为需要以下3个要素：
1）熟悉互联互通标准的业务团队，需要构建一个有过互联互通评级经验团队，该团队经常用于解读政策及同步政策。
2）基础平台选型，我们通过上面知道集成平台最主要就是ESB，那么采用成熟产品、开源改造、自研的哪一种？
3）落地实施经验，集成平台实施过程中，需要一些除了技术之外的实施技巧，这时候需要不断累积经验并形成很好的培训机制，这样形成一套完整的闭环来辅助系统的更新。
而其中关于集成平台的ESB建设选型问题，本人有幸亲身经历过一次，以下是各自方式优缺点供大家借鉴，大家可根据自身情况做选择：
方式产品优点缺点购买orion、odin1）产品成熟 2）研发时间短 3）人员投入少 4）可取得客户安心1）技术无法自主掌控 2）国家提出的国产化开源+自研muleESB、WSO21）技术自己掌握 2）核心组件成熟1）整体产品未经验证 2）需要投入较多研发人力完全自研1）技术自己完全掌握1）产品未经验证 2）需投入大量人力研发 3）研发周期长
比较可能的路线是：先购买–>开源+自研–>完全自研

1.5 新技术框架的集成平台

我们知道，其实不止医疗行业面对这种系统间交互问题，在这之前互联网、金融、工业等行业也面临这种问题，ESB服务总线这种方式其实目前在互联网行业已经被淘汰，而在金融和工业领域也进入淘汰阶段。那么为什么医疗行业还在建设中？我在第一个部分《医院信息化-1 信息系统概况》中的3.1 集成平台和《医院信息化-4 趋势与技术应用》的2.1 微服务中已经给出一些答案，总结如下：
1）医疗信息化相对落后，并且系统使用寿命较长，更新迭代比较慢
2）互联互通标准未做很好的技术更新，导致很多标准还是按照ESB方式设定，所以采用ESB更加容易实现
3）基础设施没有跟上
其实目前比较先进的就是微服务+云架构，通过以微服务划分领域，外加云基础提供微服务的基础设施（包括服务发现、网关、服务治理、可观测平台等设施）是未来医疗在集成平台的一个方向。需要的技术和时机在《医院信息化-4 趋势与技术应用》的2.1 微服务和2.5 云原生都有讲的，可以参照。

2 数据中心

数据中心到数据中台，其实最终的目标就是能让数据体现出价值，也就是数字化。但是数据中心和数据中台还是有一些不一样，有人说数据中台是一个较大的东西，数据中心是一个缩小版或者某些功能缺失的数据中台；如果从组件来说却是可以这么认为，但是其流程却大同小异（数据采集->数据清洗->数据计算->数据应用）。医院一般建立都叫数据中心，它确实不需要数据中台那么宏大，但数据从产生到应用再到反馈给业务改进的闭环还是不可少。

2.1 数据中心阶段

阿里数据中台建设理论中提到数据中台的4个阶段，我是比较认可
1）阶段一“有数据”：有数据其实就是需要保证数据产出的时效性，稳定性、数据质量的准确性。
2）阶段二“用数据”：实现数据普惠，同时能够不增加运维成本。
3）阶段三“管数据”：广泛使用数据基础上，实现各类安全管控能力。
4）阶段四“精数据”：数据业务化后，实现成本控制，达到降成本。
医院很多数据中心的建设其实一般停留在阶段一，部分到达阶段二，极个别能达到提阶段三，更别提阶段四。

2.2 医院数据中心现状

2.2.1 特点

医院数据特点有如下：

结构化的数据量总体不大，大部分表只是几万、几十万，极个别表达到百万、千万
非结构化数据量多，包括病历文书、影像等
数据增长较为稳定，有规律可循
数据应用大部分以报表形式，极个别需要科研才会有AI等技术介入
数据来源多，数据库种类多，大部分数据库都是付费，如oracle、sqlserver、db2等
大部分数据以年、季、月、天统计，实时数据较少 7）历史1~2月内的数据变更频繁

基于以上的数据特点，那么在医院在数据中心建设上的特点也就比较明显：

数据存储一般以关系型数据库为主（辅助一些文本和图像的存储，但大多没有这方面的应用要求则不会建立）
数据采集一般采用定时同步工具（kettle、datax、集成平台等），如遇到大部分数据库与数据湖采用同一数据库，则使用付费的准实时同步工具
数据应用，BI报表一般购买付费的如帆软等工具，少部分特殊应用（如影像识别、自然语言处理等）采用训练模型+厂商研发形式
并没有很好的形成数据集成平台和数据资产管理平台，大部分数据从采集到应用都是需要厂商数据工程师从零开始开发，除非采购一些较大的数据中心厂商（如数澜、滴普等厂商，但是他们在医院内部数据中心实例较少，因为他们布局更为广泛）
厂商在自己内部形成一定的底层数据和指标的复用，但是长期运维后会导致管理混乱
数据中心的基础数据模型在临床、运营有比较成熟模型（CDR、ODR），在科研方面就需要针对不同业务不同建设

2.2.2 数据中心业务架构

在这里插入图片描述
从上图可看：

先是从业务数据库采集数据到贴源数据湖中，这里保证数据的稳定性和准确性
部分贴源数据直接对接应用或者AI模型，直接应用。部分数据进入成熟的数据模型CDR、ODR、RDR
在DWD层就是CDR、ODR、RDR三大模型，其中CDR、ODR是比较成熟的数据模型，能涵盖大部分医院的医疗统计指标
数据应用层是针对医院特殊应用开发的数据层，可能是CDR、ODR、RDR模型中不能满足的
数据应用则包括：BI报表、闭环管理、患者全息视图、数据上报、影像识别等

2.2.3 数据中心技术架构

如果你看到以下技术架构就会很惊讶于它与我们熟悉的数据中台架构或者某些厂商画的技术架构相差甚远，没有数据集成平台、没有资产管理平台、没有云平台等等，但很遗憾告诉你，目前大部分医院内部的数据中心建设确实使用了如下架构，如果想了解互联网方式的数据中台，可参考我的《数据中台》专栏
在这里插入图片描述

为何是采用如上架构，我认为有以下几方面原因：
1）业务需求：大部分医院其实不采用大数据这一套（个别医院也会使用，但不多），医院内部数据的量还没有那么大，大部分可分析的数据都是结构化数据。另外如果有病历文书和影像的数据应用，则一般都是特殊化。比如病历文书的自然语言处理处理都是存储处理结果，影像都是离线训练或者实时使用模型，并没有需要存储。
2）业务搭建快：大部分需求要求实现较快出现效果，而大部分需求都是BI报表，那么从数据到应用要求简单化。这过程中大部分的数据开发平台或者数据资产管理平台都是在不断运维中完成，个别厂商有一些成熟的产品，可能会在这里面自己使用
3）运维成本：基于大数据、云平台、AI算法对于一个医院来说运维成本过高，技术支撑不够，所以一般很少采用。

2.3 数据中心建设实践

本段落主要描述实际建设医院数据中心过程中的一些主要难点，都是一些经验之谈。

2.3.1 业务难点

涉及厂商和系统繁多，因此一定要时时列出每一项任务与之对应的厂商和系统，既能作为分配标准也能作为推动列表
主数据，主数据看似选择一套标准即可，实则在选择标准和厂商系统做映射时，需要投入大量专业医疗人员参与。将各个目标罗列出来，让真正懂的如病案室、医务科等管理部门参与到标准制定中
数据质量，同步数据后，必须做数据质量，比如非空这种简单的质量判断，以及到业务级别的质量，比如年龄、诊断编码等等
数据模型，在医疗行业CDR、ODR都有一些国家的标准模型，可以用来参照加以改进。因为这些模型就是为了指标而生的，所以使用他们来做明细数据模型最适合不过。
数据管理，在整个数据运维过程中，一定要做好任务、指标、安全等方面的规范管理，并严格执行下去。如果有对应的集成开发平台和资产运营平台最好。

2.3.2 技术难点

数据同步，医院涉及的数据库种类繁多，特别有些需要准实时的同步，会带来较多的技术含量，曾经遇到过一个cache数据库（并不是我们理解的一个缓存数据库，而是国外医疗行业很常用的一个数据库）做实时同步，就无法使用CDC方式，最终还是只能通过业务的消息模式做到准实时同步
数据存储，关于使用传统数据库还是分布式数据库，主要看医院使用。大部分是不需要，但是如类似北京协和等大型医院，可能会自己使用hadoop。
数据仓库/数据集市：一般都是对应业务应用的数据模型，根据业务与需求一般采用关系型数据库、hive、clickhouse、elasticSearch。
数据计算：一般都是对应业务应用的数据模型，根据业务与需求一般采用关系型数据库、hive、clickhouse、elasticSearch分为批计算（mapreduce、hive、spark等）、流计算（flink、spark streaming、storm等）、在线查询（redis、tair、Hbase、clickhouse等）、即席分析（kylin、impala、clickhouse等）
数据应用：可根据业务不同选择不同方案，比如编程、报表工具或者某些自研的工具。

2.3.3 建设步骤

1）搭建自身数据中心平台，也就是将公司产品搭建在医院内部
2）同步梳理医院厂家、系统、数据库等情况
3）了解已有的数据报表或者数据分析等功能，梳理关键指标及对应的关键系统
4）与院方制定需要完成的内容（大部分是指标报表，极少部分可能涉及分析、计算、模型训练等）先后顺序
5）制定主数据标准，并做好映射
6）数据采集：有2种方式
一种：有成熟数据模型，比如医疗常见报表，那么按照成熟数据模型来，可以迅速搭建可视化应用
一种：没有成熟数据模型，比如科研、特殊AI训练等等，那么可以以业务为主，看看需要哪些数据
7）数据质量规则梳理，一般公司积累经验多时，在设置数据实体模型会引入已有的质量规则
8）确保输出数据与客户核对准确性，可能是原先在某些系统已有报表或者可人工统计，找出其中不准确原因，确保最终准确
9）数据治理：如果有成熟的机制或者工具那是最好，如果没有，则需要迅速搭建采集任务管理、指标管理、指标复用管理、数据模型管理等等流程以及工具。
10）深度数据开发，前面6-9的步骤主要是迅速完成如报表类的应用，在机器学习等复杂的特殊化的应用上面，需要定制开发，这部分内容可以同步进行。

2.4 新技术框架的数据中心

我们知道，在互联网行业，数据中台的建设引入了很多技术（可参考我的《数据中台》专栏）。那么在医疗行业中，哪些技术在未来几年内会迅速应用以及会应用在哪一方面，下面说说我的看法。

2.4.1 DataOps

DevOps是为了实现敏捷开发也好，为了适应微服务开发也罢，最终的目的就是能够高效地开发和运维。而DataOps也是一样。我们知道一个数据从生产到最终使用，中间会经过采集、清洗、计算、应用等步骤，而且还会建立一些中间数据模型。在这过程中会遇到很多困难点

复杂操作，在多个环境中重复操作。我们的数据开发人员可能在开发环境完成这一套后，在测试、预发、生产环境又要重新操作一遍，经常会出现错误。
开发环境和生产环境一致型问题。在开发环境和生产环境中经常会因为长期不维护或者操作不规范而导致环境不一致。

这些问题往往最终导致任务、数据、模型管理混乱，从而让数据开发变得低效，最终还不可用。那么DataOps的提出就是为了解决这些问题：

快速部署，能够将数据开发人员的工作结果在多个环境快速部署
运维：系统和应用程序的可扩展性、可用性、监控、恢复和可靠性。数据应用开发人员不必担心运维，可以专注于业务逻辑。
治理：数据的安全性、质量和完整性，包括审计和访问控制。所有数据都在一个支持多租户的安全环境中以连贯和受控的方式进行管理。
可用：用户应该能够选择他们想要用于数据开发和分析的工具，随时拿到他们可用的数据，并根据需要轻松开发和运行数据分析应用。应将对不同分析、ML、AI 框架的支持整合到系统中。
生产：通过调度和数据监控，可以轻松地将分析程序转换为生产应用，构建从数据抽取到数据分析的生产级数据流水线，并且数据应该易于使用并由系统管理。

那么在医疗行业建设数据中心已经有一段时间，而随着数据开发任务的增长，这部分需要会越来越强烈。当然实现一个DataOps平台需要很多技术支持，短期内医院不会一下子就完成，但是对于数据集成开发平台和数据资产运营平台的建设，将会是数据中心的一个建设点。

2.4.2 大数据

除了极个别大医院之外，单个医院的数据量还远远没有达到我们所说的大数据。因此该方面在医院内部普及起来比较困难。但是在医院外部却是另一番风景。医药、影像、临床辅助等，在集团性医院、区域性医院或者地区政府领导的拥有大量的中小型医院，却能够发挥较大的能量。而在医院内部，几方面的应用会是短期的重点：
1）科研，利用医院多年数据或者区域性数据对某些医疗模型的训练
2）影像识别
3）DRGs
4）临床决策系统

2.4.3 上云

企业上云是一个热门话题。那么未来短中期（3-7年）医疗上云可能吗？就目前来看，分为以下2种：
1）个体医院：可能性极低，除了极个别试验之外基本上不考虑上云。
2）区域医院：由国家或者地方政府推动，但是多数以私有云，并非公有云。
那么为什么医院上云这么困难，我觉得有以下几种原因：
1）技术。上云就需要打造云原生系统，不是你把系统搬上云就说上云完成。那么目前在国内医院内部系统中能够符合云原生的貌似还没有看到。
2）安全。数据安全在医疗行业很重要，很多医院领导宁愿牺牲功能技术的优越性，也要保证数据安全，因为数据泄露就等同于丢了乌纱帽。云上的数据泄露、数据丢失的新闻一直没有停止过，只能说现在云的安全性还没有达到要求。
3）成本。上云更便宜还是不上云更便宜，这个要不同案例做不同分析。但目前就医院内部系统上云这一部分来说，上云的成本反而会更高，因为你需要将系统全部改造一遍再上云，因此更多可能是等到换系统才考虑上云，那么可能是10年之后的事情，因此短中期内不太可能。
那么云原生在数据中心是否有用武之地？

政府组织的私有云数据中心，目前每个层级的卫健委都会建立数据中心，而数据通过医院层层上传汇总，这部分数据中心建设未来可能会上私有云
集团医院数据中心，由于某些医院包括多个分院，数据分散在各个分院中，当建立集团级数据中心时，会考虑私有云

2.5.3 人工智能

医疗行业最近几年已经开始使用人工智能作为利用数据价值的重要手段，未来在这方面都会有长足的发展。目前国内在人工智能这一块用的较多部分或者产品，这里可以列举一下：
1）医院内部系统：DRGs、临床决策系统、影像识别、智能服务（如导诊、问诊、咨询等）
2）科研项目
3）药品研发
4）医疗机器人（如智能假肢、手术机器人等）
我们从医院内部系统看看有哪些具体点应用
1）DRGs，这是近几年国家出台的一个医保计算方式，通过一些规则和查看患者病历来判断患者是否符合某些医保治疗。这里面困难点在于读取病历，这需要利用到自然语言处理。能够准确读取病历的信息，结合医保规则，既能做到事后病历质控，也能提前到事中、事前。
2）临床决策系统，它是一个临床辅助系统，在很长一段时间里，临床决策系统其实只是一个知识库。供医疗人员查阅，并通过一些简单结构化数据做部分规则判断。但是现在人工智能的自然语言处理能力、深度学习算法的落地，使得其能够更好的辅助医护人员，让更多原先无法落地的判断规则可以落地，这样在辅助方面就显得更为准确。
3）影像识别，影像就是检查的医疗影像。不太了解医疗的朋友可能不知道在医院有一帮叫做医技医师，他们并非医师，他们只是会看影像报告，并写出检查结果，但是不会下诊断。比如告诉你这个部位有一个肿块，什么形状，多大，可能是什么东西。这些能力在近几年逐渐出现AI识别，这归功于深度学习让图片识别能力得到质的飞跃。目前医疗的影像识别分得很细，不同部位不同疾病识别，还没有出现一个全方位的识别，这一方面是如果全方位计算量可能目前太大，另外就是精细化可以更加准确判断。
4）智能服务，这方面常见的应用在于智能机器人，可以线上导诊、问诊、咨询、人工客服等，相信ChatGPT的出现，会使得这一方面更为精进。利用ChatGPT进行二次规则训练后，在医疗智能服务这一方面可以有更大的提高。

3 总结

每个做集成平台和数据中心的厂商都有自身的优势，有的追求评级、有的追求低成本、有的追求技术。无论哪一种都会在其中找到生存需求。因此一个集成平台和数据中心如何做技术选型都是参照公司本身的优势和目标定制的，并无完美的答案，以上仅仅是个人在医疗行业的见闻，仅供参考，如有错误之处，望请慷慨指出。

标签： java 网络大数据

本文转载自: https://blog.csdn.net/linwu_2006_2006/article/details/129797582
版权归原作者 linmoo1986 所有，如有侵权，请联系我们删除。