Re: Fw: Interoperability with HL7

[Thomas Beale <thomas.beale@oceaninformatics.com>]

On 11/02/2010 07:45, Andrew McIntyre wrote:

I am still interested to see what the concrete objections to the openEHR reference

model classes as the basis forDCM  archetypes are.

openEHR is a EHR system and its archetypes often include things like Result identifiers 
and order numbers and things that are built into the information model on other systems.

some such numbers are part of the openEHR reference model, but even where they are included in openEHR, they are in dedicated archetypes, mostly a CLUSTER archetype that is used to populate COMPOSITION.context. The Observation lab archetype has in its protocol attribute some order / filler id attributes. Other than that, as far as I know the occurrence of such ids inn openEHR archetypes is almost non-existent (might be in a few instructions).

So here I would say two things: if 2% of openEHR archetypes have such ids, DCM has discounted the use of openEHR based on this? Secondly there has been discussion of included order/filler ids in the openEHR RM, which would remove even these identifiers.

While I get the gist of the objection, I have to say it is very unconvincing (given the very low incidence of the elements you refer to) as a reason for DCM to avoid using openEHR archetypes, and instead re-engineer all the same semnatics in a different way. Do people in DCM have a lot more free time than the rest of us?

openEHR has semantics in attributes and classes, as does HL7 V3 and they are different.

for very good reasons ;-)

Ideally a DCM format would exclude administrative attributes such as order numbers and 
result identifiers and not use semantic attributes and classes.

see previous post about 'semantic' attributes and classes. If you don't use any, then you have no foundation to do numerous simple things, and they will all get soft-modelled in non-interoperable ways. DCM will create more of the problem is is supposed to be solving. That is going to retard the health IT domain even more.

It would be agnostic 
on patient identification and demographics etc etc A DCM could have attributes that 
allow automatic mapping to specific classes in a specific model.

A DCM format on its own would not be the basis of an EHR, but the repository of the 
clinical knowledge alone and would be transformable, perhaps with a requirement of 
checking a few option checkboxes, into multiple model

here is the real nub of the problem. There is no way this is going to happen with 'checking a few option checkboxes'. A HL7v3 Act object has 22 attributes, and an ActRelationship has 18. A microbiology result has 40 logical nodes, i.e. 40 Act objects, and by implication some 40 ActRelationship objects. This is 22 x 40 + 18 x 40 = 1600 attributes. The source DCM (if it is even vaguely like the microbiology archetype will have 40 nodes, but only about 2-3 attributes per node or less - say 120 attributes. And the mapping into HL7 is not simple; you have to set things like all the type/mood/class codes, and esoteric things like contextconduction...

If the DCM model is what I would consider 'sensible' then mapping to openEHR should be quite a bit simpler, but every difference you create (e.g. removing all inbuilt timing structures) just complicates things, and it will quickly get out of hand. Mistakes will be made by whichever users do this manual transformation; it will require reviewing, and in the end it won't be clear if the mapping has been correct in all cases.

I would say (without trying to be alarmist) that here is where DCM could die: even if it creates a lot of decent models (and even accepting the extra effort to reconstruct all the missing support that the openEHR RM supplies), the transformation to target concrete models will be error-ridden and complex. This does not look like an attractive path to me.

In fact, in pure engineering terms, you would be safer to start with openEHR archetypes (at least these are implemented and tested / implementable / testable) and generate DCM models out of the archetypes, if you really want 'model agnostic' pure hierarchies.

The concept of two level modelling perhaps needs to be 3 level, 

1. Information System
2. Glue layer
3. DCM Model

In openEHR a DCM-> OpenEHR transform could combine 2 & 3.

I guess its a question of how much value is placed on inter-operability between 
systems as waiting for one to become a mono-culture may require patience

it doesn't require a monoculture in my experience. It is certainly possible to accommodate HL7v2, CDA, other formats but only do one set of archetypes. The current DCM strategy I think is most likely to lead to a lot of a) re-inventing the wheel and b) a set of models that remain largely disconnected from real systems, and there fore risk being wasted effort.

- thomas

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical