Antw: Sources of information on HL7 EHR/OpenEHR

[williamtfgoos...@cs.com]

In een bericht met de datum 13-9-2006 21:25:34 West-Europa (zomertijd), 
schrijft odysseas at sysnetint.com:


> 
> Hello,
> 
> Are there any documents anywhere that describe or compare and contrast the 
> OpenEHR initiative and the HL7 EHR effort? I have seen a couple of 
> references 
> to the fact that there are efforts to achieve harmonization but I was 
> wondering if there is a detailed comparison anywhere.
> 
> We are in the process of working through the OpenEHR specification documents 
> and implementation code as well as the specification documents coming out of 
> the HL7 EHR effort so, I was wondering if there are is a study of some sort 
> that would assist us in the process of making the comparison and 
> establishing 
> the association.
> 
> Thanks,
> Odysseas
> 
> Odysseas Pentakalos, Ph.D.
> Chief Technology Officer
> SYSNET International, Inc.
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> 


You could  look at the NEHTA website for their paper that compares standards, 
including CEN 13606 (OpenEHR) and HL7 v2 and HL7 v3.

There is an OpenEHR presenation / paper for the MIE 2006 conference, tackling 
some of the differences

HL7 / CEN and ISO work together on a 13606-HL7 v3 R-MIM that does the 
conversion, it is currently developed as an implementation guide.

There are comments from the Netherlands to CEN about the 13606 (available at 
the CEN website) in which some brief comparison is included.

Most people compare the 13606 OpenEHR materials with the HL7 RIM. However, 
that is the wrong level to compare, appropriate would be to compare with the 
HL7 
v3 Care Provision D-MIM derived from the RIM, because this is focused on the 
EHR extract and on the full Record exchange message.

In general: OpenEHR / 13606 RIM is the most generic / a-specific model level, 
could potentially be used for shipbuilding records, supermarkets and 
healthcare records
HL7 v3 RIM is more detailed in such that it covers health care specific 
classes and relationships
D-MIMs are made of the HL7 v3 RIM virtual bricks to become meaningful domain 
models
derived from D-MIMs are the R-MIMs which are subsets for specific message 
purposes.

on the detailed level the archetypes in CEN 13606 and in HL7 v3 the templates 
and R-MIMs for specific care statements,  cover the smallest molecules of 
clinical data. 
examples of the latter can be found at www.zorginformatiemodel.nl 

A problem with the archetype approach (see the definition of this in open EHR 
and 13606) is that it does not address the clinical vocabulary which is 
included in HL7 v3 R-MIM approaches and 
it does not tackle the clinical knowledge base that explains why some data 
have to fit together and why a relationship has to be kept. (E.g. for 
scientific 
instruments and scales).

Hope this helps,


dr. William Goossen
co- chair HL7 v3 patient care TC


-- next part --
An HTML attachment was scrubbed...
URL: 

Antw: Sources of information on HL7 EHR/OpenEHR

[Thomas Beale]

The main difference architecturally is that there in openEHR there is a 
reference model from which software and systems can be built. Archetypes 
and templates simply designate legal configurations of instances of the 
reference model. In HL7, the data are instances of schemas that are 
progressively refined from the RIM. In recent discussions with the 
designers, they claim that the theory of DIMs, RMIMs etc is based on 
"relational projections" on the RIM (i.e. that's the basis of attribute 
"removal"). Anyway, the end result is a schema per message.

Williamtfgoossen at cs.com wrote:
>
>
> on the detailed level the archetypes in CEN 13606 and in HL7 v3 the 
> templates and R-MIMs for specific care statements,  cover the smallest 
> molecules of clinical data.
> examples of the latter can be found at www.zorginformatiemodel.nl
you can see the openEHR archetypes at 
http://svn.openehr.org/knowledge/archetypes/dev/index.html
>
> A problem with the archetype approach (see the definition of this in 
> open EHR and 13606) is that it does not address the clinical 
> vocabulary which is included in HL7 v3 R-MIM approaches and
> it does not tackle the clinical knowledge base that explains why some 
> data have to fit together and why a relationship has to be kept. (E.g. 
> for scientific instruments and scales).
this is a problem I was unaware of William, can you elaborate with an 
example?

- thomas

Antw: Sources of information on HL7 EHR/OpenEHR

[Gerard Freriks]

Dear William,

It is nice to see a balanced approach to the problem of plug-and-play  
semantic interoperability that Archetypes and Template will bring about.

As far as I can see is the Reference Model provided by CEN/tc251 in  
EN13606 an openEHR a stable, well researched, developed  and complete  
specification to be implemented in EHR-systems. I have some founded  
doubts about the stability of the HL7v3 RIM as reference  model, as  
several papers and debates indicate.

I fail completely to see the problems you mention with CEN/tc251  
EN13606 and openEHR archetypes.
So I'm (and many more will be) very curious to see an example.

The experiences so far at TNO in the Netherlands have not given any  
indication of the type of problems you mentioned.
On the contrary. Archetypes bind coding systems, and their codes,  
tightly to clinical concepts used in a defined context.
That is the essential purpose (requirement) for archetypes that they  
have these characteristics.

Greetings,

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 653 108732



On 13-sep-2006, at 22:02, Williamtfgoossen at cs.com wrote:

> A problem with the archetype approach (see the definition of this  
> in open EHR and 13606) is that it does not address the clinical  
> vocabulary which is included in HL7 v3 R-MIM approaches and
> it does not tackle the clinical knowledge base that explains why  
> some data have to fit together and why a relationship has to be  
> kept. (E.g. for scientific instruments and scales).
>
> Hope this helps,
>
>
> dr. William Goossen
> co- chair HL7 v3 patient care TC

-- next part --
An HTML attachment was scrubbed...
URL: 

Antw: Sources of information on HL7 EHR/OpenEHR

[Dipak Kalra]

Dear William,

Please note that some of the vocabulary mappings, and correspondence with the 
main HL7 Act specialisations are provided in 13606 Part 3. I recognise this is 
not the complete solution you seek, but it is a start.

(The Enquiry draft of Part 3 was recently circulated to CEN Working Group 
members. Although not yet on the public CEN TC/251 web site I am sure it will 
be soon. You, of course, William have had direct access to it via NEN.) Others 
can let me know if they would like me to e-mail you a copy.

