探讨卫生信息标准化工作

dyy

卫生信息化的基础是医院信息化，由于医院自身信息化建设的发展以及医保体系建设和公共卫生体系建设的不断深入，医院信息标准化工作一直都备受关注。
2002年卫生部组织制定并发布了《医院信息系统基本功能规范》，试图通过描述现阶段商品化医院信息系统必须达到的基本要求，为卫生部信息化工作领导小组评审医院信息系统提供一个基本依据，同时也可用于评价各级医院信息化建设程度的基本标准。
但由于该功能规范在功能划分和描述上仍然没有打破已有HIS系统的局限，没有在业务层面上建立起一个统一的信息模型，因此在指导各个厂商开发信息系统和各级医院进行信息化建设方面只是起到了参考作用。
由于功能规范过于笼统，2003年卫生部组织制定《医院信息最小标准数据集》，试图通过描述医院信息系统的基本数据项来规范系统的实现和系统间的交互。
但任何标准都面临着扩展性和约束性两方面的难题，扩展性好则可以更好的适应实际需求但也就难以验证，约束性好则可以有效的验证但也就不能更好的适应实际需求。
该标准数据集也同样面临着这个两难的问题，因此虽然还没有完成，但对于其实用性已有很多争议。
由于认识到在卫生信息标准方面与国外发达国家有较大差距，2004年卫生部启动了《国家卫生信息标准基础框架》，试图从根本上建立各个领域各个层面的卫生信息模型。
由于这是一个基础框架，因此医院信息模型也和其他卫生信息标准一样属于该框架下的一个部分，但该框架并不具体定义该医院信息模型。

HL7标准经过十几年的广泛应用，在标准制定和系统开发方面都积累了大量的经验，与此同时，信息技术也取得了巨大的进步，从“面向过程”到“面向对象”到“面向服务”，从“中间件”到“模型驱动开发”，HL7标准3.0版也从根本上改变了原先的标准开发方式，而是采用系统建模的方式通过建立一个统一的医院信息模型来规范医院信息系统间的交互。
这个医院信息模型的基础是HL7定义的数据类型（DATA TYPE）和参考信息模型（RIM），各个国家或地区可以在此基础上针对各个领域模型（D－MIM以及R－MIM）进行本地化和细化，并制定出系统间交互的接口消息。
虽然HL7本身主要是规范系统间交互的接口，但这个本地化和细化的领域模型也可以作为实际系统开发的架构设计。

国内医院信息化建设目前已经到了一个升级换代的关键时期，HIS厂商面临着从项目化开发向产品化开发的转变，医院信息化面临着从简单医院管理向综合医院管理以及临床医疗管理的转变，区域医疗信息化也随着医保体系和公共卫生体系的要求而逐步深入。
现有的HIS大都是从部门信息化发展起来的，对于医院各个部门各个应用在业务层面上缺乏整体的架构设计，即医院信息模型。这一模型是与具体厂商的实现系统无关，并且与具体医院的业务流程无关。由于缺乏这一模型，各个厂商的实现系统大都存在着较大局限，并且不同系统间很难互连。
因此当前卫生信息标准化的关键在于建立这个医院信息模型，即在HL7定义的数据类型（DATA TYPE）和参考信息模型（RIM）的基础上针对各个领域模型（D－MIM以及R－MIM）进行本地化和细化，并制定出系统间交互的接口消息。
1，完全掌握HL7定义的数据类型（DATA TYPE）和参考信息模型（RIM），理解各个领域模型（D－MIM以及R－MIM）。
2，在卫生部功能规范和最小数据集的基础上，划分各个应用领域，开发相应的信息模型，该模型可用于指导HIS厂商的系统开发。
3，在各个信息模型的基础上，开发相应的接口规范（包括消息定义和消息实现），该规范可用于指导不同HIS厂商的系统互连。

dyy

