openEHR and CEN models

Technical (archive)
1

Hi

I hope its all right to ask a few standards related question on this forum.

I wanted to know how different the openEHR and CEN Ref Models and
Archetypes are from each other at a logical level. Is it necessary to
understand the CEN stds if working with openEHR stds? In particular, is
it important to know the CEN13606 archetypes if working with openEHR
archetypes. At a logical level what are the differences between the two?

Another topic area that alludes my understanding is a clear
parallel/possible relationship of HL7 Templates and the use of
'templates' in openEHR archetypes (the later concept I am very clear
about.. its the HL7 view of templates Im not sure of). It'll just help
in my understanding of hl7 templates w.r.t. archetypes, as parallels are
often drawn between the two.

Will look forward to responses.

Many thanks
Rahil

2

Hi Rahil,

Rahil Qamar wrote:

Hi

I hope its all right to ask a few standards related question on this forum.

I wanted to know how different the openEHR and CEN Ref Models and
Archetypes are from each other at a logical level. Is it necessary to
understand the CEN stds if working with openEHR stds?

Depends on what you want to do :wink: In the near future, the automatic
bidirectional transformation for openEHR/CEN will be completed (when CEN
works out what data types it is using). This will mean openEHR tools
will be able to generate CEN structures automatically. It may be worth
looking at the openEHR EHR Extract specification as well. This is not
yet finished, but will offer significantly more power than the CEN
Extract, while containing a CEN-like mode to act as a wrapper for
CEN-encoded information.

In particular, is
it important to know the CEN13606 archetypes if working with openEHR
archetypes. At a logical level what are the differences between the two?
  

others may know better, but at the moment I don't know of any CEN
archetypes.

Another topic area that alludes my understanding is a clear
parallel/possible relationship of HL7 Templates and the use of
'templates' in openEHR archetypes (the later concept I am very clear
about.. its the HL7 view of templates Im not sure of). It'll just help
in my understanding of hl7 templates w.r.t. archetypes, as parallels are
often drawn between the two.
  

We would like to know that as well :wink: What I know at this stage is that
an HL7 template is a specialised XML-schema of a base XML-schema such as
the CDA schema. There is no distinction in HL7 that I know of between
what we call archetypes and templates in openEHR. At the best, you would
have to say that an HL7 template is like an openEHR template that is
built like an archetype, i.e. no re-use of anything, just a single giant
archetype built for the particular purpose at hand (which would normally
make us call it a template...)...

- thomas beale

3

Hi Thomas

Thanks for the response.

Thomas Beale wrote:

Depends on what you want to do :wink:

Well we're looking at authoring openEHR Archetypes to seve as a standard form for representing clinical data for capture through templates (not the HL7 ones!). With people often confusing the openEHR approach with the CEN13606 work (and using them almost interchangeably), I wanted to make sure we're not going off on a tangent.

In the near future, the automatic bidirectional transformation for openEHR/CEN will be completed (when CEN works out what data types it is using). This will mean openEHR tools will be able to generate CEN structures automatically. It may be worth looking at the openEHR EHR Extract specification as well. This is not yet finished, but will offer significantly more power than the CEN Extract, while containing a CEN-like mode to act as a wrapper for CEN-encoded information.

Ive downloaded the EHR Extract document. Just wanted to know exactly what this document will be beneficial for - are the Extracts to be used for sending relevant parts of the EHR data (or perhaps model) based on the user query? Does the document prescribe the format in which the extracts will be returned to the user or do they prescribe the query syntax or is it just a logical representation of how the Extracts relate to the EHR Information Model?

In particular, is it important to know the CEN13606 archetypes if working with openEHR archetypes. At a logical level what are the differences between the two?
  
others may know better, but at the moment I don't know of any CEN archetypes.

Thats a useful piece of info. Ill look for more responses on this issue then.

Another topic area that alludes my understanding is a clear parallel/possible relationship of HL7 Templates and the use of 'templates' in openEHR archetypes (the later concept I am very clear about.. its the HL7 view of templates Im not sure of). It'll just help in my understanding of hl7 templates w.r.t. archetypes, as parallels are often drawn between the two.
  
