Link between goals and other clinical concepts

Bert Verhees bert.verhees at
Wed Jun 25 15:56:31 EDT 2014

> The Composition class is defined in 13606 and openEHR to do one job - 
> act as a container for data captured during the same health event. It 
> doesn't do all jobs. There is no reason we would not add other classes 
> in the future to openEHR to handle other general categories of data, 
> either at a similar level as Composition, or finer levels - just like 
> we would add a new data type if we need it.

This is exactly the problem why I mention it. Because OpenEHR is in the 
RM, and not in archetypes, people using it, must wait for you or others 
to add a new class. It makes them dependent. At that moment, they 
experience an information-lock-in.

There is another problem also, because OpenEHR as RM guarantees to 
remain backwards compatible, it cannot remove classes from the RM.
This means there must be some provision to handle redundancy in 
data-definition which can occur when new classes are added. Redundancy 
means, more paths to store data of the same semantic meaning. The start 
of big trouble.

I learned a lesson, a long time ago, and I see that this is still a 
valuable lesson.The lesson was: Never put semantics in the database 
design, put it in the data.
(it is an often made mistake to ignore this lesson)

I think more or less it can be applied to this discussion.
You can in analogy regard the Reference Model as database-design and the 
archetypes as semantics to explain the data.
The big trouble which can occur in redundancy in data-definition is 
because of having semantics in database-definition level.

I am still not aware of a good reason to create a semantic rich RM, 
while there are enough possibilities to link the data to the semantics 
via archetypes.

>> You could also model the OpenEHR information model, which now resides 
>> in the reference model, in such constructed archetype/template-based 
>> information model, using only structure-based archetypes.
> well, you could get some way. Developers like the structures in 
> Observation and Action and Instruction, because they can be programmed 
> once in Java, Ruby, Python, C#, ... etc and they just work. No 
> archetypes to worry about there, and yet they take care of a lot of 
> quite complex data like differential time-series, multi-drug orders 
> and so on.

Information must be the purpose of an EHR-definiton, not solving 

In my case, f.e., I don't even have classes representing a Reference 
Model. I don't need them. Archetypes are the thing I worry about. Data 
must conform the constraints in the RM and in the archetypes.
For my kernel it is the same if a dataset represents an ItemTable, an 
Observation or a Person.
They are treated the same way,
- they are validated on XMLSchema ((RM-validation) f.e. an Observation 
cannot live on its own)
- and on Schematron (archetype-validation)
- and stored as XML,
- and can be queried by AQL or XPath/XQuery.

Maybe this was a problem in the year 2004, in that time we saw all 
developers mimicking the Reference Model in class-schema's of their 
favorite language. Me too, but not anymore.
So you solved a problem that I do not have.

Do other people have this problem? Are they relying on RM-classes to 
process datasets?

> If you try to replicate all those details as reference archetypes, 
> you'll get some of it done, but since you can't create generic 
> (templated) types or use multiple inheritance (at this stage, at 
> least) in ADL/AOM, there are going to be limitations. Solving that 
> means upgrading ADL to have the power of a language like C++. I'm not 
> sure if that's what we should be doing.

I am not sure about this, I don't see the multiple inheritance.

As I see it on a quick glance (just an idea), there must be 
base-archetypes, a base archetype would represent the base class 
structures, as you can find them now in the RM.
I think a new attribute would be needed to the CComplexObject-items. It 
would be the attribute rmtype.
Like this
ITEM_LIST[archetype_node_id=at0001, rmtype="COMPOSITION"] matches .......
etc etc

This is no problem in using attributes because they are easy to query. 
The kernel now also relies on the attribute archetype_node_id=at0001, 
without any problem.

> Right now, displaying a time-series of heart rate v treadmill speed 
> over 15 mins is dead simple in openEHR - the data structures are all 
> there. Doing that in even 13606 requires:
>   * defining reference archetypes for time-series data, where the
>     events can have secondary state i.e. each event has a primary
>     datum like heart rate, and 'state' data like exertion (treadmill
>     speed)
>   * writing software that knows how to transpose the Cluster/Element
>     structures into a logical time-series, and figure out what is the
>     main datum, what is the state, what are the widths of every event
>     and so on
>       o remember, there won't be any Java / Ruby / Python /.. classes
>         to do this - you have to do it all manually.

I don't understand why you bring up this subject.

I stated a few times that OpenEHR is a fine information model, and maybe 
there are some difficulties in EN13606, that may be true.
I also wrote that designing medical information models is not my specialty.
So I will not easy say about an medical information model if it is good 
or bad. I can only judge it on basic-design-rules.

The point is that you don't have to choose if you use generic kernel.
You can use multiple in archetypes-based reference models to validate 
and store and query data. You can allow certain parts of an healthcare 
organization, without any technical provision, to implement new ideas 
about medical data structures, maybe necessary for specific treatment.

As I see the battle-field of medical information model-designers, the 
war is not over yet, and it will never be. There will be great ideas 
which need an own Reference Model.

Being prepared for that is a good thing.

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-clinical mailing list