医院信息平台建设的基础构建方法

ESB管理平台基本功能
配置管理
ESB核心引擎
系统配置 资源配置 服务配置 厂商配置 订阅配置
性能监控
安全和认证
日志分析
服务器性能监控
流量监控
消息监控
日志结果分析
协议转换
格式转换
消息映射
异常处理
临床数 据中心
EMR系统
获取病人信息
查询医技申请单功能 获取检查报告
服务注册
病人基本信息服务
医嘱费用服务
制定统一的数据模型标准和服务标准
各系统服务接口顺利改造是成功的一个重要因素 以信息科为主导，各厂商深入参与到流程的设计与开发是成功的 关键
P A G E 43
THANKS
在ESB平台上可以进行灵活的运行 时配置，迎合应用系统变化需求， 提高业务变化敏捷性
规范医院应用系统的医 疗服务标准
构建医院核心交换数据标准 统一系统服务接入规范
统一数据交换的数据模型
为未来应用奠定服务基 础
提升应用集成的技术水平 为未来的流程集成做好技术准备
服务发生变更能准确感知影响范围
Orion Health
想象中的数据交换示意图
LIS RIS
EMR
CPOE
ECG
其它系统
临床数据中心的建设目的
临床数据中心建设的目的
建设闭环的完整信息化临床体系
在整体架构规划的 基础上，避免数据 孤岛效应随着建设 深入进一步扩展
实现患者诊疗信息 的共享，改善信息 利用的便利性，支 持临床与科研
在量化管理的基础 上支持决策分析， 实现管理创新
InterSystems alk
数据集成的多元化操作
临床业务库
ODS
CDR
CUBE
临床业务系统整库复制
根据策略做数据清洗和数据 映射，转换，将数据转储到 ODS服务器
开启CDC功能，全量和增量 的方式部署，将数据转储到 CDR服务器
根据不同维度和度量值，通 过ETL的方式，来创建元数 据表
优化、增强业务信 息系统，在信息高 度共享的基础上， 加强流程节点管控， 实现院前、中、后 的全过程管理
临床数据中心示意图
临床数据中 心
数据架构
• 医院数据中心采用三层架构，即CDR数据实 体、数据仓库和数据集市
数据模型
• 第一层建模为CDR数据实体层： 参考HL7 RIM 模型把业务流程中的每一个活动事物所记录的 信息以及各种原始文档统一到CDR数据实体中， 形成各领域内的数据模型；
消息的重发和通知
根据配置的重试次数，消息发送失败时主 动进行重试 重试失败后，根据配置主动进行邮件，短 信通知
ESB
日志的监控和分析 任一服务执行完整的记录发起方， 调用方的执行结果
有效的区别发起方或执行方的错误原因 有效的查看数据交换成功过程中传递的业 务数据流
应用系统A
应用系统B
应用系统C
应用系统D
传统模式下的数据接口，无法形成标准的数据模型，每 个系统之间使用的数据规范不一致时，容易造成接口不 满足，需要二次开发的情况；同时，一旦接口有变化， 无法感知该接口的影响范围有多大
选择什么 样的数据 标准？
如何方便 的进行维 护管理？
服务执行 后的结果 如何进行 分析？
服务执行 的过程中 如何监控？
数据应用
• 通过解析处理，保证CDR数据的颗粒度足够 细；汇聚医疗活动中产生的所有过程性数据， 以便支撑对医疗过程的精细化管理
ESB的建设目的
服务规范
数据规范
集成规范
企业服务总线（ESB ） 在医疗行业的应用
以企业服务总线（ESB）的模式实 现SOA应用 通过ESB平台降低服务提供者和消 费者之间的耦合
灵活的部署方案 提供大数据量，低延迟的
数据复制
基于日志，无需改变当前 IT架构，对生产系统的影 响最小
全面的异构数据平台支持 提供集配置、管理和监控
于一体的图形化界面，管 理方便，易于操作
基于临床数据中心的ESB的建设
服务的配置和管理
方便的服务配置和接口管理 消息的同步和异步模式 图形化的调用趋势图和成功失败记录
智慧医疗
医院信息平台建设的基础构建方法
新医疗，新智慧
历史情况回溯及思考
过去医院数据的状况分析
系统数据孤立
各系统之间的信息相互独立，形成数据孤岛
数据无法统一 系统过于耦合
各系统之间的基础数据，如人，科室等相关信息，无法 形成统一，容易造成，多套系统切换，需要使用不同的 账号，不同的密码，业务数据标准不一致，无法形成有 效的数据交换
医技申请单服务
检查报告服务
服务目录
企业服务总线
服务注册
服务注册
服务注册
获取申请单
劢态路由服务 端点解析服务
特殊信息
HIS系统 病人基本信息功能 医嘱收费功能
加密系统（干保）
异常服务 线路服务
RIS系统
检验全过程信息
部分系统截图展示
后续思考
以面向服务的思路而非面向数据的思路建设基础平台
从应用集成向上提升到服务集成，而非向下成为数据集成