We would like to know that as well :wink: What I know at this stage is that an HL7 template is a specialised XML-schema of a base XML-schema such as the CDA schema. There is no distinction in HL7 that I know of between what we call archetypes and templates in openEHR. At the best, you would have to say that an HL7 template is like an openEHR template that is built like an archetype, i.e. no re-use of anything, just a single giant archetype built for the particular purpose at hand (which would normally make us call it a template...)...

And I thought only I was confused :). But I think your view of what the HL7 templates are is the closest Ive got to receiving a clear explanation ! I had a guy show me how the Templates can be extracted from the CDA models .. at the end I was even more confused ! .. Ill revisit the hl7 templates work with this new understanding.

Thanks a lot
Rahil

4

Hi Tom, Rahil

But I think your view of what the HL7 templates are is the closest Ive got

to receiving a clear explanation !

There has to be a better way to explain HL7 Templates than that. I'll give
it a shot.

Consider that an HL7 model (an "RMIM") is analogous to an openEHR archetype.
It's a bunch of classes that represent healthcare data.

When you start with an existing RMIM (call it "R") and create a list of
extra constraints upon it, that set of restrictions is a "template" on the
original model.

A template in HL7 speak is therefore a set of constraints, and it can be
applied on top of model R or some other model.

By constraint I mean things like: "only allow SNOMED", "only allow class A
and not class B", "allow max 2 of A".

Templates are a neat way to foster re-use of R, because they package up all
the refinements and improvements you may want on R, but only those extra
rules need be in the template - just the differences. You don't put the rest
of R in there.

Hence you don't need to keep cloning R over and over in order to re-use it
with just slight variations. That would proliferate objects and give you a
maintenance headache.

So what does an HL7 template look like? There is flexibility in how the
actual list of constraints is represented.

It can be a diagram, itself pretty similar to an RMIM, or it can be a formal
document that makes a series of assertions that must be heeded. Techniques
have been developed to turn both of these into executable checks.

In some cases these checks take the form of XSD, but it is not correct to
say that templates are in themselves XML schemas. You can also do the checks
with schematron, or any other validation technique you choose.

Does that help at all?

As far as I'm aware there is no HL7 equivalent of openEHR templates (and I'm
not sure there is an openEHR equivalent of what HL7 calls templates either).
An HL7 template is a "model of constraints" that goes along with another
model.

cheers,
Rik

5

Thanks Rik. That was extremely useful.

Its very interesting to see how HL7 has separated ‘constraints’ from the actual ‘data’. It seems like templates (lets call them T) could be a set of cardinality constraints, value constraints, or terminology constraints, among other things. Except for the terminology constraints, its difficult to understand how the cardinality and value constraints are added to R separately. So what does the base data in R look like without the T info? Id think then that although theoretically the approach is very neat, in practice, however, T will always be a part of R. Can I assume R to be a CDA document? What other form in HL7 can R assume besides CDA docs?

Now assuming Im wrong and infact practically T is not always part of R (although T can be reused in several R’s), is there a formal model to which T conforms structurally and semantically? In other words, structurally is there some RIM version specifically desgined to model T. Also semantically is there some sort of ontology that states that in this particular clinical scenario R needs to have these set of T?

I finally seem to be getting ahead with my understanding of templates, so am very keen to go ahead with this discussion.

Kind regards
Rahil

Rik Smithies wrote:

6

Hi Rahil

Except for the terminology constraints, its difficult to understand how the cardinality and value constraints are added to R separately.

yes, that was the tricky bit :wink:

You end up with 2 models, and need a way to apply one model on top of another. The tools you use to validate that you have an R can be modified to validate that it is also an R+T. Once you realise that R and T are both actually constraints of other models you are there.

So what does the base data in R look like without the T info?

R already has lots of assertions and constraints in. R stands alone, and may exist for years before T comes along. (I’m assuming you mean the model data, rather than the instance data.)

Can I assume R to be a CDA document? What other form in HL7 can R assume besides CDA docs?

Yes R is commonly CDA, but R can be any model. In less widely used models than CDA, repeated re-use may not be so much of an issue. If you are the only people to use R you may just make a model R2 is that is a clone but with more constraints modelled right in it, and stop there, no need for T.

