Dear Graham, This round no next move from me. I call for a time out.
This gives time for some reflections: -1- HL7 as an organisation is extremely valuable. We really must preserve this precious resource of healthcare providers, their organisations and Software vendors. -2- This is not to say that everything they thought of is valuable and must be preserved. -3- The same is true for CEN/tc251 but for other reasons -4- Lets say the HL7 v3 community and the CEN/tc251 community are equal. (And I think they are) -5- And that both perceive an internal and external drive to harmonise (As many know I'm in favour of this since I tried to get at a Memorandum of Understanding between CEN and HL7) -6- So far it is my perception that the voice of CEN/tc251, and their not unimportant contributions to medical informatics, was not heard, understood by our American partners. -7- Then the question arises: When the world starts to experience the multitude of difficuties with the HL7v3 RIM and message development method what will we do? Will we start to patch up something that has intrinsic problems? (Do you remember the recent discussion on a HL7 e-mail list. My conclusion was that they don't know the definitions of the major classes of the RIM. Luckily HL7v3 is not deployed that widely, so there are not much legacy systems to reckon with?) Or will we start from a more sound starting point. One that will become an European standard and is on its way to become an ISO standard as well? I reserve my next move until you and Thomas agree on technical details in your interesting dispute. (For the moment I'm in Thomas's corner. I agree more with him than with your position. As said. I wait for your next moves and Thomas' moves in the technical dispute) Have a nice weekend. Gerard ps: In the end we all MUST co-operate. Their is only one patient with one problem that needs our undivided attention, care and devotion. The poor sod needs the best solution for his problem. -- <private> -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 15-sep-2006, at 12:12, Grahame Grieve wrote: >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060915/88fbb591/attachment.html>