with best wishes,
Dipak Kalra
Clinical Senior Lecturer in Health Informatics
CHlME, UCL
___

Antw: Sources of information on HL7 EHR/OpenEHR

[Grahame Grieve]

Hi Tom

> The main difference architecturally is that there in openEHR there is a 
> reference model from which software and systems can be built.

This is not a difference; it's true of HL7 as well

> Archetypes 
> and templates simply designate legal configurations of instances of the 
> reference model.

this is true about archetypes

> In HL7, the data are instances of schemas that are 
> progressively refined from the RIM.

well, it doesn't have to be; and also, you could do this with archetypes
and/or templates, and it would have some use too.

> In recent discussions with the 
> designers, they claim that the theory of DIMs, RMIMs etc is based on 
> "relational projections" on the RIM (i.e. that's the basis of attribute 
> "removal"). 

well, I can't speak for "the designers" (I'm spending some time with him
today  on this subject ;-), but archetypes and HL7 models are the same thing.
I can interconvert between them. The only issues are syntactical differences
in things that are allowed in each language, and they are minor. Obvious
conclusion: they are the same thing.

There are differences, but they are really primarily engineering differences.
And some philosophical stuff in the reference models, but I'm starting
to think this isn't as big as I thought

It appears that this is stuff we can sort out and actually work together.

Grahame

Antw: Sources of information on HL7 EHR/OpenEHR

[Bert Verhees]

>> al"). 
>> 
>
> well, I can't speak for "the designers" (I'm spending some time with him
> today  on this subject ;-), but archetypes and HL7 models are the same thing.
> I can interconvert between them. The only issues are syntactical differences
> in things that are allowed in each language, and they are minor. Obvious
> conclusion: they are the same thing.
>   
Yes, this is partly true. I even started writing a tool which translated 
automatically HL7 XSD's to ADL-files. So it was possible to use OpenEHR 
as a HL7 storage machine.
I stopped this work because there is a bug in the java-kernel concerning 
Archetype-slots, which are really necessary for this job.

Now, also, because I changed my plans, the need disappears to finish 
this, but it can be done, in fact, I did it, except from the places 
where CMETs which incorporate other CMETs (and a few other smaller 
things), and the code is quite easy, from which one can conclude that 
ADL is fit to store CMETs. So, OpenEHR is fit as a HL7 storage machine. 
The product is however in beta, beta phase. I wrote it in a few weeks, 
and it needs some time to come to a really stable and good product.
(it even is more powerful, than for HL7 storage machine, my code does 
not know it is handling HL7, it handles every XSD-file, also when more 
are referred to each other, which almost always is)

The code I wrote is however based on the 0.95 kernel. But it can easily 
be transformed to a newer version.

And why is this good?
--
I know, in the field there are some problems how to handle the many 
CMETs that appear, even in a small RMIM. The number reaches 300 hundreds 
in a patient-record.

Very many of them are very similar, f.e. being just a demographic CMET, 
one with Address, one without, etc
There are some companies which translate CMETs to software objects, 
because when doing this, they can generate code from XSD with f.e. JAXB.
It maybe clear that this code-result is a shame when comparing it to 
code which is designed on well design principles.

So, generating code is not a solution,
but
handling hundreds of CMETs, defined in XSD-files on another way is quite 
programmer-intensive, and also, because of the many CMETs to be done, 
error-prone.

concluding:
That is why OpenEHR is a very good HL7 storage-machine, but there are a 
few technical problems to be resolved (archetype slots), which will be 
very soon.

That is the technical part, but what is more important, is the 
informational part ( philosophical stuff, I think this is what Graham 
means by...). That is not my job

But I understand there are, except from discussion on the technical 
parts, also discussions on the informational parts. That is even more 
interesting

I hope to read more about that

Thanks
Bert


> There are differences, but they are really primarily engineering differences.
> And some philosophical stuff in the reference models, but I'm starting
> to think this isn't as big as I thought
>
> It appears that this is stuff we can sort out and actually work together.
>
> Grahame
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>   

Antw: Sources of information on HL7 EHR/OpenEHR

[Grahame Grieve]

I have code to build the archetypes from the internal source of
the R-MIM's rather than the schemas. I will be publishing
this through eclipse shortly.

I will be able to go the other way too, but both formats will
need modifications for gap coverage. I am presenting changes
to the RMIM diagrams tomorrow for HL7 consideration, and also
talking to Thomas about changes to ADL to address the gap.

Grahame


Bert Verhees wrote:
> 
>>> al"). 
>>
>> well, I can't speak for "the designers" (I'm spending some time with him
>> today  on this subject ;-), but archetypes and HL7 models are the same 
>> thing.
>> I can interconvert between them. The only issues are syntactical 
>> differences
>> in things that are allowed in each language, and they are minor. Obvious
>> conclusion: they are the same thing.
>>   
> Yes, this is partly true. I even started writing a tool which translated 
> automatically HL7 XSD's to ADL-files. So it was possible to use OpenEHR 
> as a HL7 storage machine.
> I stopped this work because there is a bug in the java-kernel concerning 
> Archetype-slots, which are really necessary for this job.
> 
> Now, also, because I changed my plans, the need disappears to finish 
> this, but it can be done, in fact, I did it, except from the places 
> where CMETs which incorporate other CMETs (and a few other smaller 
> things), and the code is quite easy, from which one can conclude that 
> ADL is fit to store CMETs. So, OpenEHR is fit as a HL7 storage machine. 
> The product is however in beta, beta phase. I wrote it in a few weeks, 
> and it needs some time to come to a really stable and good product.
> (it even is more powerful, than for HL7 storage machine, my code does 
> not know it is handling HL7, it handles every XSD-file, also when more 
> are referred to each other, which almost always is)
> 
> The code I wrote is however based on the 0.95 kernel. But it can easily 
> be transformed to a newer version.
> 
> And why is this good?
> --
> I know, in the field there are some problems how to handle the many 
> CMETs that appear, even in a small RMIM. The number reaches 300 hundreds 
> in a patient-record.
> 
> Very many of them are very similar, f.e. being just a demographic CMET, 
> one with Address, one without, etc
> There are some companies which translate CMETs to software objects, 
> because when doing this, they can generate code from XSD with f.e. JAXB.
> It maybe clear that this code-result is a shame when comparing it to 
> code which is designed on well design principles.
> 
> So, generating code is not a solution,
> but
> handling hundreds of CMETs, defined in XSD-files on another way is quite 
> programmer-intensive, and also, because of the many CMETs to be done, 
> error-prone.
> 
> concluding:
> That is why OpenEHR is a very good HL7 storage-machine, but there are a 
> few technical problems to be resolved (archetype slots), which will be 
> very soon.
> 
> That is the technical part, but what is more important, is the 
> informational part ( philosophical stuff, I think this is what Graham 
> means by...). That is not my job
> 
> But I understand there are, except from discussion on the technical 
> parts, also discussions on the informational parts. That is even more 
> interesting
> 
> I hope to read more about that
> 
> Thanks
> Bert
> 
> 
>> There are differences, but they are really primarily engineering 
>> differences.
>> And some philosophical stuff in the reference models, but I'm starting
>> to think this isn't as big as I thought
>>
>> It appears that this is stuff we can sort out and actually work together.
>>
>> Grahame
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>>
>>   
> 
> 