What other form in HL7 can R assume besides CDA docs?
T could be a template on the Clinical Statement model, and then it could be applied to models based on that pattern.

It is true that any fairly complex T will be closely bound to R. An assertion always has a context. Finding the right granularity of re-use is hard in any domain, but some constraints could be very simple and could apply to various models.

structurally is there some RIM version specifically desgined to model T.
T can only assert things that are allowed in HL7 of course. R+T must be a valid model. There is no other base model for T than the RIM. But T isn’t really RIM stuff, its more “constraint on RIM stuff”.

“Cardinality <= 2” isn’t in the RIM of course, it’s something that applies to a RIM based model.

I suppose I should stress again that there is no new RIM here, no new reference model, its just that there are multiple RIM-model instances or RIM-constraints applied together. All the bits that make up templates already exist, it’s just a new application of them, and maybe some modified tooling.

Also semantically is there some sort of ontology that states that in this particular clinical scenario R needs to have these set of T?

Not an ontology perhaps, but is is getting common for people to start with some R and make a series of templates that need to be used (by their requirements) when using R in a certain clinical domain. NHS CFH for instance have some 50 odd templates that they use in various combinations on CDA to create CDA flavours for a half dozen or so domains.

glad to help,
Rik

7

Rik Smithies wrote:

Hi Tom, Rahil

Templates are a neat way to foster re-use of R, because they package up all
the refinements and improvements you may want on R, but only those extra
rules need be in the template - just the differences. You don't put the rest
of R in there.
  

this approach to representation is what is used by openEHR archetypes
and templates although in slightly different ways.

Hence you don't need to keep cloning R over and over in order to re-use it
with just slight variations. That would proliferate objects and give you a
maintenance headache.
  

But this only gives a basic level of re-use - reuse of the whole RMIM.

As far as I'm aware there is no HL7 equivalent of openEHR templates (and I'm
not sure there is an openEHR equivalent of what HL7 calls templates either).
An HL7 template is a "model of constraints" that goes along with another
model.

well, that's what an archetype is, and a template is. But the semantics
are different. The set of constraints in an archetype are constraints
for representing content to do with a particular topic, regardless of
contextual use. Such as BP measurement, diagnosis, etc. This provides a
level of definition where clinicians can define how to record all data
points to do with a particular subject, regardless of where such data
points might need to be recorded in the business process.

OpenEHR templates provide a way to combine and further constrain the
data points expressed in archetypes, in chunks or groups corresponding
to context of use, i.e. screens, reports or some other grouping that
correspnds to a business process step. There are many forms for example
that will capture vital signs, so you need a place to define all the
data points of the vital signs - the archetypes.

The reason HL7 doesn't do this is because the RMIM is already dedicated
to a particular topic, like lab observation or whatever. However, unlike
in openEHR, an RMIM is a new schema, 'derived' from the RIM - but
nevertheless a new schema. In HL7 speak, it is a data 'projection', i.e.
a selection of certain attributes from various classes in the RIM, plus
cloning.

So HL7v3 is constructed as follows (simplifying the DIM/RMIM/CMET business):

1 RIM -> N derived schemas (RMIMs) -> M templates per RMIM. i.e N
systems of 1 schema + M templates.

openEHR is constructed as:

1 Reference Model -> N archetypes -> M templates, which are N:N with
archetypes (but more numerous). This gives a system with a single schema
- the reference model - and 2 further levels of constraining which allow
topic-based deifnition and then context/business event specific
definition. But in the end all the information is just instances of the
reference model; in HL7, each message (RMIM) has its own instances,
because each is a different schema.

- thomas beale

8

Hi Rik

Thanks for the explanation. It is of course a lot to take in so I was wondering whether you could email an example of an R and T as a UML diagram.

Rik Smithies wrote:

What other form in HL7 can R assume besides CDA docs?
T could be a template on the Clinical Statement model, and then it could be applied to models based on that pattern.

One more thing, what is a clinical statement model. Is it a CDA or something else? Also if further T’s are applied to a model (say T1), does the original T become a part of R or does it still retain its individuality such that R + T + T1 is as valid as R + T1 (without T).

