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, 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 <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: <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 > 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/e4e48e13/attachment.html>