-- 
Grahame Grieve
CTO, Jiva Medical   Software Integration Tools
CTO, Kestral Computing  Healthcare Applications

Antw: Sources of information on HL7 EHR/OpenEHR

[Thomas Beale]

Grahame Grieve wrote:
> Hi Tom
>
>   
>> The main difference architecturally is that there in openEHR there is a 
>> reference model from which software and systems can be built.
>> 
>
> This is not a difference; it's true of HL7 as well
>   
I think people would have a hard time finding it - where is the 
reference model from which you can build software? It's not the RIM as 
we are told time and time again (I can pull a dozen quotes from all the 
core RIM designers to say that the RIM is not a basis for software, only 
generating other schemas - this has been practically religion for 10 
years)... you could call the sum total of all the HMDs a "reference 
model" I guess, since they are what software is based on, but that's 
stretching the meaning of the term...anyway, it's a pretty clear 
difference for all practical purposes.
>   
>> In HL7, the data are instances of schemas that are 
>> progressively refined from the RIM.
>> 
>
> well, it doesn't have to be; and also, you could do this with archetypes
> and/or templates, and it would have some use too.
>   
I'm just saying how things work now, so that new people have some hope 
of understanding. I doubt if it would have any use with archetypes / 
templates though - the subtractive logic based on relational projections 
just isn't a part of normal object modelling or openEHR.
>   
>> In recent discussions with the 
>> designers, they claim that the theory of DIMs, RMIMs etc is based on 
>> "relational projections" on the RIM (i.e. that's the basis of attribute 
>> "removal"). 
>> 
>
> well, I can't speak for "the designers" (I'm spending some time with him
> today  on this subject ;-), but archetypes and HL7 models are the same thing.
> I can interconvert between them. The only issues are syntactical differences
> in things that are allowed in each language, and they are minor. Obvious
> conclusion: they are the same thing.
>   
That's a somewhat misleading statement. An archetype isn't a new model; 
it's a statement about putting together pieces from an existing model. 
An RMIM is a new model with respect to the model from which it was 
derived - different classes, different attributes. That's the whole 
point of the HL7 refinement method - to iteratively derive new schemas 
from the RIM...you can't pick up an RMIM and say what configuration of 
classes from another model you have, because you don't have classes from 
another model, you have _modified_ classes from another model. I know 
that some RIM people will then say that the classes aren't really 
modified, the missing attributes are "projected out", which means the 
new classes are indeed new classes - each one specifying a new 
projection on a class in the preceding model. Which brings us to the 
question of the quality of the original model (the RIM), as well as the 
details of the refinement method as a way of specifying content models.

Some archetypes and RMIMs are trying to say the same thing however. Is 
reliable machine conversion possible? The key point is that while 
conversion between the formalisms of some part of an archetype and an 
RMIM and vice versa may be possible, conversion between actual real 
archetypes and real RMIMs is not the same thing, due to the reference 
models involved. Conversions that might be considered:
a) existing openEHR or CEN archetypes -> RMIM "language" - based on the RIM?
b) existing RMIMs -> archetypes based on the RIM
c) existing RMIMs -> archetypes based on openEHR

a) might be possible, but seems hard, because the RIM lacks numerous 
primitives present in the openEHR reference model; if it was achieved, 
it would allow openEHR content to be communicated in an HL7v3 message 
(although why incur all the pain of transformation at both ends, when 
the information can just be sent in the normal way is beyond me - 
sending it as an opaque payload would be easier and safer); b) may well 
be doable, and I suspect is the transformation you have most likely 
achieved already - this would allow archetyping tools to be used in 
HL7,  but still wouldn't provide a way for openEHR archetypes to be used 
in HL7, due to the difference reference models; c) I cannot see being 
possible because of the differences in reference models and also another 
problem:  it is hard to tell with RMIMs what was intended and what "had 
to be done that way" due to the limited language available in the RIM. 
Actually reverse-engineering the true intention of the modellers from an 
RMIM in general will be hard, due to this effect, and it should not be 
under-estimated. So c) is only likely to be doable my manual means, but 
it certainly should be considered, because there is a goldmine of domain 
thinking locked up in the RMIMs which needs to be shared by systems and 
technologies outside of HL7v3 messages.

One of the things newcomers to this field have to do is have a very hard 
look at the reference models involved, how they enable semantically rich 
systems and how they 

Antw: Sources of information on HL7 EHR/OpenEHR

[Grahame Grieve]

Hi Tom

>> This is not a difference; it's true of HL7 as well
>>   
> I think people would have a hard time finding it - where is the 
> reference model from which you can build software?

You can build it from RIM or DMIM's or Messages. Would this be a
good choice? I suspect not. But let's be correct here.

>>> In HL7, the data are instances of schemas that are 
>>> progressively refined from the RIM.
>>> 
>> well, it doesn't have to be; and also, you could do this with archetypes
>> and/or templates, and it would have some use too.
>>   
> I'm just saying how things work now, so that new people have some hope 
> of understanding. I doubt if it would have any use with archetypes / 
> templates though - the subtractive logic based on relational projections 
> just isn't a part of normal object modelling or openEHR.

