Link between goals and other clinical concepts

Bert Verhees bert.verhees at
Fri Jun 27 06:09:58 EDT 2014

On 26-06-14 10:16, Diego Boscá wrote:
> Well, I would say that deciding what's in and what's out of the
> reference model can be tricky sometimes. If we assume that clinical
> knowledge evolves (one of the basis of dual model approach) isn't safe
> to say that the less clinical knowledge we put in the reference model
> the better?

Hi Diego, I tend to agree on this. Because if you want a stable 
data-definition, you must be prepared for changes in thinking.
There will, however, always be some basic structures left.

A medical information model must be patient/EHR centric. All data must 
belong to a patient.
This is typical for an information system for storing medical data.

13606 was not such a system. 13606 is, in my opinion, in fact 
(and a not archetypeable demographic section, I don't understand the 
purpose of that).

13606 was a message format, and demographic data (if medical relevant to 
a specific Composition) should be an entry of a Composition.
The patient, a number in the EHR-Extract was just a carrier of related 
medical circumstances.
An EHR-message was, per definition limited in scope.
The scope was a medical circumstance that was wished to communicate, 
together with the patientID in which this circumstance lived.

I believe, I have heard, this is going to change. 13606 will become an 
information system for storing medical data with a minimalistic structure.

Since quite some time, I implemented a multiple RM-kernel.
Now I see, it is also because it can be used to serve several different 
medical information structure philosophies, as long as they are Patient 

13606 will have a more important role because of its minimalistic 
Organizations which want to implement information-standards now have 
tooling and a minimalistic Reference Model to do so.
For some ideas, 13606 will not fit, and a new Reference Model will need 
to be written.

I think that the Reference Model will loose some of its status.
Was it before the foundation of a software-structure, with a lot of 
classes to support, it now becomes more and more just an interchangeable 
information definition.

Now the LinkEHR editor change to RM-pluggable editor, and we have a 
complete new medical information use.
The customer, not depending on the vendor, can create or choose an 
information model.

We'll see if this is true, and if, where it ends.


> You can always define reusable patterns to be applied over the
> archetypes, but these patterns itself can be evolved (just in case you
> feel that some day event series could be represented in any other way,
> for example). At the end, an Observation is an specialization of Entry
> class with some structures already available for you to use.
> 2014-06-26 9:57 GMT+02:00 Thomas Beale <thomas.beale at>:
>> On 26/06/2014 08:33, Bert Verhees wrote:
>> 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.
>> sure, but like I said, this is just the same problem moved up one level. At
>> some point, you still have to write classes with the semantics of things
>> like Observation or Composition or whatever.  Otherwise you can't get the
>> data on the screen, or compute with it in any meaningful way.
>> I think this can be solved with templates and information which can be in
>> the archetype-meta-data. Don't you agree? What am I missing?
>> example: this structure is inside an openEHR OBSERVATION, and most
>> implementations use full Java/C#/other implementations of these classes.
>> That enables you to do things like handle openEHR OBSERVATION data
>> representing time series from a device natively, including varying
>> periodicity, varying sample widths, and varying math functions (max, min,
>> ave etc). This makes it very easy for an implementer to get time-based data
>> from an EHR and populate a screen graph widget.
>> Without any of this built in, e.g. as in 13606, CDA, or other models, you
>> have no guarantee that this kind of data (very common you will appreciate)
>> is even represented in a standard way, nor do you have any classes to
>> process it with. You have to assume that each CDA or 13606 data source has
>> its own representation of such data, and build N implementations to deal
>> with it. For openEHR implementers, openEHR is the target data, so we convert
>> data into openEHR, which is a higher-fidelity format, and the problems go
>> away. You could potentially convert them into a sort of standardised 13606,
>> representing the same thing but then you'd still have to build your own
>> classes to implement time-based data rather than re-use the standard classes
>> everyone else uses. I don't see the point. Especially as openEHR has AQL.
>> Now, there are things that are not actually in openEHR, that you might want.
>> So you can take the 'reference archetype' approach to that, and build local
>> classes. But you might as well still use openEHR as 13606 or CDA as the
>> basis, since you will get more for free - if you make your local native
>> format something completely custom, then there is no community or software
>> you can use - you have to build everything yourself.
>> - thomas
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at

More information about the openEHR-clinical mailing list