Link between goals and other clinical concepts

Thomas Beale thomas.beale at
Wed Jun 25 08:48:16 EDT 2014

On 25/06/2014 00:53, Bert Verhees wrote:
> Hi Hugh,
> It is indeed a discussion which runs for several years.
> I mentioned 13606 but it can also be done in OpenEHR. OpenEHR also has 
> lists, trees, clusters, elements, all derived from Locatable, thus 
> archetypeable.
> So you can define (what I call) an information model, based on the 
> generic structures in OpenEHR.
> Say you want to conform to HISA, is that possible in the 
> Composition-package? I am not sure, I read it once, some years ago, 
> and I saw some problems, say (imagine) HISA will conform more in 
> direction of ContSys, how do you handle this in the OpenEHR 
> composition-package, and we all know, it will not stop there. It is an 
> illusion to think that an information model will last for ever.
> Maybe there are concurring information models, maybe you want a kernel 
> to support more, simultaneously, maybe you want to write an API to a 
> specific information model?
> Imagine HL7, for example, VMR,  based on archetypes? I once did that, 
> for a customer. I did not write an API for that, just the archetypes, 
> but I could write an API for that.
> I am afraid you will find the composition package restrictive. It 
> represents a good information-model, as far as I can judge (it is not 
> my specialty), but is just AN information model. There can be more 
> which are good too.
> That is why I think, semantics do not belong in the reference model, 
> but in a constructed archetype/template-based information model.

well there are always 'semantics' in an information model, no matter how 
generic. It's just a question of how specific. The DvQuantity class has 
some very general semantics, which most people accept, and which can be 
mostly converted in and out of PQ and other 'competing' types.

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.

> 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.

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.

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.

How do you know whether a Cluster/Element structure is even representing 
this kind of data? What if some data source has tried to generate a 
Cluster/Element representation of time-series data, but in a different 
way than what you have assumed? That means you having to have another 
kind of code to deal with that way of arranging the data.

I can make the same argument for Instructions and Actions.

Now you might say: well, it's a job for 13606 to define reference 
archetypes for all that, and force everyone to be the same. But then you 
might as well add these classes to the RM (still preserving the generic 
ENTRY class), and make life easier for everyone.

The one thing we did not do very successfully in openEHR is to preserve 
the generic form of ENTRY; this is what let's the 'thousand flowers 
bloom', but doesn't prevent proper reference structures being in the RM 
either. In the near future we will fix this.

- thomas

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

More information about the openEHR-clinical mailing list