受人之托，代为发布此贴
发布者按：
下面是一组有关化验报告结构化表达的讨论。背景是卫生部电子病历委员会(EHRSC)在最后正式发布该委员会制定的《电子病历委员会系统互操作性规范：
临床检验结果共享》六个系列文档中的最后一个《电子病历委员会系统互操作性规范组件：临床检验结果报告内容》的讨论。完整的文档草案可以从CHIMA网站（ http://www.chima.org.cn ）“资料中心”栏目“资料”框中的EHR Steering Committee POC工作组第三次工作会议资料“EHRSC IP完整文档包” 下载。
长期以来，大家都在抱怨我国医疗卫生信息化进程中标准化工作严重滞后，制约了信息化的发展。众所周知，新医改提出的建设居民电子健康档案的目标没有标准化的支持，就是空谈。卫生部近期公布了一系列有关的标准草案试行，可以感觉到标准化问题已经得到卫生部主管部门的高度重视，获得了长足进步。
对跨机构的居民电子健康档案系统的建设而言，标准化的核心是互操作性问题。而互操作性不是仅仅有了数据元素的标准就可以实现的。信息传输、信息结构化表达更为重要。标准化是一个大工程，关键是思路是否清晰、方法学、技术路线是否正确。EEHRSC经过二年的努力发展的这一套规范文档，虽然仅仅聚焦在化验结果在区域内共享的问题，但它涉及了互操作标准的各个层次，架构、传输、格式与内容，探索了一条正确的、也是必要的和可行的方法学与途径。
仅仅有化验结果共享规范当然远远不够。但这也是没有办法的事。因为EHRSC掌握的资源有限。所有参加此项工作的组织与个人都是业余的和没有报酬的志愿者。
从下面一组往来信件可以看出问题的复杂性与参与者认真的工作态度。即便是对国际上已有的标准，引进和消化，获得共同认识，也是一件不容易的事情。要付出时间、要涉猎海量的英文文献、要对我国的化验实际应用环境有深刻的理解，要认真的钻研与思考。学术上有高度、态度上要谦卑、学风上讲严谨。更不要说深厚的IT理论基础与丰富的医疗卫生信息系统的研发经验。全才是没有的，只能讲合作。因此还要有开诚布公、团结协作的团队精神。急躁、浮躁、急于求成和拔苗助长，是搞不出真正有用的东东的。
山外有山、天外有天，Miforum 是藏龙卧虎之地。“出入皆鸿儒、往来无白丁”，欢迎论坛的朋友积极参加到互操作标准制定的艰苦工作中来，共同学习、研究、讨论，于公于私，肯定会有收获的。
PaulLee
以下是近期EHRSC部分成员的往来Mails,按时间逆序排列：
大家好，
我觉得 LAB TF-3 是对检验报告使用CDA做了更严格的约束，特别是在 level-3 中给出了值域，完全没有改变CDA的数据元，如果根据 LAB TF-3 做我们的检验报告模型，回过头来再说CDA不能cover，就自相矛盾了。
LAB TF-3 2.3.5 Content Modules for CDA Entries (Level-3)的依据是“Result Event” RMIM from V3 Laboratory Domai。“Result Event” RMIM （POLB_RM004000）已经是准标准，肯定比依据 LAB TF-3 自己做的RMIN 完善，且不会出现CDA不能cover的情况。CDA的扩展部分的目的很明确，就是为了满足 POLB_RM004000 参考值表达的需要，即按条件（年龄、性别）列参考值，目的不是为了包含所谓不能cover的数据元。
如果我们用 POLB_RM004000 规范检验报告的语义，用CDA作为报告文档的交换格式，用 LAB TF-3 对检验报告CDA做严格约束，应该不会再有建议CDA扩展的问题。
同意鲍老师的意见：“我们扩充了的东西可能用CDA模型本身就能搞定”。
实际上，对于检验报告，CDA已经搞定了，LAB TF-3 只是给约束，不能作为建模依据。
不一定正确，仅供参考，谢谢！
徐勇勇
>From: "Bao, Yongjian (GE Healthcare)" <yongjian.bao@med.ge.com>
>Reply-To:
>To: "Min Li" <minli@cn.ibm.com>,"linforest" <linforest@163.com>
>Subject: Re:Electronic Medical Summary (e-MS) Project
>Date:Thu, 16 Jul 2009 22:12:00 -0400
>
各位，
我一直认真地follow各位的讨论，包括阅读IHE的Extension部分的文档。我们可以撇开扩充还是不扩充的概念性的讨论，而是具体讨论我们哪些地方没有顺从CDA R2, 这些地方是不是可以在CDA R2框架中解决问题。是因为我们对CDA R2理解不够，还是中国的特殊环境必须要扩充。例如IHE Lab文档中的报告StatusCode是不是要在Header ServiceEvent中列为可选项。如果我们选了，也是顺从了IHE的扩展，这是一个IHE对CDA R2的扩展，不是我们自己的扩展。实际上，即使没有这个扩展，利用CDA R2已有的文档版本号（VersionNumber）和文档SetId之类Attributes，也可以区分中间报告与最终报告。
最好没有我们自己的扩展，如果有，就必须有充分的理由，我们决定不了，可以咨询台湾的范士展秘书长。
李包罗
各位：
任何人可以在CDA XML文档中使用自己的命名空间。但是，这样做的后果是你告诉别人：这是我的CDA文档。
是的，IHE Lab定义了两处“扩充”：2.3.6.2给ObservationRange增加了和Criterion的Act关系，2.3.6.3在CDA Header的ServiceEvent中加入了StatusCode用以表达检验报告是否最终报告。两个扩充都是optional use。
使用了这两个扩充的检验报告，告诉别人：这是IHE Lab的CDA文档。潜在的风险是，不支持IHE的CDA文档parser可能会拒绝它。IHE的optional use给了规范实现者一个选择：如果你要最大化interoperability，你可以在产生文档时不使用这些扩充。
所以，用不用扩充取决于你对interoperability的预期。如果你认为你的扩充有足够的理由，你的规范有足够的影响（例如IHE），你又有计划将你的扩充递交给HL7，希望它们最终能成为CDA的一部分，那么，扩充是合理的。
就我们的具体情况而言，我觉得使用扩充要非常慎重，决不要因为可以扩充而使用扩充。如李珉所言，我们定义的模型希望有尽可能广的接受度，尽量遵从CDA标准增加这种接受度的可能性。我建议我们就具体问题讨论，而不要一般地说要不要扩充。如果一般地说，我认为不是万不得以，不要扩充。理由很简单，我们的CDA经验非常有限，我们扩充了的东西可能用CDA模型本身就能搞定。
在本项目中，我认为最重要是检查现有模型和CDA以及IHE Lab遵从性。如有不易解决的问题，我们再讨论它们，这就是我建议review的原因。
谢谢张林提出这个问题。
永坚
From: Min Li [mailto:minli@cn.ibm.com]
Sent: Thursday, July 16, 2009 8:07 PM
To: linforest
Cc: heyusheng; liblpumch; miles li; phenix.pu.qin; wlh1195; xuyongyong; Bao, Yongjian (GE Healthcare)
Subject: Re:RE: RE: RE: Fw:Electronic Medical Summary (e-MS) Project
Dear,
我觉得您问了非常好的一个问题, 这里我试图把我的理解讲得更清楚一点. 如果站在IT人员的角度来说, 我们可以说您讲的这种情况可以通过CDA schema验证, 为什么呢? 请注意这样一个细节:命名空间(namespace). 这里的extension 用到了非HL7得namespace. 这样做的目的就是要CDA引擎在做验证的时候忽略掉非标准的扩展, 因为大多数(不敢说所有的)CDA引擎都只处理标准v3 命名空间下的XML元素.
回想我以前学习CDA的内容,我记得有这样一个原则: 当你觉得现有的CDA不能cover 你的需求时, 可以向CDA 工作组提交你的新需求,申请改进; 或者是直接定义自己的命名空间, 但是不能将私有扩展直接放到缺省的v3命名空间下. 很遗憾我不记得具体在CDA spec的哪一页说到了,下次我们开会的时候可以确认一下.
但是,即使原则上我们可以这样做, 我个人还是不建议这样:
1) 这样做其实是以一种合法的"私有"方式扩展了标准, 是一种work around, 而不是解决问题, 通常需要扩展者本身具有非常受到公认的权威地位, 例如CCD, IHE. 这有一点像hl7 V2的自定义字段一样,你可以在小范围内做统一约定, 但是如果你本身的地位不够强大的时候,它永远都是暂时的,不被广泛认可的, 会经常被challenge;
2) 从技术角度讲,我们说文档是符合CDA的, 这只是对文档的框架加以验证的最低要求,但是我们通常都说仅仅符合Hl7 CDA语法是没有实际应用意义的,还是需要在语义层面的互联互通.因此,即使过了XML schema的语法验证,也还是需要大家都能理解你做的扩展部分如何解释.而这部分工作是相当难做的.以我个人的经验,每当我看到XD-lab中出现"lab:xxx"元素的时候,都很头大, 很有不知所云的感觉. 因此,我觉得这种扩展对制定者和遵守者都是一种负担.
3) 从业务的角度来讲, CDA是否不能cover我们现有的业务,的确需要大家仔细思考.或者是当这种情况不可避免的发生时,我们是否还有其他更经济的做法,需要我们大家再加强学习.
4) 从商业的角度来看, 以我国目前的状态,如果是非强制的规范而会给开发商带来额外负担的话,很可能受到抵制.
上面只是我个人愚见,欢迎各位拍砖, 非常感谢张林老师引出这一话题,正在拜读您发的文档!
B.Regards
Miles (李珉)
Manager, SOA Standards Growth, Emerging Technology Institute(ETI), IBM China Software Development Lab
E-mail: minli@cn.ibm.com
Notes ID:Min Li/China/IBM
[url=tel 8610)82452819]Tel8610)82452819[/url] Tieline:90-52819 Fax8610)82826598
地址:北京市海淀区东北旺西路8号 中关村软件园19号楼 钻石大厦 B座邮编：100193
Address: 1F Tower B, Diamond, Building 19 Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193
linforest ---2009-07-17 06:06:02---Yongjian and Min, Now I have two questions:
Yongjian and Min,
Now I have two questions:
1. Does the word “extension” on the page 63 (e.g., Section 2.3.6 Extensions to CDA R2)(LTF-3: IHE Laboratory Technical Framework, Vol. 3: Content) also mean further constraining?
2. Will such extensions prevent the XML instances from CDA validations?
Thanks.
Best Wishes,
..Lin Zhang
在2009-07-16，"Bao, Yongjian (GE Healthcare)" <Yongjian.Bao@med.ge.com> 写道：
Then it means further constraining.
From: linforest [mailto:linforest@163.com]
Sent: Thursday, July 16, 2009 10:12 AM
To: Bao, Yongjian (GE Healthcare); Min Li
Cc: heyusheng; liblpumch; miles li; phenix.pu.qin; wlh1195; xuyongyong
Subject: Re:RE: RE: Fw:Electronic Medical Summary (e-MS) Project
Yongjian,
The word “extension” comes from the volume 3(LTF-3): Content of the IHE Laboratory Technical Framework (Revision 2.1, August 8, 2008). The PDF file can be abtained from the following address:
http://www.ihe.net/Technical_Framework/upload/ihe_lab_TF_rel2_1-Vol-3_FT_2008-08-08.pdf
Best Wishes,
..Lin Zhang
在2009-07-16，"Bao, Yongjian (GE Healthcare)" <Yongjian.Bao@med.ge.com> 写道：
Zhang Lin:
I’m not sure what do you mean by “extension”. CDA defines an architecture … any “extension” within the architecture (e.g., the clinical statement model) is ok. This is, however, usually referred to “constraints”. So, be really careful about “extension”. If you think you need “extension”, point it out explicitly and clearly, and let’s discuss.
Yongjian
From: linforest [mailto:linforest@163.com]
Sent: Thursday, July 16, 2009 9:47 AM
To: Min Li
Cc: Bao, Yongjian (GE Healthcare); heyusheng; liblpumch; linforest; miles li; phenix.pu.qin; wlh1195; xuyongyong
Subject: Re:RE: Fw:Electronic Medical Summary (e-MS) Project
李老师，您好！
对于检验、过敏等等不同的领域，是不是都存在这样一个问题，即：
处理好对于CDA的遵循（conformance）与对于CDA的扩展（extension）之间的关系。
个人的理解：检验、过敏等等不同的领域有着各自不同的特殊需求，而CDA只是一个通用的标准，况且其本身也不是至善至美。
另外，我有个疑问：
对于 CDA 标准的遵循是否排斥对于CDA的扩展？
敬礼！
张林
2009-07-16
在2009-07-16，"Min Li" <minli@cn.ibm.com> 写道：
鲍老师,
同意您的观点. 目前的版本中确实包含了诸多与CDA不兼容的元素, 例如元素的命名,Cardinality,等等, 甚至有的误差还出现在CDA Header部分. 以前没有注意,正好张林的邮件提醒了我们.
我会尽快改好给大家发过去review.
B.Regards
Miles (李珉)
Manager, SOA Standards Growth, Emerging Technology Institute(ETI), IBM China Software Development Lab
E-mail: minli@cn.ibm.com
Notes ID:Min Li/China/IBM
Tel:(8610)82452819 Tieline:90-52819 Fax:(8610)82826598
地址:北京市海淀区东北旺西路8号 中关村软件园19号楼 钻石大厦 B座邮编：100193
Address: 1F Tower B, Diamond, Building 19 Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193
"Bao, Yongjian (GE Healthcare)" ---2009-07-16 22:14:24---我们必须保证CDA遵从性。但是，XDS LAB只是约束了CDA中的clinical statement模型，如果我们有任何有关
我们必须保证CDA遵从性。但是，XDS LAB只是约束了CDA中的clinical statement模型，如果我们有任何有关样本的要求，超出XDA LAB的要求，但可以用clinical statement模型表达，我们应该ok。你改后的模型可以发给我，帮助review 一下。
永坚
From: miles li [mailto:mamamiaibm@gmail.com]
Sent: Thursday, July 16, 2009 9:02 AM
To: linforest
Cc: xuyongyong; phenix.pu.qin; liblpumch; minli; Bao, Yongjian (GE Healthcare); wlh1195; heyusheng
Subject: Re: Fw:Electronic Medical Summary (e-MS) Project
多谢 张林!
CC: 何老师,王老师, 如果我们的数据集必须通过CDA验证的话,我不得不把检验报告的RMIM重画一遍. 海彤当时画的图加入了很多Lab, Specimen的domain element, 不是以CDA RMIM为基础的. 这样CDA的XSD验证肯定不能通过.
如果我们以 IHE XD LAB为出发点 (CDA的 implementation guide), 而最终结果不能通过CDA验证, 好像也说不过去,除非我们不明确claim 符合CDA. 我会在周末加加班,争取下周早些时候发过去, 这一次我会把CDA L1/L2的模型也补上.
2009/7/16 linforest <linforest@163.com>
各位老师：
附件是加拿大不列颠哥伦比亚e-MS项目的CDA 实施指南（2006-1-11版）。其中，有一个关于核心数据集的附录（Appendix F – Core Data Set），尤其是关于实验室小节的核心数据集。该项目与我们的目的也许有所不同；不过，该文档及其相关文档，无论在格式上，还是在内容上，对于我们编写实施指南和数据集，都不失为有益的参考资料。
注：目前，我无法正常访问e-MS项目的网站。不知道其是否有更新的版本。如果您能够下载到更新版本，烦请转发一份。
敬礼！
张林
2009-7-16
---------- 转发邮件信息 ----------
发件人："linforest <linforest@163.com>"
发送日期：2008-09-22 22:13:36
收件人："李包罗老师" <liblpumch@sina.com>
抄送："王才有" <wangcy@moh.gov.cn>
主题： Electronic Medical Summary (e-MS) Project
李老师，您好！
Electronic Medical Summary (e-MS) Project:
http://www.e-ms.ca/
标准下载（包括消息和文档以及相关的实例）：
Download the e-MS Standard
附件是
e-MS CDA 实施指南原文（该文档之中包含临床方面的数据集，检验等等方面）
我初步对 e-MS CDA 实施指南的目录和前言部分的中文翻译
尽管是2006年的版本，但这个项目的资源对我们目前的工作（EHRSC POC和十小数据元集）有较大的参考价值。
张林
|
发表于 2009-7-20 17:07:44