HL7V3是什么？
是接口标准，更是一个信息模型！
MDA是软件开发的发展方向，而HL7就定义了一个医疗行业的PIM。
随着MDA技术和工具的发展，HL7作为信息模型的价值将越来越明显。

cfc2004

深有同感，向第一楼学习，不知如何与您取得联系？

dyy

信息化需要建立共同参考模型 建议书
居德华教授 上海亚士帝信息工程公司 CEO IEEE Software 工业顾问
最近两周内, 我连续参加几个电子政务和商务平台项目的验收和鉴定工作,看到好几个企业都在利用自身积累的技术和经验做相关的开发平台,以提高共性内容的可复用性,加快开发周期和降低开发成本,可以说各家都各有千秋和特色,如几家都按需要开发了工作流引擎，但恰好也给我造成有重复投资和开发的感觉,虽然一定程度的重复还是有必要和不可避免的,但问题是如何能形成合力,争取提高投资效率和产出水平。
在参与的评审项目中，各家为包装自己的成果，也都不约而同地用上了诸如“框架”和“平台”等字眼， 希望能有所“拔高”，但仔细一追问，发现都很表面，没有实质性内容，最多分几个常见的层次结构，按理框架和平台，将给用户提供一个清晰的概念模型和方法论， 使用户能方便地了解如何能有效地应用这些研究成果，但这几个项目恰恰在这些方面还存在明显缺陷，外来的用户很难学习和应用这些成果，结果只有开发者自己才能熟悉它的好处和应用，因此，离产品化道路还有一段距离，这是我比较明显的一点感触。
我感觉的另一个重要问题是，如果各家都按自己经验和认识，各搞一套的话，虽然对自己所属范围内的开发有好处，但由于缺乏共同的参考模型和标准，将来不同家开发的系统要互联就会很困难，因为各家采用的是不同的语言和套路，这一点恰好违犯互联网应用的大忌。在国外，几乎从一开始就已注意这一重要问题，研究和提出了一些共同的参考模型和开发标准，以方便和保证将来的互通互联，所以当谈及应用框架时，我有个强烈的感觉，我们是到一个关键时刻了，中国的信息化有必要现在就着手研究和建立自己的参考模型和应用框架，也只有提升到这一更高层次，才能指导我们的厂商开发出更高质量和更有实用价值的平台产品，但当我与开发商商讨这一问题时，每一家都感到很有必要，但又无能为力，因为这需要更高层次的协调和联合行动才能做到，才能把各家的长处捏在一起，才能迫使规范化的实施，而在国外，这也正是靠政府机构、重要的国际机构和工业联合体，才能把各方面的专家集合在一起，完成这项有意义的工作，这就使我感到有必要向领导部门提出这一建议和呼吁的原因，即使我们现在暂时无力推动建立全国范围的标准或参考模型，我们至少可先从上海一个城市范围做起，其实国外有些电子政务参考模型，也是从一个部门或一个地区政府提出的，如美国的国防部、财政部，美国的康涅狄格州和加拿大的安大略省等，下面我还会简略地介绍这方面的情况，对上海，我们已成立市信息化专家委员会多年，正好利用这一专家力量，同时我想建立共同的参考模型，也理所当然应是这一专家委员会的职责。
最近， 我恰好也在为《科教兴市》行动计划，在从事《CTO知识体系》和《新产品开发知识体系》的调查研究工作，另外我也饶有兴趣研究信息化人才的《知识体系》工作，我曾就这些内容，向市领导提出过相关的建议，利用我们自己的优势和技术长处，也已开发出一批《信息化高级教程》，共有 73M
和2600 多 .ppt 页面的内容，反映了现代信息技术和应用的趋势，适合高层次信息化人才的培养，在调研的过程中，我们发现国外先进国家非常重视信息化参考模型和应用框架的研究和建设，已开发出不少有价值的成果可以借鉴，鉴于这一内容的重要性，我们也已把它们收集在我们的教材之中，为配合这一建议，我们也已在我们的《IT之源》技术资源网站，增设了《信息化参考模型》的专栏，推动这方面的技术传播。
下面我简要地介绍一下，国外在这一领域的发展情况和动态。其实，无论在电子商务或电子政务领域， 都已提出了一些有非常重要影响的参考模型和应用框架，如在电子商务和企业应用领域有：著名的Zachman 框架，John Zachman 是原IBM 的高级专家，美国康州信息部门 (DoIT) 提出的 EWTA/EWITA （Enterprise-Wide Technical Architecture）, 美国联邦政府提出的 Federal Enterprise Architecture (FEA) 及其框架 FEAF，后两者也兼顾电子政务领域，其它重要的参考模型还有OPEN GROUP 的 TOGAF，去年年底刚推出企业版第8版，NCR 的企业架构框架和DSDM 框架，ISO的开放分布处理参考模型ISO RM-ODP, ISO 15704Generalized Enterprise Reference Architecture and Methodologies (GERAM) 等；在电子政务与公共服务领域， 有联合国安 UN/CEFACT 提出的 通用模型方法UMM，它还参与了电子商务XML ebXML 的开发，加拿大政府的战略参考模型 （GSRM）、城市参考模型MRM、公共服务参考模型 PSRM， 美国国防部的 DOD 结构框架 DODAF 和C4ISR，美国财政部的企业架构框架TEAF等，从软件开发技术角度，未来的主流技术将是OMG 的模型驱动结构MDA。
面对国际上如此众多的技术成果和进展，我们有必要组织力量，进行认真研究消化，吸取众家之长，同时结合中国实际，发展建立自己可用的信息化参考模型，同时设法兼容国际标准，以便促进与国际商务的合作和互联。
希望此项建议能引起有关领导部门的重视，并组织力量，采取及时行动，我们也愿意为此提供我们力所能及的贡献。