The "subtractive logic" as you call it, is exactly what cADL is.
It's true that it's not part of normal object modelling - and that's
a deficiency of normal object modelling. So you invent cADL and
Hl7 invents Static Model Diagrams, but they both do the same thing,
and in this regard OpenEHR and HL7 do not follow normal object
modelling.

>> well, I can't speak for "the designers" (I'm spending some time with him
>> today  on this subject ;-), but archetypes and HL7 models are the same thing.
>> I can interconvert between them. The only issues are syntactical differences
>> in things that are allowed in each language, and they are minor. Obvious
>> conclusion: they are the same thing.
>>   
> That's a somewhat misleading statement. An archetype isn't a new model; 
> it's a statement about putting together pieces from an existing model. 

it's not a misleading statement. I am aware that lot's of HL7 people are
making misleading statements about HL7 modelling - but they are mislead
themselves, and they are generally open to being educated.

if I can interconvert, therefore it's true that the 2 formats are
presentations of the same concept. ADL is a more natural fit, and
I think that in the long term, most people would prefer to develop
in the tools that arise out of the ADL constructs. But they are
still the same concept

So let's all move on: these things are the same concept, there's
some engineering differences about how to represent and use the
concepts.

> Some archetypes and RMIMs are trying to say the same thing however. Is 
> reliable machine conversion possible? The key point is that while 
> conversion between the formalisms of some part of an archetype and an 
> RMIM and vice versa may be possible, conversion between actual real 
> archetypes and real RMIMs is not the same thing, due to the reference 
> models involved.

agree that automated conversion between reference models is not (yet)
possible, and agree that the key difference is in the reference models.
This is something we all need to work on. At least we have made
major progress with data types.

I suggest as an opening gambit regarding how to progress this that the
OpenEHR reference model corresponds more closely to the HL7 domain models
than to the RIM, and that's the useful point to pursue genuine
interoperability.

Grahame

Antw: Sources of information on HL7 EHR/OpenEHR

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

Antw: Sources of information on HL7 EHR/OpenEHR

[Grahame Grieve]

>> The "subtractive logic" as you call it, is exactly what cADL is.
>>   
> No, it's not - this is a fundamental misunderstanding. The subtractive logic 
> of 
> the HL7v3 methodology is the ability of one model in the chain (say an RMIM) 
> to 
> remove attributes in class A that were defined in the same class A in the 
> predecessor model (say a DIM).

In cADL, I can say something like this:

   attributeName cardinality matches {0} matches {*}

this is a statement that attributeName cannot be valued in this model.
But attributeName must exist in the reference model, and it is superfluous
to say this if some other archetype on which you are based has already said
this. And you cannot add or define attributeName in cADL

In an RMIM, you make a statement that attributeName cannot be valued
in this model.  AttributeName must exist in the reference model, and it
is superfluous to say this if some other RMIM or DMIM on which you are
based has already said this. And you cannot add or define attributeName in
DMIMs or R-MIMS

If you want, you can interpret the statement, either in an archetype or
an RMIM, as a definition of a new class which has had that value
"subtracted", as HL7 does with RMIM's. This may or may not be a good
idea, but doesn't change the fact that what is going on in concept is
no different

 > The models are defined, starting with the RIM,
> loaded with attributes that can be deleted (projected out) in this way.

you've been listening to someone who's trying too hard to pretend these
things are not the same too much; ignore him. In spite of the fact that
I will use "projection" below, I think it's an extremely unhelpful term.

> This isn't a deficiency in object modelling, because it is not part of the 
> object model

I believe that it should be; it's certainly part of Bertrand Meyer's scope
for an object model: design by contract.

>> So you invent cADL and
>> Hl7 invents Static Model Diagrams, but they both do the same thing,
>> and in this regard OpenEHR and HL7 do not follow normal object
>> modelling.

You objected to this. And yes, The reference models for both are normal
object models. But the idea that the value of the construct is found in
constraint definitions on the construct is not normal practice. I believe
it's the only game in our town, but it is not normal practice. I think
it should be.

> but there is still the key difference to do with attribute deletions. It 
> could 
> be faked by including a lot of invariants in an archetype to force all such 
> attributes to 0

what's fake about that?
We could talk about whether it is good that HL7 constraint statements implicitly
prohibit anything not mentioned - but this is a policy, it doesn't really
bear relevance on the question of the concepts

> And the other problem with this is that two 
> distinct RMIMs each containing (say) a clone of the Observation class from 
> the 
> RIM could delete different combinations of attributes (i.e. create 2 new 
> projections on the RIM Observation class); multiply this up to N RMIMs doing 
> the 
> same thing, and M classes. None of this can happen in openEHR.

really? So I cannot make cADL statements that make different constraints on
a reference model class in different archetypes (or even the same one)? Of 
course
this is how things work. If I chose to treat an archetype as a "projection" - 
which
I could - then this might be a problem. If I chose not to treat an RMIM is a
"projection", then it's not a problem.

I'm going to keep saying this until everyone listens: the difference is not
in what is being done, it's in how the outcome is treated.



> Believe me, if interconversion was easy, we would have done it years ago 
> (when 
> we did in fact try, in concert with senior HL7 people). What you are now able 
> to 
> do is a conversion between formalisms (or parts thereof; RMIMs etc don't have 
> a 
> place to put the meta-data, archetype terminology or code-bindings), which is 
> not the same as a conversion between artifacts. It will be great if the ADL 
> formalism can be used more widely, but please don't imply that a) archetypes 
> and 
> RMIMs now seamlessly interconvert or b) that the methods are really the same 
> in 
> HL7 and openEHR. This will just confuse people.

the methods are the same, the perception is different. Agree that RMIM's
are missing some things. They can - and will - be changed.

But yes, I don't (yet) convert between reference models. I don't want to
imply something different, but the language you have chosen to use is
confusing. what's an "archetype"? Is it an ADL statement against any
reference model, or an ADL statement against the openEHR reference model?
Please advise me how to describe things so they aren't confusing.

