Dear Stef, As I understand when Charlie McCay says "More is needed to ensure that information can be safely reused and combined.". It is because when you have an agreed reference model and terminology, for example openEHR and SNOMED you can define the clinical concepts relation using the archetypes but your archetype definition for one concept may vary between different solutions. Each of these possible solutions would be valid archetypes that can be used therefore to avoid problems is better store your archetypes in an agreed repository. Then both sides, the source and the receptor, can express the medical concepts with the same structure (archetype) and avoid interoperability problems.
The same situation can happens defyning clinical concepts in other reference models such as HL7 CDA or 13606 archetypes. This is only my opinion maybe I am not the right person to answer about other people comments Alberto 2010/2/1 Stef Verlinden <stef at vivici.nl> > Op 1 feb 2010, om 10:33 heeft Charlie McCay het volgende geschreven: > > More is needed to ensure that information can be safely reused and > combined. > > > Dear Alberto, > > Can you please explain what this 'more' is and provide some examples for a > non-technical person like myself. > > Cheers, > > Stef > > Op 1 feb 2010, om 10:33 heeft Charlie McCay het volgende geschreven: > > Alberto > > I would say that EHR systems based on the openEHR specification face > similar interoperability challenges to to those based on other proprietary > or open source architectures. > > I will take a step back and observe that two implementations of openEHR or > any other EHR system design will not interoperate fully unless there are > coherent information structures used. This is certainly true of a system > as flexible as that defined by the openEHR architecture. > > Agreeing on a reference model (HL7 RIM, 13606, openEHR, ...) and a > terminology certainly helps, but even with that agreement in place there are > many ways to represent the same clinical content. More is needed to ensure > that information can be safely reused and combined. Within an openEHR > installation this is achieved by using a single coherent set of archetypes, > much as data structures are localised in other EHR architectures. > > If your requirement is limited to communicating within an openEHR > community, then developing and agreeing to use a suite of common archetypes > and templates is sufficient. If you wish to interoperate with the broader > healthcare information systems installed base, then it makes sense to work > with HL7 specifications which are focused on delivering this, and broadly > adopted for this purpose. > > For external communication of entry-level detail using HL7v3 there is a > need for agreed static models (R-MIMs). These are implemented as templates > (eg with CDA), or as CMETs in V3 messaging - and a corresponding sets of > archetypes for 13606 or openEHR can be defined if these are what you use to > configure your system. > > All the best > > Charlie > > > -- > Charlie McCay, *MailScanner has detected a possible fraud attempt from > "x-msg:" claiming to be* charlie at RamseySystems.co.uk > Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES > tel +44 1743 232278 / +44 7808 570172 skype: charliemccay > linkedin:charliemccay > > > > ------------------------------ > *From: *Thomas Beale <*MailScanner has detected a possible fraud attempt > from "x-msg:" claiming to be* thomas.beale at oceaninformatics.com> > *Organization: *Ocean Informatics > *Reply-To: *For openEHR technical discussions < > openehr-technical at chime.ucl.ac.uk> > *Date: *Sun, 31 Jan 2010 23:30:22 +0000 > *To: *<*MailScanner has detected a possible fraud attempt from "x-msg:" > claiming to be* openehr-technical at openehr.org> > *Subject: *Re: Interoperability with HL7 > > On 29/01/2010 07:41, Alberto Moreno Conde wrote: > > I would like to address the interoperability with the HL7 standards. As I > understand it is possible to map between OpenEHR to HL7 CDA, this allows us > to create systems that are based on the openEHR reference model compatible > HL7. This system would be able to send HL7 v2 and HL7 v3 messages from the > CDA and EHR_EXTRACTS from the OpenEHR reference model. > > I don't understand what consequences have that the HL7 RIM is still not > fully compatible with the OpenEHR reference model if we can send messages > from HL7 CDA. > > Is there other problems in the interoperability between HL7 and OpenEHR? > > I hope that Thanks > > Alberto > * > * > > > Hi Alberto, > > In practical terms, performing mapping between HL7v2 messages and openEHR, > and also CDA and openEHR is certainly possible. It takes some work - the > complexity of the HL7 RIM doesn't make it that easy for CDA or other > v3-based structures. > > In a theoretical sense, the key thing to understand is that in HL7 there is > a pervasive approach of restriction-based modelling - in the RIM, the > data-types, and all *MIMs. In this kind of modelling, abstract classes have > numerous attributes, in theory all that would ever be needed, and descendant > classes are defined as restrictions of the parents. You will have noted for > example that the Act class in the RIM has 22 attributes, and the > Act-relationship class 18. I won't go into the problems that this causes, > but there is one other key fact to note: the RIM classes contain a mixture > of domain information related attributes and message-related attributes. > However, if your interest is not hand-building messages, it can be hard to > see past these attributes to get a pure domain model of the concept in > question, e.g. cholesterol test result, or whatever. This is one of the > reasons CDA has become popular, because it is a more generic, less > message-oriented RMIM than other message types. It nevertheless contains the > same fine-grained (level 3) concepts as the RIM, albeit in a restricted > form. > > At a more concrete level of analysis, you need to compare the reference > models. The openEHR reference model is a standard OO style of modelling, and > has been heavily influenced by the development of archetypes over the years. > It now appears to accommodate most clinical models pretty naturally and has > been very stable for nearly 3 years. It contains useful structures like > history-of-events, various design patterns for referencing demographic > entities, a generalised state machine for instructions and activities, and a > comprehensive model of distributed versioning. > > In terms of solving practical interoperability problems, the above analytic > comparisons have been useful in implementing the required transformations. > If you can provide more detail on the problem you are trying to solve, I > could probably describe more detailed and relevant points of comparison. > > - thomas beale > > > ------------------------------ > _______________________________________________ > openEHR-technical mailing list > *MailScanner has detected a possible fraud attempt from "x-msg:" claiming > to be* openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100201/be58a4c0/attachment.html>