cfc2004

对于信息化参考模型与应用框架是否能给予一个更明确的解释？

dyy

刚从广州参加卫生信息化大会回来，所以回复慢了一些，这次会议论文集中有四医大的两篇和北医大的两篇论文都谈到了模型标准。

技术的发展实在是太快了，各种术语层出不穷，而且随着技术的发展，各种术语也有变化，更何况不同的人针对不同的研究方向，对于术语的理解也会有不同。
我只是说说我在目前项目中的理解：
按照MDA的概念，模型分为4层，M3、M2、M1、M0，上一层对于下一层来说就是一个参考模型，而M0层对于具体系统来说也是一个参考模型。
应用框架在我们的项目中是指M0层的模型开发工具，即通过导入M0层的参考模型，自动实现一个完整的应用系统。

jhs1

希望有进一步的讨论

dyy

这个话题确实是太大了，所以我也快把它遗忘了。
随着技术的发展，标准本身的内容、形式和意义也在发生着变化。这个标准指的是信息系统所使用的标准。
　　参照下述引用“设想由“企业的人”清晰准确地描述它们需要的企业（部分的），然后这些需求或构想被反映在它们面对的企业信息系统
中——这可以有很多种不同程度的实现方式或层次，以下四种可能是最典型和重要的：
　　1）形成书面叙述文件，交给软件开发者去进一步设计实现。
　　2）形成严谨的叙述文件，可能某种程度（部分）电脑可解释的，令其精确地限定整个开发过程和结果。
　　3）形成完全电脑可解释的模型，自动生成代码。
　　4）形成电脑可执行的模型，基于通用的平台，直接形成面对用户的“功能”。”
    则标准的变化也大致如此。
    又说了一堆空话，标准是多层次、多方面的，也许我们可以暂时脱离具体的某个编程实现所需要的接口方法，脱离具体的某个业务操作所需要的编码或规则，来考虑一下系统的整体规划。
    在这方面，我觉得“功能规范”虽然比较粗，但还是很有意义的。

dyy

