1、医疗信息建模方法与开放式电子病历系统开发平台报告目录Contents医疗信息化需求和现状软件工程角度理论分析 临床业务建模开放电子病历平台的业务架构 开放电子病历平台的技术架构技术路径与愿景医疗信息化现状和需求目录医疗大数据政策 医疗数据特征临床电子病历问题 信息化需求医疗信息化愿景医疗信息化现状和需求医疗大数据政策2014年2015年9月2016年6月2017年1月2014年，国家卫计委制定国家卫生、计生资源整合顶层设计规划-“46312”工程2015年，关于促进大数据发展的行动纲要2016年，关于促进和规范健康医疗大数据应用发展的指导意见2017年，十三五全国人口健康信息化发展规划2018
2、年，国家健康医疗大数据标准、安全和服务管理办法（试行）2018年9月医疗信息化现状和需求医疗数据特征医疗数据的特医疗数据的特点点医疗大数据具备一般的大数据特征：规模大、结构多样、增长快速、价值巨大。另外作为医疗领域产生的数据具备医疗领域的特点：多态隐私时效冗余数据类型多样隐私泄漏风险时效性强重复数据医疗信息化现状和需求临床电子病历问题现状比现状比喻喻现在的医疗信息化系统好比是一座桥，桥上走的和跑的是患者，桥上 的石狮子、花纹等装饰是大数据、人工智能和物联网。院长们和领导 们喜欢看的，往往是桥上的华丽产物，却忽视了桥下的基础。桥下是 信息科和软件开发商的人在苦苦支撑，东修西补来维持桥梁的正常运
3、作。针对不断变化的临床业务需求，信息科的人对软件开发商怨声不 绝，而开发商也是苦不堪言，陷入恶性循环。创建一套拥有强大扩展 能力的富有弹性的信息化系统，成为解决问题的关键。非结构化真实性互联互通科研难或半结构化数据后补信息孤岛数据在厂家手中医疗信息化现状和需求医疗信息化愿景构建与供应商无关的，由临床专家主导的专科应用体系；减少信息化的重复投入和系统维护投入，增加需求响应速度和提高系统稳 定性；通过多方参与、共同运营临床模型仓库、医疗数据存储等服务，实现医疗 信息的标准化并互联互通。报告目录Contents医疗信息化需求和现状软件工程角度理论分析 临床业务建模开放电子病历平台的业务架构 开放电子
4、病历平台的技术架构 技术路径与愿景软件工程角度理论分析目录传统瀑布开发模式 迭代和敏捷模式 Luna模式软件工程角度理论分析传统瀑布式开发01需求调需求调研研02需求分需求分析析03系统设系统设计计04开发编开发编码码多次评多次评审审06系统上系统上线线05系统测系统测试试07系统维系统维护护软件工程角度理论分析传统瀑布式开发模式特模式特点点 强调文强调文档档前一个阶段的输出就是下一个阶段的输入，文档是阶段衔接的唯一信息接口。所以很多 开发人员好像是在开发文档，而不是开发软件，因为要到软件开发的后期，我们才可以 看到软件的“模样”。缺乏迭代与反缺乏迭代与反馈馈电子病历操作繁琐，医生在录入数据时
5、，难免会出现疲倦与懈怠，录入的数据的准确性 会存有疑问。不适合客户需求不断变化的软件开不适合客户需求不断变化的软件开发发“唯一不变的是用户变化的需求”，用户业务需求随着市场变化而改变，在软件初期的 设计时需求可能已经发生变化，而后期的需求更改成本是开始的10倍工作量。在过去的 医疗软件市场里，一方面市场带动需求变化，另一方面初期客户对需求描述不清楚，这 些客观因素都为瀑布模型的使用团队带来困难与障碍。软件工程角度理论分析迭代、敏捷开发01需需求求02设设计计03开开发发04测测试试05交付交付一一05交付交付二二05交付交付N01需需求求02设设计计03开开发发04测测试试第一迭代第一迭代期期
6、第二迭代第二迭代期期第第N 迭代迭代期期软件工程角度理论分析迭代、敏捷开发模式特模式特点点 敏捷就是敏捷就是“快快”可以适应目前社会的快节奏与变化的用户需求。客户参与开发过客户参与开发过程程以人为本，客户是软件的使用者，是业务领域的专家，没有客户的参与，开发者很难理 解客户的真实需求。“轻轻”文文档档强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主 体。迭代、小版迭代、小版本本对迭代的强调是缩短了整个软件版本的周期。软件工程角度理论分析开发模式对比项目项目敏捷开发敏捷开发传统开发传统开发用户需求迭代获取，通常由简到繁开发前获取详尽的需求变更成本较低高测试每次迭代编码
7、阶段完成后客户参与度高低开发人员要求技术技能、业务技能、沟通能力技术技能适合的项目规模小型或中型的软件大型的软件软件工程角度理论分析Luna开发模式的提出3管理工具2开发工具1开发模式信息化软件开发开销大响应临床业务变化速度慢 总体开发周期长需求沟通难度大技术和专业知识耦合性强痛点Luna根本上就是分层体系架构，将信息模型与业务模型分离根本上就是分层体系架构，将信息模型与业务模型分离。软件工程角度理论分析Luna开发模式的设计理念标准标准 OR 标准应用标准应用解决信息孤岛解决信息孤岛自由自由or约束约束不能支持完整数据互通的接口，单 层模式的系统（业务数据与数据库 一一对应的硬编码架构）都属
8、于信 息孤岛。系统将支持相关的标准互 联互通的接口。用一个例子来说明标准和应用的关系。电子邮 件系统有各种服务端、客户端应用，形态、功 能差异巨大，但大家遵循的SMTP标准协议。每个应用有不同的形态，同样的邮件（类比医 疗数据）用不同的客户端（类比不同的供应商 开发的系统），可以呈现不同的系统功能。自由与约束是辨证统一的。自由 的实现是以付出巨大代价为前提 的。现阶段的luna主要任务是顺 利走通开发流程，因而将约束数 据结构、控件类型、查询路径等。软件工程角度理论分析Luna的架构体系数据存储结构和软件底层组件如安全 审计等不随需求变化和知识更新而频 繁变动的部分抽象出来，构成Luna平 台
9、抽象的“底层”。底层架构组底层架构组件件临床业务模临床业务模型型“把临床医生放回了驾驶员的座位上”让 医务专业人员直接参与医疗软件中领域知 识层的设计，方便快捷地满足医务人员对 医疗数据的采集、存储、展示需求。Luna将传统需要重复性的人力密集型的工作，通过解释器加模式识别的方法自动生成，像文档生成、ORM、UI-generator等报告目录Contents医疗信息化需求和现状软件工程角度理论分析 临床业务建模开放电子病历平台的业务架构 开放电子病历平台的技术架构 技术路径与愿景临床业务建模CDML建模语言实验室检查临床业务建模抽象为临床概抽象为临床概念念根据临床术语抽象业务需求转为业务表转为
10、业务表单单生成前端可视、可操作表单Luna的临床领域建模语言CDML解决核心问题：解决核心问题：通过医务工作者易用的工具，输出的领域模型可读readable（同时具备人可读和机器可读）与医学数据集关联保证语义的完整与正确表达避免岐义临床知识可积累和复用，避免重复造轮子Luna建模过程：建模过程：临床业务需求开放Repository设置触发CDS关联Terminology构建临床模构建临床模型型根据模型仓库选取或新建模型临床业务建模Luna预期的临床领域模型仓库400+医疗领域模型基于OPENEHR的 全球智慧和临床 知识200+临床表单表达 90%覆盖产科业务报告目录Contents医疗信息化
11、需求和现状软件工程角度理论分析 临床业务建模开放电子病历平台的业务架构 开放电子病历平台的技术架构 技术路径与愿景开放电子病历平台的业务架构Luna业务架构示意图开放的医疗信息化解决方案构建区域化标准化体系数据标准：在一定范围内通用的标准（语言无关），包括分层模型标准、数 据共享标准；开发标准：涵盖从项目管理到测试发 布的过程；不约定相关的实现技术，以 适应新技术的应用。包括：应用是否应 该有标准，规范有什么功能（记录哪些 字段），有什么业务（逻辑关系），用 什么方式展示，用什么方式存储？开放电子病历平台的业务架构Luna业务组件示意图开放的医疗信息化解决方案项目管理模项目管理模式式将项目需求
12、、评审、开发、测试、上线固化为开发平台流程。完整的过程记录、自动文档生成、审批体系、版本回滚制度。Docker集成，通过容器构建测试、开发、生成环境。提供基础组提供基础组件件数据存储：结合SQL和文档数据 库的特点，保证数据检索效率和业 务变更的可扩展性。服务接口：设计通用的数据查询 语言实现任意数据粒度的数据查询 与共享，支持HL7 FHIR的资源接口 模式。权限与审计：统一的权限管理、电子签名、审计模块，作为院内基 础服务组件为其他模块服务。全局服务组件：临床决策模块、随访模块、事件告警模块，让传统 医疗信息系统支持智慧医疗。是一种临床业务建模 规范，紧密支持医疗 术语集保证临床意义 的准
13、确表达；是医疗信息化生态的 种子，如HTMLx之于 WEB生态。C D M LClinical Domain Model Language集项目管理、版本管 理、发布管理、模型 仓库对接等功能于一 体，符合临床使用习 惯，所见即所得式的 简单易操作界面。CD MStudi o建模工作平台共有库+私有库+大型 医院公开库+第三方专 业模板仓库等运营模 式，公共仓库模型预 期平均满足专业科室 应用80%的需求。C D M RClinical DomainModel Repository为解决信息孤岛，达 到任意粒度及其组合 的数据检索，提供一 种融合SQL+节点存储 优点的临床数据持久 层服务。C
14、 D P 服服务务临床数据存储服务开放电子病历平台的业务架构Luna业务组件组成报告目录Contents医疗信息化需求和现状软件工程角度理论分析 临床业务建模开放电子病历平台的业务架构 开放电子病历平台的技术架构 技术路径与愿景脚手架框架开源EHR服务商EHR服务商方法论基础重要存储方案后端框架医疗资源管理及共享 标准前端框架，也包括electron等开放电子病历平台的技术架构参考方案与技术栈领域与信息模型分领域与信息模型分离离临床领域建模：绑定医疗术语集，支持临床领域建模：绑定医疗术语集，支持LOINC、SNOMED、ICD.x信息模型：基础数据支持、数据关系支持、信息模型：基础数据支持、数
15、据关系支持、CDS表表 达式语言、统一查询语达式语言、统一查询语言言前后端分前后端分离离前端呈现：支持前端呈现：支持pc和移动端样和移动端样式式后端：在数据持久层上提供后端：在数据持久层上提供Rest层作为数据检索接层作为数据检索接口口组件式开组件式开发发后台组件：权限管理、审计管理、组织管理、后台组件：权限管理、审计管理、组织管理、模模 型管理、集成管型管理、集成管理理前端组件：表单组件、报表组件、路由组前端组件：表单组件、报表组件、路由组件件以模型为中心，自动生成持久层数据体系和以模型为中心，自动生成持久层数据体系和Rest 接口，结合表单编辑自动生成前端页接口，结合表单编辑自动生成前端页
16、面面自动化脚手自动化脚手架架开放电子病历平台的技术架构Luna总体架构逻辑示意图领域与信息 分层模型自动化脚手架组件式开发前后端分离开放电子病历平台的技术架构Rest 接口服务层Restful共享接口管共享接口管理理根据数据集成要求通过模型选择元素，设计数据查询条件和相关的数据结构为第三方集成设置API key 自动生成接口和接口文档 设置接口CRUD权限接口访问可审计开放电子病历平台的技术架构持久层存储-ER图动态临床数据存储方动态临床数据存储方案案根据模型生成存储索引，无需变更 表结构。数据类型符合临床数据需求和数据 分析需要。开放电子病历平台的技术架构安全基础组安全基础组件件数据安全是医
17、疗信息化的前提条件架构提供数据库安全、传输安全、角色权限 管理、审查管理的基础功能组件Luna的相关技术可视化建模工可视化建模工具具计划开发面向领域专家的所见即所得的数据应用模板编辑器，能提供简单易用的可视化 编辑界面，由领域专家以所见即所得的方式 编辑临床应用模板文件。医疗前端组医疗前端组件件通过数据绑定技术栈，隐藏掉平台的差异，实现跨平台，技术栈有非常好的伸缩性能，在水平和垂直 方面均有良好的扩展性。使用的工具有专业的团队或者社区提供持续 的技术支持统一查询语统一查询语言言通过临床模型或资源模型的数据查询语言可 生成任何粒度和结构的数据集，便于数据集 成和数据分析，将医疗数据掌握在医院自己
18、 手中。开放电子病历平台的技术架构Luna技术模块特点Bjson数据灵活扩展数据仓库可直连数据 分析平台数据驱数据驱动动应对数据类 型变更和数 据分析响应速度响应速度快快高性能高健高性能高健壮壮分层模型，各司其职自动化脚手架，减少 重复开发Spring Boot底层微服务架构前后端分离应对临床业 务快速更新应对单点故 障或难以水 平扩容报告目录Contents医疗信息化需求和现状软件工程角度理论分析 临床业务建模开放电子病历平台的业务架构 开放电子病历平台的技术架构 技术路径与愿景技术路径与愿景技术路径与愿景产科专科的实践FHIR支持支持业务模型业务模型技术路径与愿景前端效果展示主要功能：主要功能：专科医生工作站 续诊报导模式，自动提示新出报告 产科高危管理、产前筛查管理 检查套餐，异常检查数据提醒 CDS支持，临床路径支持谢谢