> the problem of overuse of coded attributes in HL7 is what killed this kind of 
> effort the last time it was tried - the HL7 people could not produce reliable 
> rules as to when some value went into Act.code and when it went into 
> Act

Antw: Sources of information on HL7 EHR/OpenEHR

[Thomas Beale]

Grahame Grieve wrote:
>>> The "subtractive logic" as you call it, is exactly what cADL is.
>>>   
>>>   
>> No, it's not - this is a fundamental misunderstanding. The subtractive logic 
>> of 
>> the HL7v3 methodology is the ability of one model in the chain (say an RMIM) 
>> to 
>> remove attributes in class A that were defined in the same class A in the 
>> predecessor model (say a DIM).
>> 
>
> In cADL, I can say something like this:
>
>attributeName cardinality matches {0} matches {*}
>   
Grahame,

you can only do this if the reference model already says that the 
cardinality (which is only for container types by the way) is 
0..something. You can't say and attribute value is absent unless the 
reference model already allows that.
> this is a statement that attributeName cannot be valued in this model.
> But attributeName must exist in the reference model, and it is superfluous
> to say this if some other archetype on which you are based has already said
> this. And you cannot add or define attributeName in cADL
>   
no, that's not right - the attributeName of course exists in the RM, but 
if its cardinality is 0..1 or 0..*, clearly it is allowable for there to 
be no value in the data. cADL statements are statements about objects, 
i.e. instances, not models.
> In an RMIM, you make a statement that attributeName cannot be valued
> in this model.  AttributeName must exist in the reference model, and it
> is superfluous to say this if some other RMIM or DMIM on which you are
> based has already said this. And you cannot add or define attributeName in
> DMIMs or R-MIMS
>
> If you want, you can interpret the statement, either in an archetype or
> an RMIM, as a definition of a new class which has had that value
> "subtracted", as HL7 does with RMIM's. This may or may not be a good
> idea, but doesn't change the fact that what is going on in concept is
> no different
>   
see above. There are no new classes of any kind in ADL archetypes, nor 
any subtractions, additions or any other modifications to the reference 
model, because archetypes are not saying anything about models, or 
classes, they only make statements about instances.
>  > The models are defined, starting with the RIM,
>   
>> loaded with attributes that can be deleted (projected out) in this way.
>> 
>
> you've been listening to someone who's trying too hard to pretend these
> things are not the same too much; ignore him. In spite of the fact that
> I will use "projection" below, I think it's an extremely unhelpful term.
>   
well, he's the most vocal advocate/defender/architect of the RIM, and 
seems to represent HL7 on the matter...and that's how he describes the 
theory behind the RIM.
>   
>> This isn't a deficiency in object modelling, because it is not part of the 
>> object model
>> 
>
> I believe that it should be; it's certainly part of Bertrand Meyer's scope
> for an object model: design by contract.
>   
that is something else entirely - DbC statements like in Eiffel and OCL 
are statements attached to models, defining or modifying their 
semantics. Archetypes don't add anything to the model, they say how its 
instances should be used.
>   
>>> So you invent cADL and
>>> Hl7 invents Static Model Diagrams, but they both do the same thing,
>>> and in this regard OpenEHR and HL7 do not follow normal object
>>> modelling.
>>>   
>
> You objected to this. And yes, The reference models for both are normal
> object models.
well, I don't think many people would agree,with respect to HL7 - I have 
numerous reports and references to that effect over the years. And they 
are right: no-one builds object models by including all possible 
attributes in the most abstract classes so that they can be stripped out 
in "derived" models - there is not one paper, textbook or other 
published source that says to do this, and there are many that show why 
it should not be done. I will write a cheque for ?100 to anyone who can 
find one that anyone has heard of (not published by HL7 obviously), 
describing why an object model should be built this way.
>  But the idea that the value of the construct is found in
> constraint definitions on the construct is not normal practice. I believe
> it's the only game in our town, but it is not normal practice. I think
> it should be.
>
>   
well constraints on models have been normal since Djikstra and others 
invented the concepts; it's a pity that only languages like Z, Eiffel 
and a few others have incorporated them. In fact, I think we should 
consider it an aberration that the other programming languages have 
failed to do something so basic so far But now Java has the JML 
effort, and C# will finally get design by contract. But we need to be 
careful in our understanding - these contracts are constraints on the 
reference model; there is no point trying to express domain specific 
constraints (i.e. business rules) on instances as contracts, because a) 
we don't want that stuff built

Antw: Sources of information on HL7 EHR/OpenEHR

[Grahame Grieve]

>> In cADL, I can say something like this:
>>
>>attributeName cardinality matches {0} matches {*}
>>   
> Grahame,
> 
> you can only do this if the reference model already says that the 
> cardinality 

of course

>> this is a statement that attributeName cannot be valued in this model.
>> But attributeName must exist in the reference model, and it is superfluous
>> to say this if some other archetype on which you are based has already said
>> this. And you cannot add or define attributeName in cADL
>>   
> no, that's not right - the attributeName of course exists in the RM, but 
> if its cardinality is 0..1 or 0..*, clearly it is allowable for there to 
> be no value in the data. cADL statements are statements about objects, 
> i.e. instances, not models.

ok, I'll rephrase:

This is a statement that attributeName cannot be valued in an instance
that conforms to this constraint. But attributeName must exist in the
reference model, and it is superfluous to say this if some other archetype
on which you are based has already said this. And you cannot add or define
attributeName in cADL

This is a statement that attributeName cannot be valued in an instance
that conforms to this model. But attributeName must exist in the
reference model, and it is superfluous to say this if some other *IM
on which you are based has already said this. And you cannot add or define
attributeName in an *IM

If you want, you can interpret the statement, either in an archetype or
an RMIM, as a definition of a new class which has had that value
"subtracted", as HL7 does with RMIM's. This may or may not be a good
idea, but doesn't change the fact that what is going on in concept is
no different

so, you say:

> There are no new classes of any kind in ADL archetypes, nor 
> any subtractions, additions or any other modifications to the reference 
> model, because archetypes are not saying anything about models, or 
> classes, they only make statements about instances.

And I say that this is equally true about archetypes and *IMs, and you can
choose, if you want, to create schemas or class models from either. HL7
chooses to. OpenEHR doesn't.