说点实际的，HIS缺标准是人所共知的，不谈那些编码标准，当然那是最基础的，只说应用接口。
功能规范也有三年了，HL7也始终没有用起来，最小数据集我猜想是借鉴了英国的CMDS（纯属臆测）。
虽然我们作不了什么，但深入地探讨一番也许会有些触发。
我觉得应用接口应该是基于流程的，而功能规范是按照系统模块划分的，HL7V3中提出了应用角色的概念，所以系统模块可以按照所支持的流程活动来声明应用角色。
那么这个流程分析就是最重要的了。
HL7是按照流程来分析的，它包括了管理和医疗两个大域，管理域中又分为患者管理、人员管理、收费管理、保险管理，医疗域中又分为药品、电子病案、检验、血库等多条业务流。

HIS功能规范是按照部门和职责来分析的，它包括了挂号、门诊医生、门诊收费、病人咨询、住院管理、住院医生、住院收费、护士、手术麻醉、血库、设备、物资、药品、财务、病案、管理统计、医疗统计、医保、社区、远程、LIS、PACS等22个子系统。

业务流是一个抽象的工作流，包括一组活动及它们的相互顺序关系，还包括流程及活动的启动和终止条件，以及对每个活动的描述。

在分析的时候可以从部门和职责入手，最终抽象出一个个的业务流程，这也就是一般和特殊的关系。

palmerston

继续，学习中。。。。。

dyy

HL7不适用？不好用？那么它是什么地方不适用？什么地方不好用？

我感觉对于HL7的研究应该先把它的流程搞清楚，流程中串起一个个相对独立的活动（事件），活动中包括了一个个对象（消息中的各个结构）。

流程、活动、对象、      词汇表、     技术实现。
段落、句、  字词的name、字词的value、语法。

如果我们暂时忘掉HL7那相对简单的通讯机制和烦杂的串结构，那毕竟只是一种技术实现，相当于一种语法，虽然它很通用，但技术的发展是最快的，而且技术实现总是可以作到的，不同技术实现之间的转换对接也是容易作到的。

如果我们暂时忘掉HL7那几百个HL7定义的或引用的词汇表，那毕竟是相对明确的，相当于一些语义集合，虽然它很基础。

如果我们不是象最小数据集那样笼统的对待接口中所包含的信息项（作为臆测举例而已，最小数据集的开发方向和开发方法我不清楚，说错还请原谅），也不是象HL7V2那样孤立的对待某一接口某一位置的信息项，而是象HL7V3那样以RIM为基础构造一个对象集合，或者象CMDS也有一个对象集合（好像是这样，有待查证）。则我们对于我们所要表达的内容就可以有更准确、更具扩展性的组织。

如果我们连我们所要表达的内容也先暂时忘掉，因为我们说话所要表达的内容是很重要，但之前为什么要说也是必须首先要搞清楚的，这就是活动，或者叫事件，我理解它是用例（什么是用例是很容易引起争论的，我取用例是完成一项具体功能，代表一种场景）。

为了保证我们思路说话的连贯性，不至于颠三倒四胡言乱语，所以活动是必须串成流程的，每句话都表达了一种意思，但一句话是说不清楚的，所以要认真组织段落，使它能够表达我们的中心思想。

各个段落之间是要有衔接的，各个段落会有交错，医院是复杂的，中心思想也有很多，如病人为中心、人员为中心、收费为中心、药品为中心、医嘱为中心、经济核算为中心、医疗质量为中心、教学科研为中心、等等。

我理解作文章是从大处着手，逐步求精，象医院信息化这样大的文章，更是需要统筹规划，分工实施。而且这篇文章我们也作了很多年了，虽然还有很多不了解的，但毕竟已经了解了很多。而且还有外行业或国外的类似文章可以参考，甚至可以引进一些枪手来帮助。

dyy

