Hi,
I’m writing my diploma thesis at the Vienna Medical University and I have a question concerning the HL7 templates/archetypes. I’m aware that this sites are related to the openEHR but maybe somebody can answer the following question:
Which model (RIM, R-MIM, …) and which formalism (ADL, OCL, OWL, …) should be used for the description and creation of the entry-level templates?
Thanks for a brief answer!
Best regards
Dana Prochazkova
In een bericht met de datum 15-10-2006 19:15:05 West-Europa (zomertijd), schrijft e0125766@student.tuwien.ac.at:
Hi,
I’m writing my diploma thesis at the Vienna Medical University and I have a question concerning the HL7 templates/archetypes. I’m aware that this sites are related to the openEHR but maybe somebody can answer the following question:
Which model (RIM, R-MIM, …) and which formalism (ADL, OCL, OWL, …) should be used for the description and creation of the entry-level templates?
Thanks for a brief answer!
Best regards
Dana Prochazkova
Can you define what you mean with ‘entry level templates?’
I am creating HL7 compliant and easily transformable to OpenEHR templates covering a wealth of clinical details. We have currently over 150 examples.
dr. William Goossen
the Netherlands
Dear Dana,
Asking the question on the OpenEHR list is answering it.
In my view only CEN/tc251, openEHR and ISO any time soon have the answer:
Use OpenEHR and the CEN and ISO standard.
This means the CEN part one standard is modelling any document or fragment there off.
This means CEN part two defining ADL.
OpenEHR is an implementation plus of the CEN/ISO standard for the EHR.
And provides the Archetype Editor to produce archetypes that can represent clinical information Models.
Both part one and two enable plug-and-play semantic interoperability.
HL7 has nothing that is coming close to something usefull and implementable.
The HL7 RIM has some known problems. The message Development Method has short comings that make it less than optimal for scalability.
Besides EN13606 will become an European standard and an International worldwide standard via ISO in addition.
Is there any real choice?
Gerard
– –
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
T: +31 252 544896
M: +31 653 108732
Dear Dana,
Why would you like to do that?
Theoretically it might be possible to map computationally constraints imposed on one model to others imposed on an other, where both ways express the same clinical model.
But I doubt that this can be done.
So far only humans can make the translation since only us humans have an “internal ontology”, an internal knowledge of the clinical world, that makes this possible.
As far as I can see it, the CEN/tc251 EN13606 part 1 is a model of any document.
The HL7v3 RIM is a linguistic model of any possible statement of fact.
Both are not the same.
For instance the HL7v3 Mood attribute in the HL7v3 RIM will map onto a specific type of Archetype.
Types of Archetypes are based on a model of clinical treatment: Observation, Evaluation, Instruction and Action.
And types of Archetypes are not attributes of the Reference Model, they are different beasts.
In addition the RIM has all kinds of attributes CEN does not need. The combinatorial possibilities of all the structural attributes go into the billions. This amount of nuance exceeds the possibilities of computation and comprehension.
HL7v3 RIM has not defined and used the major RIM classes in a rigourous way, as was shown during a discussion on a HL7 list with the subject: “Why is a document an Act”.
What is your reason/driver to try the impossible?
What might be possible in a way, is to transform from CEN to HL7 and back again when a R-MIM is used that is an agreed mapping of the CEN/tc251 EN13606 part 1 Reference Model using the RIM. Part 5 of the CEN EN13606 standard will contain such an R-MIM, is the expectation.
Why is such an undertaking of mapping between EN13606 and HL7v3 interesting?
Only CEN/tc251 EN13606 makes plug-and-play semantic interoperability possible.
Only EN13606 will enable that conformant systems can be searched using the same query and expose any information stored in that system in an uniform interpretable way enabling better easier clinical decision support.
Greetings,
Gerard
– –
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
T: +31 252 544896
M: +31 653 108732
Dear Dana,
Why would you like to do that?
Theoretically it might be possible to map computationally constraints imposed on one model to others imposed on an other, where both ways express the same clinical model.
But I doubt that this can be done.
So far only humans can make the translation since only us humans have an “internal ontology”, an internal knowledge of the clinical world, that makes this possible.
As far as I can see it, the CEN/tc251 EN13606 part 1 is a model of any document.
The HL7v3 RIM is a linguistic model of any possible statement of fact.
Both are not the same.
Doesn’t CDA provide the model for a document in the context of HL7?
Gregory Woodhouse
gregory.woodhouse@sbcglobal.net
“Those who are enamored of practice
without theory are like a pilot who goes
into a ship without rudder or compass.”
–Leonardo da Vinci (1452-1519)
As they say in Odessa, a CDA "document and an open EHR are two big differences.
Mapping current HL7 vs. openEHR structures is like squaring the circle.
O. Pishev
I believe it is very hard to accept the dogmatic approach of Gerard Freriks once again 
I thought we would have stopped, working on the implementable harmonization artifacts. It has been proven to work with HL7 v3 messages.
For clinical content it does not matter at all in which technical formalism or spec it is operationalised. A clinical concept sorting out takes 2 weeks, transforming from HL7 to Open EHR takes 15 minutes.
William Goossen
In een bericht met de datum 15-10-2006 23:54:28 West-Europa (zomertijd), schrijft gfrer@luna.nl:
What might be possible in a way, is to transform from CEN to HL7 and back again when a R-MIM is used that is an agreed mapping of the CEN/tc251 EN13606 part 1 Reference Model using the RIM. Part 5 of the CEN EN13606 standard will contain such an R-MIM, is the expectation.
Why is such an undertaking of mapping between EN13606 and HL7v3 interesting?
Yes, I say this transformation is possible.
Why interesting? We face multiple approaches and since sorting out the clinical stuf is more costly than transformations, we face a large reuse of models and reduction of overall development costs.
Only CEN/tc251 EN13606 makes plug-and-play semantic interoperability possible.
Only EN13606 will enable that conformant systems can be searched using the same query and expose any information stored in that system in an uniform interpretable way enabling better easier clinical decision support.
Gerard,
are we now in the stage that we have to ly?
I agree that both implementations are still in infancy, but there is no way you can substantiate this.
William
Dear William,
I am currently working on the creation of Diabetes related archetypes based on common archetypes. These archetypes are used to be specialised in templates for use in diabetes protocol support systems.
Please, can you provide me with one example where you have an HL7 compliant “archetype” (I am not sure mean this) which van be easily in an openEHR template? Because my HL7 knowledge is limited ( I have my doubts about the engineering concepts of HL7 v3), I was not able to see this link in an real implementation
Thanks in advance,
Roel Stap
TNO-ICT
Colosseum 27
7521 PV Enschede
+31 53 4835212
+31 6 10968787
DISCLAIMER
http://www.tno.nl/disclaimer/email.html
Gregory Woodhouse wrote:
Dear Dana,
Why would you like to do that?
Theoretically it might be possible to map computationally constraints
imposed on one model to others imposed on an other, where both ways
express the same clinical model.
But I doubt that this can be done.
So far only humans can make the translation since only us humans have
an "internal ontology", an internal knowledge of the clinical world,
that makes this possible.
As far as I can see it, the CEN/tc251 EN13606 part 1 is a model of
any document.
The HL7v3 RIM is a linguistic model of any possible statement of fact.
Both are not the same.Doesn't CDA provide the model for a document in the context of HL7?
it does. The only problem is that where HL7v3 is being used, the
relevant authority may well ordain the use of specific messages rather
than templated CDA, creating a much larger mapping problem.
- thomas beale
Williamtfgoossen@cs.com wrote:
I believe it is very hard to accept the dogmatic approach of Gerard
Freriks once againI thought we would have stopped, working on the implementable
harmonization artifacts. It has been proven to work with HL7 v3 messages.For clinical content it does not matter at all in which technical
formalism or spec it is operationalised. A clinical concept sorting
out takes 2 weeks, transforming from HL7 to Open EHR takes 15 minutes.
Hi William,
I think one needs to be careful with such claims. Properly designing
archetypes can take quite a lot longer than 2 weeks, due to the time it
takes to get various experts to analyse the model, analyse their own
needs etc.
"Transforming HL7 to openEHR" is obviously an imprecise statement; we
would need to know what particular transformation you are talking about;
working out transformations from HL7 to openEHR may or may not be quick
in practice, but they can only be quick once the theory has been worked
out. People are working on this, but it certainly isn't a 15 minute problem.
- thomas
Williamtfgoossen@cs.com wrote:
In een bericht met de datum 15-10-2006 23:54:28 West-Europa
(zomertijd), schrijft gfrer@luna.nl:What might be possible in a way, is to transform from CEN to HL7 and
back again when a R-MIM is used that is an agreed mapping of the
CEN/tc251 EN13606 part 1 Reference Model using the RIM. Part 5 of the
CEN EN13606 standard will contain such an R-MIM, is the expectation.
Why is such an undertaking of mapping between EN13606 and HL7v3
interesting?Yes, I say this transformation is possible.
Why interesting? We face multiple approaches and since sorting out the
clinical stuf is more costly than transformations, we face a large
reuse of models and reduction of overall development costs.
William,
one element I think are you underestimating the importance of is the
dangers of a) excessive data transformation and b) bugs in software due
to loose and/or over-complicated standards specifications. Either can
cause patient safety issues, and ultimately injury or death; they
already have, and will continue to do so.
Data transformations are absolutely to be avoided as much as possible;
they are however of course not totally avoidable. The main factor that
aggravates the problems of data transformation is the semantic gap
between the relevant formalisms.
So while it is clearly good economics to re-use semantic models, the
economic costs of data transformations, particularly poorly specified
ones should not be ignored; they are the costs most related to patient
safety in the health information infrastructure.
I used to work in the control system industry, where the software
controlled power stations, trains, gas pipelines and so on - places
where bugs could cause injury, death and massive capital losses. We made
sure there were no bugs in the software by clean clear design, and heavy
use of version control, heavy reviewing, and disciplined unit and system
testing. There were no data transformations of the kind I see people
casually assuming in the healthcare environment. To be honest, the way I
hear people speak about how the software will transform into this and
that form all over the place, as if to suit the whims of modellers,
standards politics etc, and with little regard for the consequences to
patients - positively scares me. I hope I never end up in a hospital
containing the solutions some people are speaking about today.
And the runtime performance costs of transformation cannot be ignored
either. Processing just prescription messages for a country of 60m
people incurs serious costs of computing hardware and bandwidth.
Complexity and excessive data transformation might keep some people
amused and employed, but in my view, both are the enemies of safe
computing, and in health, of patient safety. They both have to be minimised.
openEHR is designed from the outset to do this, and to provide the
needed semantics for health computing.
- thomas beale
I very much agree with Tom that "transformation" even if desirable in some
circumstances shall not be taken lightly and it is not going to be a piece
of cake, possibly dangerous. Therefore strategies should focus on avoiding
it.
Cheers
Gunnar
Dear William,
You write:
I believe it is very hard to accept the dogmatic approach of Gerard Freriks once again
My simple dictionary reads:
dogma |ˈdôgmə| |ˌdɔgmə| |ˌdɒgmə|
noun
a principle or set of principles laid down by an authority as incontrovertibly true : the Christian dogma of the Trinity | the rejection of political dogma.
ORIGIN mid 16th cent.: via late Latin from Greek dogma ‘opinion,’ from dokein ‘seem good, think.’
By the way, I like the original old meaning of Dogma better.
When we can agree on the modern meaning of Dogma, I will not object either:-)
You find it hard to accept that something is ‘inconvertibly true’, is the way I interpret your quoted sentence.
When you will choose to disagree with me then you must provide arguments and try to convert me and the readers.
My list of positions and arguments, open for debate and written or presented or discussed several times at various occasions, are:
Harmonisation: CEN and HL7
Harmonisation between CEN EN13606 EHRcom and HL7v2 is not taking place.
Harmonisation between CEN EN13606 plus its Archetypes and HL7v3 message artefacts is not possible.
Harmonisation between CEN and HL7 on the level of Archetypes as performed by humans using the OpenEHR Archetype Editor Tool (and therefor EHRcom part 2) is possible. This is very much needed and taking place.
Harmonisation between CEN EN13606 EHRcom and HL7v3 work on the Clinical Statement might become possible and has to be proven. It depends on the way this HL7 Clinical statement is expressed; e.g. what Reference Model will be used.
CEN/tc251 EN13606 EHRcom and HL7v3 m****appings
In general, mappings are possible, only, when both worlds share one or more meta-models that guide the transformation/mapping.
At the Archetype level, when archetypes are presented to humans, only humans are able to translate in the absence of a formal complete and accepted Ontology.
(This situation is what you write in your last sentence. Humans easily are able to translate clinical models expressed via HL7v3 to CEN Archetypes and vice versa)
At the level of Archetypes, as expressed by a formalism describing constraints on a Reference Model, transformation is possible when both Reference Models can be mapped.
Part 1 of the CEN/tc251 EN13606 is not the same model as the HL7v3 RIM. A mapping between these two is not possible. They are certainly NOT the same.
Only a computational mapping might perhaps be possible with some effort between Archetypes on the basis of CEN/tc251 EN13606 part 1 and a HL7 R-MIM expressing EN 13606 part 1. By the nature of the process these meta-models can be mapped, partially. Extra models are needed to deal with all possible mappings of structural HL7v3 vocabularies and elements in the CEN Reference Model (part 1) and types of CEN archetypes (part 3)
Requirements based standards
CEN/tc251 EHRcom (and OpenEHR) is the only EHR related standard, I know, that is meticulously based on a well researched set of requirements for the EHR as published by ISO.
Proof of Concept: working software
CEN/tc251 EN13606 EHRcom is based on more than 15 years of research in Europe and Australia. Various Proof of Concept studies have been performed. The most recent one is OpenEHR, its open source specifications and published functional software. Plus the proprietary software produced by OceanInformatics from Australia based on CEN/tc251 EN13606 EHRcom and OpenEHR.
Scalability
Message paradigm versus the Archetype (Two Level Model Paradigm)
Any solution derived from the RIM and expressed as a message using the HL7v3 MDF method will NEVER scale. Since each vendor has to write specific software for each artefact and version of it. Each clinical domain will consist of many messages. There are many clinical domains.
Any solution based on the CEN/tc251 EN13606 is scalable by the fact that only one schema based on part 1 has to be implemented by the vendor, ever.
Any CEN archetype or set of archetypes assembled in a Template can be read, stored, retrieved, presented and exchanged without the need to write any software by the vendor. Therefor EN13606 and OpenEHR provide build-in scalability.
Decision support
Systems that are conformant to EN13606 EHRcom have as an additional feature that software providing decision support is able to query ALL the data stored since all data in conformant systems is presented using one uniform method without any extra programming. Plug-and-play decision support becomes possible.
Plug-and-play
CEN/tc251 EN13606 EHRcom makes real Plug-and-Play semantic interoperability possible.
Status
EN13606 EHRcom not only is becoming an European Standard and a National Standard in its Member States, but is on its way to become an International ISO standard as well.
Role of European standards
European standarisation is subject to various European Directives.
European standards play a specific role in legislation and procurement in all its Member States.
The European “Stand-still rule” ensures that in Europe conflicting standards are impossible.
Greetings,
Gerard
– –
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
T: +31 252 544896
M: +31 653 108732
William,
Since when is it a “lie” when one states his opinion?
Read my other e-mail where I state more opinions and provide some arguments.
Read in that e-mail also the fact that CEN/tc251 EN13606 and OpenEHR are based on many years of R&D and real implementations.
EN13606 EHRcom is factual NOT in its infancy, as you know.
Gerard
– –
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
T: +31 252 544896
M: +31 653 108732
Gerard,
It would help us to have the names and contact info for those
implementations over many years. As you know there are also CDA and HL7 v3
implementations. I am trying to put together that list.
Thank you for your support of these discussion.
Ed
---------+------------------------------------->
> Gerard Freriks |
> <gfrer@luna.nl> |
> Sent by: |
> openehr-technical-bounces@|
> openehr.org |
> >
> >
> 10/16/2006 07:31 AM |
> Please respond to For |
> openEHR technical |
> discussions |
> >
---------+------------------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> >
> To: For openEHR technical discussions <openehr-technical@openehr.org> |
> cc: |
> Subject: Re: Antw: Re: AW: HL7 templates/archetypes |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
William,
Since when is it a "lie" when one states his opinion?
Read my other e-mail where I state more opinions and provide some
arguments.
Read in that e-mail also the fact that CEN/tc251 EN13606 and OpenEHR are
based on many years of R&D and real implementations.
EN13606 EHRcom is factual NOT in its infancy, as you know.
Gerard
-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
T: +31 252 544896
M: +31 653 108732
Our course mapping between two solutions is just postponing the issues.
Maybe some day we will get to a single solution.
Ed Hammond
---------+------------------------------------->
> Thomas Beale |
> <Thomas.Beale@OceanInforma|
> tics.biz> |
> Sent by: |
> openehr-technical-bounces@|
> openehr.org |
> >
> >
> 10/16/2006 06:12 AM |
> Please respond to For |
> openEHR technical |
> discussions |
> >
---------+------------------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> >
> To: For openEHR technical discussions <openehr-technical@openehr.org> |
> cc: |
> Subject: Re: AW: HL7 templates/archetypes |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Gregory Woodhouse wrote:
Dear Dana,
Why would you like to do that?
Theoretically it might be possible to map computationally constraints
imposed on one model to others imposed on an other, where both ways
express the same clinical model.
But I doubt that this can be done.
So far only humans can make the translation since only us humans have
an "internal ontology", an internal knowledge of the clinical world,
that makes this possible.
As far as I can see it, the CEN/tc251 EN13606 part 1 is a model of
any document.
The HL7v3 RIM is a linguistic model of any possible statement of fact.
Both are not the same.Doesn't CDA provide the model for a document in the context of HL7?
it does. The only problem is that where HL7v3 is being used, the
relevant authority may well ordain the use of specific messages rather
than templated CDA, creating a much larger mapping problem.
- thomas beale
Hi Roel
Nice to hear that somebody out there is working on diabetes.
Are you gonna share them.?
We are planning to make Fertility related archetypes based on common templates.
rgds
Srikanth
In een bericht met de datum 16-10-2006 13:34:27 West-Europa (zomertijd), schrijft gfrer@luna.nl:
William,
Since when is it a “lie” when one states his opinion?
Read my other e-mail where I state more opinions and provide some arguments.
Read in that e-mail also the fact that CEN/tc251 EN13606 and OpenEHR are based on many years of R&D and real implementations.
EN13606 EHRcom is factual NOT in its infancy, as you know.Gerard
The lie is in the ONLY
Simple: OpenEHR works and HL7 v3 works. ONLY is not an argument, it is just an expression of beliefs.
William
In een bericht met de datum 16-10-2006 12:59:18 West-Europa (zomertijd), schrijft Thomas.Beale@OceanInformatics.biz:
Hi Tom,
Thanks for bringing in arguments here. I will
respond in between the lines.
William,
one element I think are you underestimating the importance of is the
dangers of a) excessive data transformation and b) bugs in software due
to loose and/or over-complicated standards specifications. Either can
cause patient safety issues, and ultimately injury or death; they
already have, and will continue to do so.
WG: I agree with excessive and bugs being problematic.
That is why I prefer the ‘more difficult’ HL7 v3 approach currently because it tackles the more complicated approach, and then transformation of the specification! to OpenEHR is simpler and will cause no problems.
I talk here about a clearly specified data set, cardinalities, vocab, code, you know the examples.
Data transformations are absolutely to be avoided as much as possible;
they are however of course not totally avoidable. The main factor that
aggravates the problems of data transformation is the semantic gap
between the relevant formalisms.
WG: that is exactly why we are currently working within HL7 AND OpenEHR groups to come to one specification only and allow from that different implementations.
So while it is clearly good economics to re-use semantic models, the
economic costs of data transformations, particularly poorly specified
ones should not be ignored; they are the costs most related to patient
safety in the health information infrastructure.
WG: exactly, hence the careful specification of the clinical content, and not datatransformations, but model transformations.
I used to work in the control system industry, where the software
controlled power stations, trains, gas pipelines and so on - places
where bugs could cause injury, death and massive capital losses. We made
sure there were no bugs in the software by clean clear design, and heavy
use of version control, heavy reviewing, and disciplined unit and system
testing.
WG: agree with the process here, health care is lacking such scrutiny for software development.
TB: There were no data transformations of the kind I see people
casually assuming in the healthcare environment.
WG: I agree, I talk about the transformation of the data specification and where possible, the vocabs from one system to the other. There is a publication coming out soon on how to tranform from one classification to the other, where an in depth analysis is necessary.
To be honest, the way I
hear people speak about how the software will transform into this and
that form all over the place, as if to suit the whims of modellers,
standards politics etc, and with little regard for the consequences to
patients - positively scares me. I hope I never end up in a hospital
containing the solutions some people are speaking about today.
WG: again, I agree that any standard specification should be done carefully, and I think that paying the most attention to the clinical definition and careful independent of technology modeling is the way to go here. This would than allow the different technologies to work and allows careful testing whether the content specification is met 100%.
And the runtime performance costs of transformation cannot be ignored
either. Processing just prescription messages for a country of 60m
people incurs serious costs of computing hardware and bandwidth.
WG: again, I talk about the transformation of the content specification, not the actual data of 60 M people on a continuous base, that would be ridiculous. However, messaging of the correctly specified data from one system to the other in case there is a need can be done safely in my opinion and experience.
Complexity and excessive data transformation might keep some people
amused and employed, but in my view, both are the enemies of safe
computing, and in health, of patient safety. They both have to be minimised.openEHR is designed from the outset to do this, and to provide the
needed semantics for health computing.
WG: again: HL7 v3 is designed for safe exchange of carefully defined and standardised data items. Although I agree with your comments with respect to safety etc, I see no difference in meticulously defined standards for message or OpenEHR specification. Especially since on the concrete data item level we work with templates and archetypes in the same way.
- thomas beale
William Goossen