> that is something else entirely - DbC statements like in Eiffel and OCL 
> are statements attached to models, defining or modifying their 
> semantics. Archetypes don't add anything to the model, they say how its 
> instances should be used.

So, an archetype is not a definition of semantics for how to use a
model in a particular context?

> well, I don't think many people would agree,with respect to HL7 - I have 
> numerous reports and references to that effect over the years. And they 
> are right: no-one builds object models by including all possible 
> attributes in the most abstract classes so that they can be stripped out 
> in "derived" models 

you do. tell me that this isn't how openEHR works? You define everything
you will need in the reference model and strip it out from the instances
using archetypes

>>  If I chose to treat an archetype as a "projection" - which
>> I could - then this might be a problem. If I chose not to treat an RMIM is a
>> "projection", then it's not a problem.
>>   
> but - an archetype isn't, and an RMIM isthese are both facts - they 
> are in the formal expressions

So, I can see that I'm not getting anywhere. I am claiming that this
difference is a feature of how these things are used, and hoe they are
presented, not what they are. And that you can use either in either way.

Am I wrong to claim that you *can* use either in either way? (I am not
claiming that anything is useful, only possible)

You told me that you could a schema from an archetype
And, if you remember, we spoke about why this would be useful and
how it would be limited - they are exactly the same issues that HL7 V3
implementers face today

Grahame

Antw: Sources of information on HL7 EHR/OpenEHR

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

Antw: Sources of information on HL7 EHR/OpenEHR

[Grahame Grieve]

ok, we have real convergence here.

OpenEHR works exactly like HL7 - define a reference model
with all the needed semantics, and then refine things away
in constraint models (and use the refinements as a basis for
composition). So the principle is the same.

We can generate [class models|schemas|wire formats] from
constraint patterns. Doing so has benefits and costs. The
same benefits and costs in either HL7 or OpenEHR. And one
of the clear costs relates to persistence. I think we need
to search for a better way, but that's not going to happen
in the short term.

But the OpenEHR & HL7 reference models are quite different.
In most parts, the HL7 reference model is more abstract
(Which is way Act gets 22 attributes). So harmonising between
the reference models is going to require actual change rather
than adroitly altering perspectives, as with data types and
the constraint model things.

This will be hard, and painful. And it must involve compromise,
so this is when we find out who really values collaboration.

And we don't want to take away the real benefits that OpenEHR
has in the process (same for HL7)

Grahame

Antw: Sources of information on HL7 EHR/OpenEHR

[Ognian Pishev]

Grahame,

One of the theoretical difficulties of the debate that you are contributing 
so eloquently to is to separate methods proper to computing from methods 
defined by domain specificity.
Object-oriented programming, modular design, abstract data types, etc. are 
fundamental principles whose existence does not follow from any particular 
domain features. They lead to better information modelling in terms of 
architecture, computational semantics and have been adopted as the best 
engineering methodology to create information processing systems.
The abstractions that bridge the gap between computing and domain-driven 
modelling have to be able to represent in machine processable form the 
business objects we are dealing with. What you are doing in this case is 
less important than what you are doing it to. The marriage of the two 
strands does not deny their individuality but produces an offspring that 
blends their essential features in an organic way.

openEHR contains RECORD in its name as the basic abstraction. The RECORD is 
a container structure that has well defined computational semantics - data 
entry is structured in the form of compositions that may be of different 
type (instruction, observation, etc.) because of differences in computing 
requirements - data representation, etc.
Thus we have a model of a record (document) management system which at its 
highest level is generic. However, its type system is geared towards the 
faithful representation of information in the health care domain with the 
goal of producing a shared longitudinal patient record.

HL7 as the name attests is based on the messaging paradigm. The MESSAGE has 
been historically the modelling abstraction that defines HL7.  Thus, we have 
to ask ourselves, which root abstraction fits better the twin criteria of 
clear and purposeful computational semantics and faithful representation of 
domain specifics.

You said:

> ok, we have real convergence here.
> OpenEHR works exactly like HL7 - define a reference model
> with all the needed semantics, and then refine things away
> in constraint models (and use the refinements as a basis for
> composition). So the principle is the same.

(I have the feeling that you are thinking of HL 7 V4.0)
Convergence is a really strong statement. I understand your motivation and 
your honest desire to overcome the gap between openEHR and HL7. However, one 
has to be equally honest in appraising the
two approaches and their results.

openEHR doesn't "work exactly like HL7".  A brief look at the history of the 
two would show that while openEHR has always been based on sound software 
engineering and knowledge modelling principles, HL7's effort to a reference 
model to its messaging structures is not necessarily a product of organic 
development, hence th gap between version 2 and version 3.

openEHR does define a reference model with all the needed computational 
semantics but leaves domain-specific knowledge modelling to the second level 
of its methodology - archetype modelling.
Implementation efforts have clearly shown openEHR's ability to produce clean 
clean computational models that enhance domain-specific semantic 
interoperability first and foremost throught the strict enforcement of the 
separation of concerns between information modelling and knowledge 
representation. The two sides click together at run-time in a very efficient 
and effective way.

This is not refining things away in constraint models.
The fundamental difference is how one deals with modelling or how one uses 
abstraction.