关于段落之间的衔接，也就是各业务流之间的交互，两个业务流之间至少要有一对交互点，即一个业务流中附加了另一个业务流中的一个活动，对这个业务流来说这个附加的活动就是一个出口点，对另一个业务流来说这个本来的活动就是一个入口点。
各个业务流本身是相对稳定的，多变的是业务流之间的交互。RIM所包含的4个状态图（实体、角色、参与、活动）就是单个业务流的抽象表达。

看医生就要交钱，看医生是一个业务流，以病人为中心，交钱是一个业务流，以收费为中心，病人的入出转不会有太多变化，收费退费也不会有太多变化，但是看病什么时候交钱就会有很多变化，预约时交？挂号时交？就诊时交？就诊后交？一次性交？分批交？批量交？
应用系统要适应这些变化就有多种方式，固定一种交互，如产品模式和定制模式；修改代码，如二次开发模式；预先准备多个版本，如构件模式；修改参数或模型，如参数配置模式和模型驱动模式。
关于这六种模式：
管理软件的生产模式大致可以分为三个阶段六种模式，标准产品模式和完全项目模式为第一代，二次开发模式和参数配置模式为第二代，构件装配模式和模型驱动模式为第三代。目前的管理软件生产模式以第二代为主，但已经开始逐步向第三代演化了。
原文出在http://xjcxp.mblogger.cn/，这是一个个人网志，虽然都是些只言片语，但很有些有价值的东西。

回到标准上来，如果能够搞出一个《医院信息系统流程规范》，按照各个业务流分章节，定义清楚每个业务流中所包含的活动，该活动所实现的功能，该活动的输入输出所包含的业务对象。我觉得这是对功能规范的一个发展。
当然这个业务对象的定义是需要跨流程的，这本身也是一件艰巨的工作。我觉得这是对最小数据集的一个发展。

各个厂商可以测试并声明各自产品所实现的流程活动，这个测试声明也可以由权威或中立机构来作。
各个医院可以按照各个厂商产品所声明的流程活动进行组合，这个组合从理论上可以是流程间的，也可以是流程内的。

当然，上述都是理想化的，实际作起来会有诸多问题。
如果按流程间整合，则医院部门职能是跨流程的，必然出现一项工作要使用多个系统，界面整合就有需求了，看来要用上CCOW了。
如果按流程内整合，则可能是每个活动都要提供外部接口，这样作系统也太累了，不大现实。
如果这些都不算什么，那么以前暂时忘掉的词汇表和技术实现的问题也是无法回避的。
难！难！难！

但是再难，这件事情也是要作的，问题是永远不会自动解决的。
没有标准，各厂商产品很难集成，迫使各老厂商、新厂商、大厂商、小厂商都作大而全的或小而全的，就有了低水平重复。
其实，就算按照理想化的来作，虽然对于系统集成的最终目标实现不了，但对于业务模型的共享至少是可以实现的。
按照MDA的4层模型，不是M3到M0，那是另外一个维度的：
CIM计算无关模型
PIM平台无关模型
PSM平台相关模型
最底层是系统实现（这个我记不清楚了，有兴趣可以去上面的连接查原文，我没见过OMG的原文）

所以我认为流程规范＋业务对象＋词汇表，虽然并不能够真正实现系统集成，但已经作到了平台无关模型，可以对各厂商的需求分析提供极大的帮助，对于医院的业务流程管理也具有一定的指导意义。

jhs1

谢谢！

Mr Hd

可以到 http://www.chiss.org.cn 的论坛看看.

dyy

业务对象不是OO对象

在OO中，对象也就是类或者类实例，其内部仍然是面向过程的，由一些变量和方法组成。
在业务分析中，业务对象相当于OO对象中的变量，业务活动相当于OO对象中的方法。
在业务分析中，与OO对象相对应的应该是更高层次的服务。

但是，业务对象又是OO对象，业务活动也是OO对象。
在业务分析中，可以用OO方法分析业务对象，但是这和业务活动无关。
在业务分析中，可以用OO方法分析业务活动，但是这和业务对象无关。
只是在业务活动中要使用业务对象。