Re: Fw: Interoperability with HL7

[Andrew McIntyre <andrew@medical-objects.com.au>]

Title: Re: Fw: Interoperability with HL7

Hello Thomas,

Thursday, February 11, 2010, 8:24:53 AM, you wrote:

On 10/02/2010 12:00, Andrew McIntyre wrote:  I think a DCM format should exclude the administrative attributes, such as Author and Observation Time  Andrew, I could agree in principle, but how could Observation time be an 'adiministrative' attribute?

The wording is probably wrong, its an attribute that is expected to be in the 
information model and how its there is not something a DCM needs to worry about.

A "Follow up date" might belong in the DCM. In reality its a line that has to be drawn based on 
what is expected of an information model of the target systems. That is a vague line for sure but
if u look at the dominant few information systems it can be drawn easily for many attributes.

and leave those to the Information model. Drawing that line is potentially tricky, but needs to be done in order to allow each Information model to do it the way it wants to. Things like order numbers and links to orders should also stay out of the DCM model. In the end we want the pure clinical hierarchical structure that does not conflict with the information model and ideally does not conflict with the Terminology Model.    is DCM now trying to be totally model-agnostic?

Unless everyone wants to throw away their model and start afresh it has to be. 
Currently DCM is modelling in UML, mindmaps etc etc and they cannot be transformed 
in any algorithmic way unless they are constrained. They are however trying to be 
model agnostic currently.

The line between the DCM and terminology is also hard to draw as it varies depending on the ability of the terminology. eg SNOMED-CT is quite rich wrt its models and ICD-X is quite poor. well... sometimes. Have a look here for SNomed's context model - it is in poor shape... http://www.openehr.org/wiki/display/term/Information+Model+-+Terminology+Equivalence  A DCM optimised for SNOMED-CT will be inadequate if the only coding system is ICD-10. I guess including SNOMED-CT context structures with the option to use them for ICD-10 and move them to the terminology for SNOMED-CT is one possibility? 2 similar DCMs (?archetypes) with stated terminology affinity would be another.    many countries are using things like ICD9 or 10, ICPC+, vocabularies for nursing, procedures, devices, prostheses and drugs. Snomed actually doesn't figure that highly in the list of currently used terminologies - i.e. actually in production. Re-imbursement-related terminologies and vocabularies are far more important right now. So optimising DCM (whatever DCM now is) for Snomed would be quite wrong-headed, unless DCM is also destined for 'in 5y+' time.

Yes I agree, its a question of the "lowest common denominator issue" Using a lowest common 
denominator does reduce the value of SNOMED-CT and many large realms have a license. There 
are some moves to allow (SNOMED-CT + information model attributes + logic) = Transformability 
to classifications which is usually the billing terminology.

Some sort of "adapter pattern" to allow other terminologies could reduce the impact of allowing 
the use of less capable terminologies in some realms. Its not easy, but I would hate to give up 
the semantics that SNOMED-CT give to allow another terminology to be used in a realm that I 
don't interact with. I appreciate SNOMED-CT is not perfect, but it does have some very powerful 
features.

I appreciate this is an openEHR list, and maybe this discussion should be transferred to a DCM list, but I don't think there are enough resources to model every clinical concept in every information model and there is enormous value in a neutral DCM format. The archetype concept is a good way to achieve this, but perhaps a generic "DCM only" Reference Model that does not try and be a EHR model would help?    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.

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

Ideally a DCM format would exclude administrative attributes such as order numbers and 
result identifiers and not use semantic attributes and classes. 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 models.

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 
measured in geological time. Our own personal focus is mostly on HL7 V2 as that is 
likely to persist for a long time in Australia. However its the models that add 
the eHealth value, not the format that its currently held in. 


Andrew McIntyre

- thomas beale __________ Information from ESET NOD32 Antivirus, version of virus signature database 4855 (20100210) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

-- 
Best regards,
 Andrew                            mailto:andrew@Medical-Objects.com.au

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