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