"Abstraction means to strip away the superficial or incidental aspects of a 
thing and to reveal its most important aspects, or essence, aka theory, 
hypotheses. Abstraction is important and can lead to deeper (beyond surface 
understanding ) of things.
Abstraction can also go wrong. There are different ways to abstract. How do 
we test whether our abstractions (theories, hypotheses) are right or wrong?" 
(to quote a good blog: 
http://billkerr2.blogspot.com/2006/08/ascending-from-abstract-to-concrete.html).

The key to using abstraction in theoretical modelling is to understand how 
one can "ascend from the abstract to the concrete." I don't think 
constraining and refining actually play such an important role in the design 
process.

The same blog:

"Marx talked of "ascending from the abstract to the concrete" which on the 
surface can seem rather absurd.
How can a concrete view of reality be superior to a more abstract view? We 
all know that science takes us beyond the surface appearance of things and 
proposes deeper explanations that are not immediately apparent. And anyone 
who has studied child development knows that initially children view the 
world in a "concrete" way and as they become able to think better they 
become capable of thinking more abstractly. So isn't abstract thinking more 
advanced than concrete thinking?
The difficulty arises from confusing the Marxist idea of "the conc

Antw: Sources of information on HL7 EHR/OpenEHR

[Gerard Freriks]

Graham,

Isn 't is a matter of scope, as the thing we need to have agreement  
on first?
Isn 't is a matter of requirements, as the thing we need to have  
agreement on second?
Will the rest of the harmonisation process follow from that?

I think that harmonising two things with substantial different scopes  
and requirements is impossible.

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 653 108732



On 19-sep-2006, at 4:30, Grahame Grieve wrote:

> This will be hard, and painful. And it must involve compromise,
> so this is when we find out who really values collaboration.
>
> And we don't want to take away the real benefits that OpenEHR
> has in the process (same for HL7)

-- next part --
An HTML attachment was scrubbed...
URL: 

Antw: Re: Antw: Sources of information on HL7 EHR/OpenEHR

[williamtfgoos...@cs.com]

In een bericht met de datum 13-9-2006 23:44:53 West-Europa (zomertijd), 
schrijft Thomas.Beale at OceanInformatics.biz:


> 
> 
> The main difference architecturally is that there in openEHR there is a 
> reference model from which software and systems can be built. Archetypes 
> and templates simply designate legal configurations of instances of the 
> reference model. In HL7, the data are instances of schemas that are 
> progressively refined from the RIM. In recent discussions with the 
> designers, they claim that the theory of DIMs, RMIMs etc is based on 
> "relational projections" on the RIM (i.e. that's the basis of attribute 
> "removal"). Anyway, the end result is a schema per message.
> 


Sometimes a set of schema's even to also refer to generic message parts. 
However, once this set of messages per domain is ready, it can be used over and 
over and over. It is stable along clinical domains, as we have proven in 
different projects in the Netherlands. Key is that there is a data 
specification and 
mapping per clinical domain. Here the archetype / templates come into place. 
Once the mapping is made for common data, they can be carried over from one 
clinical domain to the other. E.g. the bloodpressure archetype / template / 
mapping table specification does not differ between domain of stroke care or 
domain 
of general surgery, it is common knowledge and reusable. 

We are currently working on harmonizing the procedures to specify the 
clinical knowledge, to model it once and to use tools to transform between 
OpenEHR, 
HL7 v3 and other technical solutions. 


> Williamtfgoossen at cs.com wrote:
> >
> >
> > on the detailed level the archetypes in CEN 13606 and in HL7 v3 the 
> > templates and R-MIMs for specific care statements,  cover the smallest 
> > molecules of clinical data.
> > examples of the latter can be found at www.zorginformatiemodel.nl
> you can see the openEHR archetypes at 
> http://svn.openehr.org/knowledge/archetypes/dev/index.html
> >
> > A problem with the archetype approach (see the definition of this in 
> > open EHR and 13606) is that it does not address the clinical 
> > vocabulary which is included in HL7 v3 R-MIM approaches and
> > it does not tackle the clinical knowledge base that explains why some 
> > data have to fit together and why a relationship has to be kept. (E.g. 
> > for scientific instruments and scales).
> this is a problem I was unaware of William, can you elaborate with an 
> example?
> 
> 

Yes, it is currently not possible in the archetype editor to define the goal 
of an instrument, have a abstract of the evidence base in the clinical world 
underpinning it, work instructions, interpretation guidelines, references to 
the literature or websites per archetype. It should not be too difficult to add 
this and then it would be useful tool for any standard development once 
Grahame Greave has done his tooling work. 

William
-- next part --
An HTML attachment was scrubbed...
URL: 

Antw: Re: Antw: Sources of information on HL7 EHR/OpenEHR

[Thomas Beale]

Williamtfgoossen at cs.com wrote:
>
> Yes, it is currently not possible in the archetype editor to define 
> the goal of an instrument, have a abstract of the evidence base in the 
> clinical world underpinning it, work instructions, interpretation 
> guidelines, references to the literature or websites per archetype. It 
> should not be too difficult to add this and then it would be useful 
> tool for any standard development once Grahame Greave has done his 
> tooling work.
>

Hi William,

Since I am not 100% sure of the details of what you want to do, I won't 
make any claims yet, but it seems to me that the archetype "description" 
section (i.e. the meta-data in an archetype) is the place where you can 
reference online and other resources (e.g. guidelines, medline content) 
used to build or otherwise related to the archetype. See here for this 
information being displayed in an archetype (it happens that in this 
archetype the "resources" fields are empty, but they are there) - 
http://svn.openehr.org/ref_impl_eiffel/TRUNK/apps/doc/images/description_1.png 
. The meta-data design is based on CEN and CDA meta-data specifications.

Looking at the latest version of the Archetype Editor, it seems that the 
resources fields cannot be edited directly yet - this functionality 
needs to be added. Would this address the need in this area?

As for the "goal of an instrument" - I am not sure what you mean - can 
you explain a bit further?

- thomas

-- 
___
CTO Ocean Informatics (http://www.OceanInformatics.biz)
Research Fellow, University College London (http://www.chime.ucl.ac.uk)
Chair Architectural Review Board, openEHR (http://www.openEHR.org)

Antw: Re: Antw: Re: Antw: Sources of information on HL7 EHR/OpenEHR

[williamtfgoos...@cs.com]

In een bericht met de datum 14-9-2006 20:33:51 West-Europa (zomertijd), 
schrijft Thomas.Beale at OceanInformatics.biz:


> Hi William,
> 
> Since I am not 100% sure of the details of what you want to do, I won't 
> make any claims yet, but it seems to me that the archetype "description" 
> section (i.e. the meta-data in an archetype) is the place where you can 
> reference online and other resources (e.g. guidelines, medline content) 
> used to build or otherwise related to the archetype. See here for this 
> information being displayed in an archetype (it happens that in this 
> archetype the "resources" fields are empty, but they are there) - 
> http://svn.openehr.org/ref_impl_eiffel/TRUNK/apps/doc/images/description_1.pn
> g 
> . The meta-data design is based on CEN and CDA meta-data specifications.
> 
> Looking at the latest version of the Archetype Editor, it seems that the 
> resources fields cannot be edited directly yet - this functionality 
> needs to be added. Would this address the need in this area?
> 
> As for the "goal of an instrument" - I am not sure what you mean - can 
> you explain a bit further?
> 
> - thomas

I know Thomas that we are almost getting there:

It needs indeed to be editable at least when entering the first version and 
then updatable with versions. 

The goal or purpose is the reason why a clinician would use the data, 
instrument, observation in first place: clinical knowledge. E.g. apgar score 
must be 
measured after birth of a baby 1 min, 5 min, 10 min. It is often very obvious, 
but the more we move into detailed clinical area's the less obvisous is gets 
and such functionality allows to trace back the clinical knowledge.

One upcoming project will be to set up the real specified criteria for 
defining the background knowledge of what in next stepp will become an 
archetype / 
synonym.

I have spoken with Sam, Heath and Sebastian Garde on how we can do this. 

Just give us the time to manage it (requirements). 

Thanks,

William
-- next part --
An HTML attachment was scrubbed...
URL: 

Antw: Re: Antw: Re: Antw: Sources of information on HL7 EHR/OpenEHR

[Thomas Beale]

Williamtfgoossen at cs.com wrote:
> In een bericht met de datum 14-9-2006 20:33:51 West-Europa 
> (zomertijd), schrijft Thomas.Beale at OceanInformatics.biz:
>
>
>> Hi William,
>>
>> Since I am not 100% sure of the details of what you want to do, I won't
>> make any claims yet, but it seems to me that the archetype "description"
>> section (i.e. the meta-data in an archetype) is the place where you can
>> reference online and other resources (e.g. guidelines, medline content)
>> used to build or otherwise related to the archetype. See here for this
>> information being displayed in an archetype (it happens that in this
>> archetype the "resources" fields are empty, but they are there) -
>> http://svn.openehr.org/ref_impl_eiffel/TRUNK/apps/doc/images/description_1.png
>>  
>>
>> . The meta-data design is based on CEN and CDA meta-data specifications.
>>
>> Looking at the latest version of the Archetype Editor, it seems that the
>> resources fields cannot be edited directly yet - this functionality
>> needs to be added. Would this address the need in this area?
>>
>> As for the "goal of an instrument" - I am not sure what you mean - can
>> you explain a bit further?
>>
>> - thomas
>
>
> I know Thomas that we are almost getting there:
>
> It needs indeed to be editable at least when entering the first 
> version and then updatable with versions.
>
> The goal or purpose is the reason why a clinician would use the data, 
> instrument, observation in first place: clinical knowledge. E.g. apgar 
> score must be measured after birth of a baby 1 min, 5 min, 10 min. It 
> is often very obvious, but the more we move into detailed clinical 
> area's the less obvisous is gets and such functionality allows to 
> trace back the clinical knowledge.
there are two levels of expression of clinical knowledge, guidelines, 
evidence etc that we can use, namely
a1) guidelines etc that are mentioned in an archetype, and inform the 
design of the archetype. This can be done as I described. In this case, 
the guideline or other knowledge reference is the same for all data 
built from the archetype.
a2) resources that are referenced on a per-archetype basis, but not in 
the archetype, rather they are referenced from the archetype 
classification ontology that indexes archetypes
b) guidelines referenced in data, i.e. on a per instance basis. On the 
model you see here: 
http://www.openehr.org/uml/release-1.0/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html
 
the class CARE_ENTRY has the attributes "protocol" (how / why did I 
create this clinical statement/observation/whatever), "guideline_id" 
that enables the referencing of guideline that caused this Entry to be 
created (e.g. maybe some guideline told the doc to measure the BP and 
also ask questions about smoking); ENTRY.workflow_id may also be 
relevant, for Entries created due to workflow execution.

I would think these go close to supporting today's requirements in this 
area, although I realise we cannot predict the requirements of the future...
>
> One upcoming project will be to set up the real specified criteria for 
> defining the background knowledge of what in next stepp will become an 
> archetype / synonym.
>
> I have spoken with Sam, Heath and Sebastian Garde on how we can do this.
>
> Just give us the time to manage it (requirements).
yes, of course - this is clearly an emerging area for the medical 
peoplemaybe you will have more requirements for the models one day...

- thomas

Antw: Re: Antw: Re: Antw: Re: Antw: Sources of information on HL7 EHR/OpenEHR

[williamtfgoos...@cs.com]

In een bericht met de datum 14-9-2006 22:22:42 West-Europa (zomertijd), 
schrijft Thomas.Beale at OceanInformatics.biz:


> there are two levels of expression of clinical knowledge, guidelines, 
> evidence etc that we can use, namely
> a1) guidelines etc that are mentioned in an archetype, and inform the 
> design of the archetype. This can be done as I described. In this case, 
> the guideline or other knowledge reference is the same for all data 
> built from the archetype.
> a2) resources that are referenced on a per-archetype basis, but not in 
> the archetype, rather they are referenced from the archetype 
> classification ontology that indexes archetypes
> b) guidelines referenced in data, i.e. on a per instance basis. On the 
> model you see here: 
> http://www.openehr.org/uml/release-1.0/Browsable/_9_0_76d0249_1109249648736_8
> 72559_12384Report.html 
> the class CARE_ENTRY has the attributes "protocol" (how / why did I 
> create this clinical statement/observation/whatever), "guideline_id" 
> that enables the referencing of guideline that caused this Entry to be 
> created (e.g. maybe some guideline told the doc to measure the BP and 
> also ask questions about smoking); ENTRY.workflow_id may also be 
> relevant, for Entries created due to workflow execution.
> 
> I would think these go close to supporting today's requirements in this 
> area, although I realise we cannot predict the requirements of the future...

Yes, this is indeed what we need, I do like b also very much, have not 
thought of this in this way due we use the moodcode dynamics and care plan 
R-MIM. 
Key in that is that we do what you express in b: explain that something (an 
observation) from the guideline goes into the careplan because the patient 
meets 
the criteria for it and the clinician determines to follow this. 

Moving to 'independent' modeling with the new tools will sort all these 
clinical materials out and allow both expression of knowledge and of workflow 
and 
of the result of resoning :-) 

thanks again,

William
-- next part --
An HTML attachment was scrubbed...
URL: