Thomas Beale wrote: > GEHR on its own is not an interchange format. The "modern" way to do > interchange is using generic mechanisms like CORBA, rather than > application level protocols like HL7. CORBA (for example) just > serialises whatever structures it finds in memory into a bytestream, > according to the rules for the language and the IDL definition for > the classes involved. So there is no need to say anything about > clinical concepts in the protocol - it's all in the object model > (i.e. the class model, i.e. the software - it's all the same thing > in OO). HL7 v 2.x has to define clinical concepts in the protocol, > because it makes no other assumptions about systems. All one has to > do is to build an HL7 interface and stick to the HL7 rules. Wait, wait, just a moment. You are suggesting that it would be favorable to not have clinical concepts represented in the interface to a system (a protocol is simply an interface). This goes straight against my idea of good system design. Object oriented technology allows us to construct system interfaces of ever higher abstractions, ever more application (business) oriented and ever less computing- technology oriented. This is what computer science did all along: First systems engineers talked about bits and registers and memory units, then about characters and strings, then about tokens and named variables, then we distinguished information presentation from application level semantics, we built independence from physical data base schemas, etc. Now you are saying we should stop right here and deal only with a somewhat intermediary logical schema and not deal with clinical concepts? No. You are not really suggesting it, since GEHR too talks about clinical observations, etc. In the end, systems want to do clinical business, and communication wants to exchange clinically relevant information. I don't say it's easy, but wishing application level business logic away from inter-system interfaces is not right. Your points on HL7 version 2 are well taken, but I plead with you to keep HL7 v2 out of the discussion. When we compare GEHR with HL7 we ought to look at HL7 version 3 only. Whatever you may know about HL7 v2 does not apply to HL7 v3. So, please do not even mention HL7 v2 any more in this discussion (except if explicitly labeled and explained why HL7 v2 is relevant.) > - because the protocol is defined in terms of its semantic content, > there is always the problem of older software not understanding > newer messages. This should not in principle happen with CORBA. This is stated too simply, misleading, and therefore wrong. First of all CORBA is not equal to CORBA. (At some point we should start using terms and references to models and systems more distinctly.) There is CORBA and CORBAmed. CORBA talks about interaction of distributed objects. CORBAmed defines application models and interfaces using the CORBA infrastructure. CORBA is good stuff. CORBAmed defines information models that are designed mostly from an information systems perspective rather than from a medical information perspective. <SOAPBOX>That's the reason why CORBAmed goes pretty fast, but I predict at some point they will get into problems tying these many pieces together.</SOAPBOX> So, if you talk about CORBA here, which do you mean, CORBA plain or CORBAmed? It is not true that CORBAmed is free from "semantic content" as you suggest to be a good idea here. CORBAmed has specific semantic content (that sometimes, however, falls pretty short.) If you talk about CORBA plain, I agree that it is a great architecture in which to make medical information systems interoperate, but it requires one to add well-defined medical semantics to CORBA or otherwise you just communicate "stuff" that your systems do not really understand. Thus, the information model that encompasses the whole of clinical information is of paramount importance. That's what HL7 version 3 is doing. So, CORBA is to be lauded for it's technical infrastructure, but not for it's missing any medically relevant concepts. These concepts of our domain have to be added and have to be standardized (CORBAmed tries to do just that too.) That's hard work, but there is no other way around that work. XML and other hyped technologies (like ASN.1, remember it?) all come along with great (bold) promises that are never fulfilled -- the technology evangelists are like a locust plague: they fall over an application domain field that is just about giving crops and eat everything to the ground, suggesting to do it all over again, (from the ground up so to speak :-) using their new technology. This costs so much effort, and leads nowhere. That's why I stick with HL7 v3 and that's why I refuse to shortcut our application layer work to any currently hyped technology. I consider GEHR to be on a fairly high application layer too, defining clinically relevant EMR concepts. My only criticism about GEHR is that they build everything on the concept of Observation ... often used metaphorically, and sometimes called MedicalItem or something. In one part of HL7 version 2 we made this same mistake believeing that everything could just be represented by an Observation structure (the infamous OBX segment.) Yet, we now know that this isn't much better than expressing everything in XML: tag-value pairs are technology, the medical semantics still needs to be added. And that's our paramount job in the medical information standards community. Instead of doing our job, some of us always choose to get distracted by some hyped technology. This makes it harder. regards -Gunther -- Gunther_Schadow-------------------------------http://aurora.rg.iupui.edu Regenstrief Institute for Health Care 1050 Wishard Blvd., Indianapolis IN 46202, Phone: (317) 630 7960 [EMAIL PROTECTED]#include <usual/disclaimer>
begin:vcard n:Schadow;Gunther tel;fax:+1 317 630 6962 tel;home:+1 317 816 0516 tel;work:+1 317 630 7960 x-mozilla-html:FALSE url:http://aurora.rg.iupui.edu org:Regenstrief Institute adr:;;1050 Wishard Blvd;Indianapolis;Indiana;46202;USA version:2.1 email;internet:[EMAIL PROTECTED] title:M.D. fn:Gunther Schadow end:vcard