Thanks a lot
Rahil

9

Hi Tom

The reason HL7 doesn't do this is because the RMIM is already
dedicated to a particular topic, like lab observation or
whatever.

When you consider that an RMIM, a CMET and an HL7 graphical template are all
basically the same thing, the granularity issue you mention doesn't apply. A
single model can be used as any one of these [for those unfamiliar, an RMIM
is a largish HL7 model, and a CMET is a smallish one, intended to be a
component].

The set of constraints in an archetype are constraints for representing

content to do with

a particular topic, regardless of contextual use. Such as BP
measurement, diagnosis, etc.

HL7 models can and commonly do have this level of granularity.

What are generally called RMIMs perhaps typically don't, but a small "RMIM"
model could be just such a BP measurement - a component in other words. It
would generally be called a CMET or template but the model is exactly the
same despite the name.

These components are assembled into other models (which would perhaps be
called full RMIMs, but could be other templates or CMETs), and this seems
like the assembly of archetypes into openEHR templates.

The larger model could correspond to a single report or business step just
as with the openEHR template. (There is no UI aspect inherent to them, but
nothing to stop a system rendering the model as an input screen.)

However, unlike in openEHR, an RMIM is a new schema, 'derived' from the RIM

- but nevertheless a new

schema.

This is obviously true to a degree since any HL7 model has a unique
validation schema that checks that an instance or a fragment conforms.

But all models are actually expressed in the single RIM schema, since even
in instances, where you can have unique class names (eg ObservationSystolic,
ObservationDiastolic) the RIM class is indicated via structural codes eg
"classCode='OBS'".

HL7 templates can be applied to these uniquely named classes even though the
template has different class names (in fact normally the RMIM has the
plainer names, and the graphical HL7 template the specialised ones).

Templates are thus not tied to single RMIMs and so not to a single topic.

cheers,
Rik

10

The best way to look at this, following Tom’s example of

1 RIM => N archetypes and M templates in OpenEHR is to look at HL7 v3 Care Provision (CP) or CDA or Clinical statement.

Here I agree fully with Rik’s comments.

v3 Care Provision, CDA and Clinical Statement have a Domain Message Information Model that serve exactly the same purpose as the RIM in OpenEHR: the basic and unchanged model against which all detailed clinical content is modeled.

Several R-MIMs are produced from this to cover the dynamics of continuity of care (referrral, acceptance, query, record exchange).

There is a fixed set of XML schema’s for each of these R-MIMs.

As Rik explaines: within the R-MIMs there is an option for nested R-MIMs. Each of these smaller R-MIMs are clinically a 100% match to an archetype in OpenEHR (variations are clinically necessary variations e.g. to population or age groups). Technically it does work a little different. These small R-MIMs go into the choice box, that allows clinicians 100% freedom about what to include in the message. The full XML remains the same, but at the start of choicebox XML until the end of choicebox XML one can enter 1 - N small R-MIMs, each of which adheres to a pattern, e.g. the vital sign pattern, a common observation pattern, an assessment scale pattern. This pattern leads to XML small blobs, similar to archetype XML, and can be insterted in the specific message XML.

At this stage we have been testing the Care Provision model for
perinatology continuity of care and national statistics: no limits for > 300 data items and constructs
juvenile care, youth at risk: no limits for > 1000 data items
stroke care, . 1200 items, no limits in message
diabetes care, work in progress, no limits found at this stage
elderly care in 2 projects, > 1500 items, no limits
To a large number the items are composite data items, e.g. representing assessment scales like Apgar, Barthel, MMSE and such. Others are very complex growth and development measures, not summated, but a complex overview of motor, physical, psychosocial growth and development, measured from age 1 week until age 18 years. All match the pattern and can be developed in user interfaces and included in the CP message.
mental health by GP and social worker > 50 items, no limits, however consent needed to be included explicitly.

So I think the only points that are valid are that the technical implementation is different, and that the archetype build up is mostly done top down.

relationship between small R-MIMs are done via the Organizer class in HL7, allowing any linkage to each other, exactly as is done with archetypes and templates in OpenEHR.

These many similarities make me move to a technology independed way of modeling with the detailed clinical model approach.

