论通用病历文档格式标准
论通用病历文档格式标准
南京都昌信息科技有限公司 袁永福 2016-11-21
本文首发于 http://www.hit180.com/23732.html
作者简介：
袁永福，男，南京东南大学毕业，微软MVP，南京都昌信息科技有限公司创始人，长期从事电子病历编辑器控件的研发和推广工作，其产品成为编辑器细分市场的第一品牌。
联系方式：手机:13337824178，电子邮箱：28348092@qq.com，通讯地址：南京市雨花台区软件大道106号2号楼702室。
简介
本文讨论了一种通用的病历文档格式标准M-DOM，试图为数据互联互通、CDR、EHR、大数据分析等重要应用打下坚实基础。希望能帮助实现整个HIT行业的病历数据互联互通。
行业痛点
数据不能互联互通，这是整个HIT行业的老大难问题。从过去、到现在乃至未来很长一段时间内都会困扰整个行业人士。大量的医疗机构消耗巨大的资金和精力来试图解决这个问题，失败多于成功。
有一些医疗机构斥巨资开始建设临床数据中心（CDR）；国家卫计委也在各种大会宣讲数据互联互通；而近期的互联网+医疗中很大一块也是在试图解决互联互通的问题。不过大家努力的效果是有待观察的。
围绕着数据互联互通，是各个HIT系统厂商、医疗机构、政府各方博弈。客观的来说，厂商作为中国HIT系统的主要承建者对数据互联互通是不够热心的；很多医院只希望院内互联互通而对院际互联互通缺乏热情；政府的操作手法又不接地气，孤掌难鸣。
病历文档，此处不仅包括住院病历，还包括门急诊病历、护理记录表单、各种检查检验报告单等等，是整个HIT系统中很重要的数据类型。各家厂商的病历文件格式又各不一样，而且有很多是加密的，第三方无法利用的。这些都增加了互联互通的难度。
不通则痛。由于广泛的弥漫性的数据不互联互通，这就导致了整个HIT行业的最大的痛点。
HL7的解决之道
对于数据互联互通，很多人寄希望于HL7，希望DICOM在影像领域中的成功模式复制到整个HIT行业。百度百科中是这样介绍HL7的：
HL7 卫生信息交换标准（Health Level 7），标准化的卫生信息传输协议，是医疗领域不同应用之间电子传输的协议。HL7汇集了不同厂商用来设计应用软件之间接口的标准格式，它将允许各个医疗机构在异构系统之间，进行数据交互。
HL7的主要应用领域是HIS/RIS，主要是规范HIS/RIS系统及其设备之间的通信，它涉及到病房和病人信息管理、化验系统、药房系统、放射系统、收费系统等各个方面。HL7的宗旨是开发和研制医院数据信息传输协议和标准，规范临床医学和管理信息格式，降低医院信息系统互连的成本，提高医院信息系统之间数据信息共享的程度。
对于HL7 第三版支持XML，也就是CDA，以下是一个CDA的范例：
HL7/CDA最大缺点是它合适数据的传输和交换，但不适合数据的存储，特别是病历数据的存储。因为CDA只包含自然语言文本字符串，不包含半结构化、文档格式、痕迹、权限控制、医学公式等信息；而这些都是一个完备的病历文档的必备内容。因此CDA难于胜任病历文档互联互通的重任，也难于用作精细化的病历文档大数据分析。
另外HIT厂商对于CDA也没有主动推动的热情，强扭的瓜不甜，CDA落地效果不好。
M-DOM的解决之道
我们的团队长期从事电子病历编辑器的研发和推广工作，已经为很多行业厂商提供配套产品和服务，立足行业的现状，结合自身的优势，借鉴相关国际标准，在此提出M-DOM的解决方案，来试图解决困扰整个行业的病历数据不互联互通的问题。
通用病历文档对象模型，Medical Document Object Model，简称M-DOM，是一种专门用于精确描述病历文档内容的软件设计模式。它利用一个个可编程实体映射到文档的各个部分，这些实体基本上按照树状结构组织在一起，各种实体类型之间存在派生关系，其他软件通过这些可编程实体来访问文档内容。M-DOM很多地方借鉴了W3C国际标准组织的DOM标准，而W3C-DOM是立场中立的，而且它的影响力是远超HL7的。
下图是M-DOM中各个实体对象实例的组织结构图：
下图是M-DOM中各个实体对象类型的派生关系图：
M-DOM不仅包含了文档数据的描述，还包含了一系列的编程接口的规范，这套规范也参考了W3C-DOM标准。比如以document作为访问M-DOM的唯一入口点、文档节点具有AppendChild(),RemoveChild()等成员函数等等。
定义统一的编程接口也具有重大现实意义。因为所有伟大的系统架构、设计思想最终都要落实到一个个编程接口。M-DOM定义了标准的编程接口规范，使得各个厂家开发出来的M-DOM产品具有相同的编程接口，使得开发者很容易在各个厂家的产品之间来回切换。另外无论开发者使用C#、JAVA、C++、VB、DELPHI、JAVASCRIPT、PB等编程语言，都能以相同的编程模式访问M-DOM。实现了软件开发手段上的互联互通。
综上，M-DOM可以总结为三要素：1.文档元素对象实例的组织结构；2.文档元素类型的派生结构；3.编程接口规范。
DOM是一种业界比较少用的软件设计模式，大多数人不是很理解DOM，因此这也增加了M-DOM的推广工作量。想详细了解DOM，可参考http://www.cnblogs.com/xdesigner/archive/2008/06/04/1213504.html或者http://www.w3.org/DOM/。
M-DOM的实际效果
目前M-DOM只在我们内部研发过程中使用。M-DOM是我们的DCWriter电子病历编辑器控件软件产品的主体思想，它支撑了DCWriter这五年来的高速发展，而且远没有到达瓶颈。
M-DOM的应用已经从最原先的住院文书扩展到护理文书、门急诊病历、医技报告单、护理量表、医嘱单类似的报表功能，甚至扩展到电子政务等其他行业。
实践证明，M-DOM具有强大的生命力。是一颗强大的心脏。
以下是使用我们软件产品的部分用户医院的分布图，里面标记了M-DOM作为幕后英雄默默运行的地点。
M-DOM的标准化
M-DOM是产生于应用实践中，前期是野蛮生长。我们正在进行修正和标准化来增强它的长久生命力。
M-DOM目前只在DCWriter产品中得到应用，需要开放出来，让更多的软件产品采用。大家可以在CDR中使用M-DOM作为核心标准，为CDR装上一颗强大的心脏；同时也可以将M-DOM用于描述EHR，提高区域卫生信息平台的执行力和生命力。
我们的工作预期是设计出一套精确的XSD模式，用于定义M-DOM文件格式，分为三个层次。以下是目前设计出的XSD的部分内容。
对于M-DOM Level1，只定义了最基本的功能，是必须满足的，如果不能满足则不能应用；Level2定义了一些常用的功能，主要是文档格式控制、文档内容描述等信息；Level3定义了完整的功能，是M-DOM的最全面的功能集合。
标准化的M-DOM支持很多HIT行业中的实际需求，包括：
- 常规文档内容样式，包括字体样式、图像、表格等等。
- 纯文本、半结构化、全结构化的病历文书。
- 医学矢量图标记、医学表达式。
- 国家健康数据集的引用。
- 跨文档的数据引用。
- 病历文档内容质控。
- 修改痕迹和三级权限控制。
- 电子签名。
- 其他功能等等，未来将有详细而精确的功能清单。
M-DOM的落地实现
一套规范标准的能否落地实现决定了它的实际应用价值，CDA不能广泛落地实现就导致了CDA的价值大打折扣。而M-DOM具有相当大的落地执行力。下图是M-DOM的落地实现原理图：
我们的DCWriter电子病历编辑器控件已经实现了M-DOM，经过五年多的辛苦而扎实的努力，我们使得很多HIT厂商采用DCWriter开发应用系统，目前业界已经存在大量的系统支持M-DOM，而且还不断有大大小小的HIT厂商加入这个生态圈。
一般的HTI厂商对互联互通是爱恨交织的，内心是矛盾的；为客户利益及同行合作应该是互联互通的，但考虑到自身小利益捆绑客户时却是封闭的。而我们都昌公司无论是从客户利益还是自身利益来说都是全力推进互联互通，而且我们推进这个工作时，尚未发现合作伙伴阻止。此时没人反对或使绊，剩下的就看我们的执行力了。
另外我们不是一个人在战斗，而是可以借助于这几百家具有研发推广功能力的HIT厂商的，他们的软件每部署到一家医院，M-DOM就开始默默的跑在这家医院中。可以靠谱的预见，这个过程再持续个三五年，中国大部分医院将运行着M-DOM，到时候M-DOM将成为一种事实上的行业标准。
另外这种互联互通在各个细分市场上是广泛的，合作厂商使用DCWriter开发出来的产品有电子病历、HIS、PASC、LIS、RIS、门急诊系统、护理系统、基础卫生平台系统等等。此时医院的各个子系统都采用M-DOM，可以实现跨厂商的病历数据的共享，这样医院建设CDR的难度大为降低。而医院的CDR就可以快速的将M-DOM原始文档或者转换为CDA文档后发送给HER或者政府的公共卫生信息平台。
当然还有未采用DCWriter的HIT厂商，对于他们的系统，只要他们能将病历数据导出为XML格式，而我们正在开发中的DCFW（都昌应用程序框架）就能快速灵活的将任意XML格式转换为M-DOM格式，最大化M-DOM的应用范围。
放眼整个HIT行业，我们的团队是非常小的，因此我们不敢好高骛远、频放大招。只能老老实实的写好每一行代码，服务好每一个客户。但是我们可以从微观层面的量变来引发宏观层面的质变，采用农村包围城市的策略，持续改进和推广M-DOM，在这块无人区中不断探索前进，希望能帮助实现整个HIT行业的病历数据互联互通。
posted on 2016-12-09 09:02 袁永福 电子病历，医疗信息化 阅读(3622) 评论(0) 编辑 收藏 举报
