Alberto You are correct.
An example would be the XMLEPR project [1], which in 1999 asked a number of suppliers to write ENV 13606 instances for the same GP medical record. The results showed that each used different combinations of 13606 structures to represent key concepts such as allergies. Since these structures need to be recognised and used by the receiving systems, further specification is needed. In the case of the english GP2GP project, an HL7v3 implementation of 13606 (ie clinical statement) was used, with additional implementation guidance to say how allergies, family history, and many other such patterns should be represented. This has been successfully adopted and implemented within the NHS CFH program [2]. The language defined by ENV13606+Read codes was too flexible for the receivers to be able to be able to identify all the allergies (among many other things). The GP2GP specification effectively established a more specific language for expressing GP record contents, that was easier for receivers to process. In the time since then formalisms (archetypes, HL7 static models as templates, etc) have been developed to help express those additional constraints. One other question to ask is why you want interoperability. Often it is fine to define structures that will only be used locally, and often it is all that is possible. OpenEHR defines a particular architecture that can be used for EHR systems which manipulate locally defined data, as well as data that needs to be shared in a wider community. HL7 provides a framework and set of specifications for sharing healthcare information. All the best Charlie [1] http://xml.coverpages.org/isis-healthcare.html [2] http://www.connectingforhealth.nhs.uk/systemsandservices/gpsupport/gp2gp -- Charlie McCay, 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: Alberto Moreno Conde <albertomorenoco...@gmail.com> Reply-To: For openEHR technical discussions <openehr-technical at chime.ucl.ac.uk> Date: Mon, 1 Feb 2010 11:40:32 +0100 To: For openEHR technical discussions <openehr-technical at chime.ucl.ac.uk> Subject: Re: {Disarmed} Re: Interoperability with HL7 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 > _______________________________________________ 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/9f461cd9/attachment.html>