Sincerely yours,

dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
email: Results4Care@cs.com
phone + 31654614458
fax +3133 2570169
Dutch Chamber of Commerce number: 32121206

11

Williamtfgoossen@cs.com wrote:

relationship between small R-MIMs are done via the Organizer class in
HL7, allowing any linkage to each other, exactly as is done with
archetypes and templates in OpenEHR.

Hi William,

this is new to me. Are you saying that you can create an artefact in HL7
that reuses specific data elements from archetypes, which are themselves
hierarchically nested (due to the structure of the RM)? E.g. if a BP
RMIM had possibilities for {baseline, 5 min, 10 min, 1hr, 4hr} X
{actual, max, min, avg} X {systolic, diatolic, ... + patient position,
exercise, ...} that you can then build a 'template' that chooses only
(say) 5min actual value for systolic diastolic, and poisition? All
within a (say) vital signs Section structure of which only some headings
are chosen, and all that within (say) a GP contact Composition? I am
interested to know how Organisers do that...

- thomas

12

Hi Rik,

Rik Smithies wrote:

HL7 models can and commonly do have this level of granularity.

What are generally called RMIMs perhaps typically don't, but a small "RMIM"
model could be just such a BP measurement - a component in other words. It
would generally be called a CMET or template but the model is exactly the
same despite the name.

These components are assembled into other models (which would perhaps be
called full RMIMs, but could be other templates or CMETs), and this seems
like the assembly of archetypes into openEHR templates.
  

well - one of the main functions of a template is to choose what is
needed from the archetypes. Let's say a template 'assembles' 5
archetypes each with (for the sake of example) 50 possible data points
(note that even the BP archetype can generate 100s of data points), then
the total potential number of data points is 250. But the template might
choose just 10, say 2 from each archetype, according to the needs of the
business process step corresponding to the data capture being modelled
by the template.

This is obviously true to a degree since any HL7 model has a unique
validation schema that checks that an instance or a fragment conforms.

But all models are actually expressed in the single RIM schema, since even
in instances, where you can have unique class names (eg ObservationSystolic,
ObservationDiastolic) the RIM class is indicated via structural codes eg
"classCode='OBS'".
  

yes, but the semantics of each such variant class are different from the
parent - various attributes have been removed etc. I had all this
explained to me a year ago by Gunther Sshadow in no uncertain terms -
hsi explanation was that each such variant class is a 'projection' on
the RIM parent class, which contains all possible attributes (aka
columns) needed by that class. So any variant 'class' is actually more
like the SELECT a,c,e,g part of the SQL statement SELECT a,c,e,g FROM
Observation, where we assume that Observation is a table/class with
columns/attributes a,b,c,d,e,f,.... Needless to say, such semantics pose
all kinds of problems for object-oriented software engineering (having
to know all the properties of a superclass in advance, for a start).

HL7 templates can be applied to these uniquely named classes even though the
template has different class names (in fact normally the RMIM has the
plainer names, and the graphical HL7 template the specialised ones).

Templates are thus not tied to single RMIMs and so not to a single topic.
  

so a single HL7 template might only have the scope of a single (variant)
class inside an RMIM?

- thomas

13

In een bericht met de datum 12-12-2007 11:52:14 West-Europa (standaardtijd), schrijft thomas.beale@oceaninformatics.com:

Hi William,

this is new to me. Are you saying that you can create an artefact in HL7
that reuses specific data elements from archetypes, which are themselves
hierarchically nested (due to the structure of the RM)? E.g. if a BP
RMIM had possibilities for {baseline, 5 min, 10 min, 1hr, 4hr} X
{actual, max, min, avg} X {systolic, diatolic, … + patient position,
exercise, …} that you can then build a ‘template’ that chooses only
(say) 5min actual value for systolic diastolic, and poisition? All
within a (say) vital signs Section structure of which only some headings
are chosen, and all that within (say) a GP contact Composition? I am
interested to know how Organisers do that…

  • thomas

BP measures at baseline, 5 min, 10 min, 1 hr, 4 hr are each small molecules composed of discrete observations (sys / dias / position / cuff / excercise). The suggested examples base, 5, 10, 1hr etc go in the RMIM “Lists”
You can set any limit or expansion.

