> But. > -1- > The HL7 RIM is a reference model for any sentence. > The EHRcom reference model defines any document. > The former will be more difficult to implement generally by writing generic > software, because sentences can express very many nuances of trillions of > things. > The latter is more easy to implement. The model for any generic document is > only > a limited amount of classes and structural codes.
Perhaps the answer is that the reference models are not equivalent. The openEHR reference model is equivalent to the HL7 DIMs. The fact that the HL7 DIM's are based on a metamodel with a structural code pattern is both a strength and a weakness when compared with the OpenEHR reference model, which is not based on a seemantic metamodel, only on a technical metamodel (MOF). So we should not compare reference models, we should compare the openEHR reference model with the HL7 Domain Models > -2- > The HL7v3 method, using the RIM as template for further developments, > produces > R-MIMs in a not-computable way. they are computable, but not compatible with each other in a computible fashion. > Each R-MIM generates an unique xml-schema needing unique software. well, I will keep saying this until everyone listens: * R-MIM's need not be treated this way * Archetypes can be treated this way. Each approach has advantages. HL7 chose one, OpenEHR chose the other. Full analysis suggests that HL7 should change on this issue, we are considering this. > -3- > Using the Message paradigm, a community of healthcare providers, together > with > the vendors, produce a series of XML-schema's for a clinical domain. > In the Archetype (or Two Level Model) paradigm only healthcare providers meet > to > produce the archetypes/templates. All vendors have to implement one > relatively > simple and stable XML-scheme based on the EHRcom reference model. Implementing a reference model is more costly than implementing a few messages with specific models. Implementing a lot of messages with specific models is more costly than implementing a reference model. The structural code pattern allows HL7 users to choose either approach, but this has not proved very successful, partly because the nominated reference model is actually the metamodel. > -4- > HL7v3 is based on the philosophy that only the common information model is > used > in the exchange structure. It is system agnostic. It is not impacting the > proprietary components of the communicating systems. > EHRcom impacts one or more components is EHR-systems in order to be able to > reap > the benefits of this standard. The full deployment of EHRcom needs a new > layer > in EHR-systems. One layer that conditions the archetypes and accompanying > data > such that it provides a uniform interface with the other EHR-SYSTEM > components > like the persistence layer, the presentation layer and the business logic > layer. > (This is why the CEN/tc251 HISA standard is important next to EN13606 EHRcom) so this is why they have different scope. But the scopes very clearly have a large overlap > -5- > EHRcom is an European standard (and will become an ISO standard as well) > European standards play a reserved role in the European Market. > Only European standards (or equivalent standards) can be used in legislation > in > Europe and its Member States. > Several European Directives regulate this in the European Economic system. > > In view of the first four topics mentioned above, I don't think HL7v3 > messages > and EHRcom can be considered equivalent. they are not the same. But the focus clearly overlaps. > In our game of 'EHR-chess' you will not be surprised to learn that my next > move is: > */CEN/tc251 EN13606 EHRcom (openEHR) deserves to be considered for worldwide > patient safe communication between EHR's and EHR-systems./* > It is a new exciting paradigm. I could respond with: HL7 V3 is the primary contender for world wide communication between all health systems, including EHR's. But that's not what I'm here for, we cannot afford to compete and confront. Instead, my move is about stepping in the direction towards this statement: The HL7/CEN healthcare standard provides a solid base for everyone who wishes to communicate and manage information in healthcare. ok. my move: If we work together (i.e. our different focuses overlap with common engineering and semantics support, and we can use each others content models), this will be a net benefit to everyone. For instance, I note that OpenEHR does not include general business process / orchestration models, and you really need to consider this before systems can usefully communicate. This is a core interest of HL7. But OpenEHR/13606 have a focus of managing persisted information - everyone has to do this, and HL7 is not good here. So, it's good to work together for everyone's benefit. We can do this if we share: * reference models * constraint pattern expressions * wire formats So, we can move ahead in each of these areas: * I have a data types ITS for HL7 V3 which is well cross-mapped to the OpenEHR data types. The differences are mainly due to requirements differences, and we can use this as a base to move to a single model that everyone shares. I am starting to work on the reference model. (There is a joint working party already working the reference model who have made significant progress, some of the contributers to this are on this list) * I can interconvert between R-MIM's and ADL diagrams. I have code for this. To complete the work, some small changes are needed in ADL and HL7 constraint methodology. I have been proposing changes here at Boca Raton for the HL7 methodology, and I have been discussing the changes required in ADL with Tom. I believe that they make sense in their own right, not just justified by harmonization. And in Eclipse, we will be working on having a single editor for both archetypes and HL7 models * The HL7 wire format is being reexamined. For technical reasons, a wire format that closely resembles the OpenEHR wire format is emerging as a front runner. (i.e. a single schema at the domain level). This is not an established decision, it's something that is still being worked on So, in each of the 3 areas, fundamental progress is being made, and, while not complete, progress is accelerating, and being taken seriously by everyone. I look forward to advancing this even further in Geneva in a few weeks time. Last point: the most important thing to understand is that both OpenEHR and HL7 are *very closely* aligned in goals and methods. There is some engineering differences. I wish that important clever people who should know better would stop claiming these differences are significant, and start talking about how these things are nearly the same after all. Then we can accept that both are flawed, and have useful discussions about how to move forward together. (and pigs will fly, I guess, in some cases) Grahame