A CP “list Act” keeps those OBS or Acts together that a clinician chooses.
This is useable with CDA, Care provision and clinical statement (at this time).

It is possible in the time attribute to determine start time, end time, width and so on to select particular times as you suggest above.

It is possible in the value attribute to determine start max and min value to select particular values of BP (e.g with pregnancy a key variable for referral is a maximum diastolic BP > 95 mm HG).

In in an additional observation class for body position it can be made explicit as value what the position is (in the current R-MIM for blood pressure).

Excercise is not in the R-MIM but can be instantiated and related via the component relationship in the Choice box. Again, would use a value to express the excersice. Vocab could be chosen from Snomed CT or local. This vocab could also be made such that position is excercising is part of the value set, some choice here similar to archetyping.

If you need a calculation you make another OBS that has the derivation expression such that the algorythm or mathematic is expressed and that the value resulting from the mathematic can be entered (e.g. the sum score of an Apgar, or in the BP case the average value). This can be linked to the above list of predetermined timing.

“Template” as you define it above can be used as follows:

Define the R-MIM blood pressure plus all additional you / clinician want(s).
Query the data based on this to select only the parameters you want (time, max, width)

If you want to see this in the section vital signs, you “hang” the organiser Act to the BP and link BP to the vitals section.
If the vitals section is again part of a specified contact, it can be nested via the organiser to this part. ( I mean the larger section is nested into vitals section is nested into BP is nested into 4 discrete observations)/

I would however suggest to apply the List of GP contacts and link the BP results you want: so a list A GP contacts related to List B specified set of BP.

This is how we have modeled it several times and it has been used as structure behind e.g. the EPD in Nijmegen and the stroke system by Portavita. Still more validation work necessary though!

Hope this clarifies why I consistently say that the approach RIM - archetype - OE templates does not differ methodically from CP D-MIM - care information model as specified RMIM for clinical detailed stuff to template is organising single OBS into lists or groupings.

Sincerely yours,

dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
email: Results4Care@cs.com
phone + 31654614458
fax +3133 2570169
Dutch Chamber of Commerce number: 32121206

14

Hi Tom,

bit tardy getting back to this thread I'm afraid, but just to come back on a
couple of those points:

well - one of the main functions of a template is to choose
what is needed from the archetypes. Let's say a template
'assembles' 5 archetypes each with ...
50 possible data points...then the total potential
number of data points is 250. But the template might choose
just 10, say 2 from each archetype, according to the needs of
the business process step corresponding to the data capture
being modelled by the template.

That’s fine, you can build one model from others in V3 modelling. Once you
can constrain one model to another, and build models out of others, you can
do what you like. HL7 just doesn’t have two well established words for the
small bits and the big bits, or the constraining down and the assembling
back up. Maybe the granularity differs a little too.

yes, but the semantics of each such variant class are
different from the parent - various attributes have been
removed etc.

The semantics of the variants aren't really different though. If you can
cope with an A that has an optional property X that is any code, you can
cope with a constraint to B that is mandated to always have an X that is
always "123".

In particular, the fact that is has a new name 'B' adds no semantic meaning
at all. It's really just a nameless "classCode=OBS, code=123".

HL7 templates don't add semantics to instances either.

The template (or any model) is just a specification of what you want to be
assembled as the data elements. The XML doesn’t say "this is a BP template,
and you need to go and look up what that means". The template just says
"when creating a BP, do it like this (and we'll know if you don’t...)".

The template is useful because it can show illustrate to people that a BP is
made up of systolic and diastolic and other stuff. So people know what to
build, or what to collect on a screen. But they don’t put a template in the
instance. They put observation classes in it that happen to match what it
says in the template.

so a single HL7 template might only have the scope of a
single (variant) class inside an RMIM?

Absolutely. Any model can be a template, and a model can one or a hundred
classes. Non graphical templates can be a single assertion (though they
aren't the main trust of this thread).

Actually, reading again, I think you may possibly mean: can a template can
be applied to a single class in an RMIM? You can do that also. A template
can be any size and be applied at any point on another model.

cheers,
Rik