CCR and openehr

Clinical (archive)
1

Has anyone looked at making an openehr
composition archetype(s) corresponding to
the ASTM continuity of care record (CCR)?

I don't have access to the ASTM standard
but I was just looking at the HL7 document
describing how CCR maps into CDAr2 and
was thinking that it would be a good test of
the power/generality of the openehr RM
to see if similar could be done for it.

(I realise that CCR has its own specific
adhoc XML schema that are incompatible with
the openehr RM, but at some higher level
it has content sections/actors etc
that are captured and it would be interesting to
see how close the openehr models can go to
capturing that same information)

Andrew

2

I bet you can...even better implement one that is compatible with CDAr2
CCR implementation; they have some implementation guides with detail;
CDA is supposedly mappable to a composition any way :wink: (ask Heath
Frankel and Dipak Kalra, or Sam)..

Then go sell the idea to the NHS for mega$$

3

Andrew,
The CCR would not be implemented as a composition archetype but as a
template. Obviously there will be a composition archetype required and
several section archetypes but they would not be specifically designed for
CCR. The same archetypes should be able to be used in Australia
(HealthConnect/NEHTA Discharge Summaries), UK, NZ, etc. The CCR template
will ensure it reflects the requirements of the CCR data model.

Most of these archetypes already exist in some sense but it would certainly
be useful piece of work to ensure all the CCR requirements are supported in
the various archetypes as the CCR is really not anything different to
HealthConnect Event Summaries or UK equivalents. This might be done as part
of the Detailed Clinical Modelling work that is being done in the US.

Even though it would be relatively simple to construct a CCR from these
existing archetypes into a single composition, openEHR is designed to be
more intelligent in its representation of data that is copied into Discharge
Summaries from existing documents such as Lab Reports, Prescriptions,
Problem List and Referrals. By using LINKs from the Discharge Summary
composition to these existing items in the EHR, your able to manage the
duplication of EHR content which is commonly copied into Discharge Summaries
and Referrals. Using this approach, the Discharge Summary or Referral
composition becomes relatively small document containing only actually
created at the time of creating the composition such as the letter and LINKs
to the existing documents, which is committed and communicated to the
intended recipient as an EHR Extract containing the Discharge/Referral
composition and the associated compositions that are LINK targets in the
Discharge/Referral composition. Ocean is currently working on the details
of this representation using the NEHTA Discharge Summary Template
specification which is more detailed than the CCR.

Even though the representation of the Discharge Summary in openEHR is a
collection of LINKed content rather than a single document, it is expected
to be able to produce a CDAr2 equivalent of the openEHR composition for
communication purposes, but of course you lose the advantages provided by
openEHR.

Regards

Heath

Heath Frankel
Product Development Manager
Ocean Informatics

4

The CCR would not be implemented as a composition archetype but as a
template.

Some of us haven't seen the template spec which makes it hard to
see where the line between openehr archetypes and openehr templates
lies.

Obviously there will be a composition archetype required and
several section archetypes but they would not be specifically designed for
CCR. The same archetypes should be able to be used in Australia
(HealthConnect/NEHTA Discharge Summaries), UK, NZ, etc. The CCR template
will ensure it reflects the requirements of the CCR data model.

I understand how a template introduces further constraints on the allowable
data - but I don't see exactly where it stops being data we would
'archetype' and becomes data that would be 'templated'. Surely there
would be openEHR-EHR-COMPOSITION.ccr.adl which enumerates
the allowable sections (perhaps these might be a common archetype
such as openEHR-EHR-SECTION-findings), but more likely would be CCR
specific sections (openEHR-EHR-SECTION-ccradvancedirectives). At
the lower levels, the CCR sections could refer to shared ENTRY
archetypes, or LINK's as suggested in your email. Where specifically
does templating come in? I know the spec isn't published but we could
we see a snippet of how a template might work in this case?

Can I also make a plea here - given that the openehr template spec hasn't
been released yet, is it too late to rename 'templates'? openEHR has staked
out the word 'archetype' pretty well (enough that even though it is a generic
concept it is clearly associated with the openehr approach) - now HL7
will be creating a
'template' spec in order to do 'archetyping' (with a template being
at a similar level as an openehr archetype). Simultaneously, openehr
will be releasing
a 'templating' spec, which is some concept that is distinct from an openehr
archetype and yet also distinct from the HL7 artifact of the same name?

English is a big language - can't we find find enough different words
for these things
to avoid confusion? If they are essentially the same thing, then fine,
but we had
better be confident that they really are exactly the same concept..

Brett, can you get HL7 to rename the templates group?

(actually I just found a document called templates_and_archetypes.pdf on the
openehr site written by Sam, Gerard etal which kind of explains it all but I'm
not sure everyone is still using the terms in the way that was proposed in that
document.. all I know is that I'm still confused! :slight_smile: )

Andrew

5

Andrew,
I understand the limitation of no specifications for templates. Archetypes
are more than data structures, they are semantic structures. A CCR is a
data structure defined by a particular organisation but has no true
semantics in health, where as a discharge or referral is a common concept.
So you have an archetype of discharge (or referral depending on the
semantics of the CCR). If we had archetypes for every data structure
developed by an organisation we would have millions of archetypes and no
semantic interoperability. This is how Templates play their role, it allows
an organisation like ASTM to use existing archetypes and specify their own
data structures with relation to the semantic of those archetypes.

Also, HL7 Templates and openEHR templates are actually conceptually the
same, they both aggregate and further constrain existing model artefacts.
In openEHR the model artefacts are the openEHR RM and archetypes and in HL7
they are the RIM and RMIMs. It is the Archetype term that is confusingly
used in the HL7 world because there is no real concept of building new
concepts from the RIM as the HL7 methodology is all about constraint. You
never create an archetype in HL7, the archetypes are already defined in the
RIM. So the HL7 Template spec is not for archetyping, it is for templating.

BTW, CCR is relatively limited in structure below the section level, it
defines the sections and the kind of entries allowed in each section but not
the structure of the entry. The HL7 CCD have gone one step further and
defined some structure to particular entries like Medication and Problems
but it is still limited. This is why the NEHTA Discharge Summary is more
detailed even though they are abstract specs and don't yet have an
implementation technology specification.

Heath

6

The reason why it is important to distinguish between archetypes and
templates is to why we insist on the separation between the design and
implementation spaces. Archetypes as clinical model exist independent of
their potential use. Templates are the visual forms created for particular
applications. Thus it would be possible to create different versions serving
the same purpose - in this case the visual representation of a CCR form.

Ogi Pishev

7

implementation spaces. Archetypes as clinical model exist independent of
their potential use. Templates are the visual forms created for particular
applications. Thus it would be possible to create different versions serving
the same purpose - in this case the visual representation of a CCR form.

Is this all that templates are though? If the distinction is purely
that templates are a method for specifying the user interface aspects
of archetyped data (i.e. this should be a combobox pick list etc) then
that is a distinction I can understand. However, the CCR is not a
specification of a particular 'interface' or even 'form'. Its a clinical
model of data that needs to be recorded - exactly the type of thing
I would think would be archetyped first and foremost (obviously if
someone wanted to specify a 'user interface' in some standard they
could do that - but I would think the primary artifacts that would be
released by standards bodies, NHS etc would be archetypes - vendors
can work out interfaces on their own can't they?)

Andrew

8

My try.

Archetypes: Models about a domain topic. They describe interoperably what can be stored, retrieved, presented and exchanged in general about that domain topic.
Templates: The collection of archetypes constrained to that precise degree that it is usable in a specific context.
Template: It is the interoperable information part of a contract between two or more communicating actors.

Gerard

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

9

Andrew & Ogi,
openEHR Templates are not Forms, they are aggregations of archetypes with
further constraints. The scope of an openEHR template can be compared with
a form but define the data structure of that form. However openEHR
Templates can be used to drive the design and generation of forms as is done
using the Ocean Template Designer. The designer has a Template Design panel
where archetypes are dragged from a archetype repository view onto the panel
building up the template structure and the archetype nodes are constrained
as required in the template. The Form Design panel allows nodes from the
Template to be dragged onto the Form and formatted as designed. This latter
step is purely an application customisation step whereas the former template
design is a knowledge development step possible used by more than one
application.

Heath

10

Hi Heath,

I am interested in this aspect of archetypes/templates as well. I am
currently working with the Scottish National Clinical Datasets program to
see how we might integrate archetypes and templates into their data
standards development process i.e essentially as a design-time tool rather
than a full OpenEHR runtime system (though this may perhaps follow along in
due course). The current process has delivered very good clinical
involvement and knowledge acquisition but the output has a number of
deficiencies - poor support for 'complex clinical concepts' i.e. archetypes
and is not sufficiently tightly defined to be used by system developers
without a great deal of further confusion.

I am interested in your comment "the former template design is a knowledge
development step possible used by more than one application" because as well
as templates being a precursor to form design can they also play a part in
'dataset' definition by capturing the requirements of different clinical
workgroups based perhaps on the same archetypes?

Is there an inheritance mechanism within templates as there is for
archetypes via specialisation?

Regards,
Ian

Dr Ian McNicoll
Maclean McNicoll Software
www.gpacc.co.uk

11

Heath Frankel wrote:

Andrew & Ogi,
openEHR Templates are not Forms, they are aggregations of archetypes with
further constraints. The scope of an openEHR template can be compared with
a form but define the data structure of that form. However openEHR
Templates can be used to drive the design and generation of forms as is done
using the Ocean Template Designer. The designer has a Template Design panel
where archetypes are dragged from a archetype repository view onto the panel
building up the template structure and the archetype nodes are constrained
as required in the template. The Form Design panel allows nodes from the
Template to be dragged onto the Form and formatted as designed. This latter
step is purely an application customisation step whereas the former template
design is a knowledge development step possible used by more than one
application.
  

To further clarify: an openEHR template can be used to:
- create a visual form (as described above by Heath)
- to create a message definition, i.e. an XML-schema corresponding to
the template
- to create a means of displaying data, using XML/Xslt
- create other generated artifacts, e.g. code skeletons, wsdl
specifications etc

Logically, an openEHR template corresponds to a localised specfication
for a chunk of content, based on use of archetypes (which themselves may
be very general).

- thomas beale

12

Gerard Freriks wrote:

My try.

Template: It is the interoperable information part of a contract
between two or more communicating actors.

Gerard,

that is a very nice functional definition. In some cases, the actors are
the GUI application user, and other users, whose previously persisted
information is served up via a template-enabled application.

- thomas

13

I apologise for my rather irreverant previous post....that was an oops.

Are openEHR template specialisation hierarchies a real possibility? This
would be particularly useful in message profiles, and conformance level
assertions made by systems.

Btw: would consider the openEHR RM classes archetypes if I was to
express them somehow using CEN13606, and HL7 V3 RIM further again
specialised archetypes. The choice is how general is your reference
model and the assumed semantic level that comes with that. HL7 V3
templating is the using the same method whether archetyping or
templating in openEHR speak, there are also many aspects of openEHR
style templating in HL7 message development itself.

This becomes N level modelling...
- openEHR has at least 3, RM, archetype, template
- HL7 V3 at least 4, RIM, DMIM, RMIM, HL7 Template (CIM + CMET)

All of these have some usage description...and some 'rules' e.g must
have a single entry point, must be serialisable etc.

Picking your level for expressing a wire protocol is another choice;
that would be in some ways be entirely based on your level of generality
desired.

Regards,
Brett Esler

14

Hi Ian,

I am interested in your comment "the former template design
is a knowledge development step possible used by more than
one application" because as well as templates being a
precursor to form design can they also play a part in
'dataset' definition by capturing the requirements of
different clinical workgroups based perhaps on the same archetypes?

This is exactly what templates are designed to support.

Is there an inheritance mechanism within templates as there
is for archetypes via specialisation?

Hmm, good question. Not sure what Tom & Sam have in mind here, would be
nice. However, I do know that the inheritance mechanism in archetypes is
being improved and that the Template Model is really just an extension of
the Archetype Model so I would guess that it might. We have not yet
implemented this capability in the OceanEHR Tools and Application
Components.

Regards

Heath

Heath Frankel
Product Development Manager
Ocean Informatics

15

data structure defined by a particular organisation but has no true
semantics in health, where as a discharge or referral is a common concept.

Well, not strictly true - the CCR has semantics that aren't the same as
discharge or referral but they are seemingly clear to the CCR people
- the CCR is a summary
record that could be used by an (unknown at the time of composition)
future health provider to continue the care of this patient. If it becomes
popular it may become a common health concept.

developed by an organisation we would have millions of archetypes and no
semantic interoperability.

Well, we'd maybe have multiple archetype sets (as opposed to one set of
archetypes) each defined by different organisations. ASTM, NHS, NEHTA
etc. I don't think we'd even break into the 1000's if every health standards
body defined their own?

I thought semantic interoperability was the ability to computationally
recognise the
similarities in archetyped data between systems using terminologies etc,
therefore allowing data to be used across multiple systems. i.e. this
is a soap 'plan' because it is in a section marked with the term
binding for 'plan', and over here in this other completely different
archetype we might have a similar section and therefore we know they
have the same meaning. If semantic interoperability is just that everyone
agrees to use the same definitions for everything, then we don't really
need a fancy word like semantic interoperability for it. Its like saying
we'd have semantic interoperability if everyone agreed to use the Medical
Director database schema - which is true but pointless - if everyone
agreed in the first place we wouldn't be worried about the semantics
when we go to interoperate.

I'm not suggesting that every player in the whole health system
would be going around defining archetypes for everything. But surely
we're not suggesting that there would only be ONE set of archetypes
for the whole world (with templates making the constraints for local
variations)?

Andrew

16

Andrew,

> data structure defined by a particular organisation but has no true
> semantics in health, where as a discharge or referral is a
common concept.

Well, not strictly true - the CCR has semantics that aren't
the same as discharge or referral but they are seemingly
clear to the CCR people
- the CCR is a summary
record that could be used by an (unknown at the time of
composition) future health provider to continue the care of
this patient. If it becomes popular it may become a common
health concept.

I don't see any difference in semantics to the Discharge Summary stored in a
HealthConnect Record System.

Well, we'd maybe have multiple archetype sets (as opposed to
one set of
archetypes) each defined by different organisations. ASTM,
NHS, NEHTA etc. I don't think we'd even break into the 1000's
if every health standards body defined their own?

openEHR does not intended for this to happen. However, this does not mean
that organisations can't have local archetypes but they should not
semantically overlap with those archetypes that are globally recognised.
This is the fundamentals of Archetype Governance which is under development
by the openEHR Clinical Review Board.

I thought semantic interoperability was the ability to
computationally recognise the similarities in archetyped data
between systems using terminologies etc, therefore allowing
data to be used across multiple systems. i.e. this is a soap
'plan' because it is in a section marked with the term
binding for 'plan', and over here in this other completely
different archetype we might have a similar section and
therefore we know they have the same meaning. If semantic
interoperability is just that everyone agrees to use the same
definitions for everything, then we don't really need a fancy
word like semantic interoperability for it. Its like saying
we'd have semantic interoperability if everyone agreed to use
the Medical Director database schema - which is true but
pointless - if everyone agreed in the first place we wouldn't
be worried about the semantics when we go to interoperate.

Actually sections are purely organisational only, they do not change the
semantics of the entries inside them.

What you describe above regarding sematic interoperability is what is
attempted by HL7 V3 where the semantics are defined in the RIM. The problem
here is that no one can agree on the semantics of the RIM (I am not trying
to controversial here, this is from experience as the Modelling Facilitator
of the Care Provision domain for many years). It has taken > 2 years (and
it continues) to agree on the RIM structures required to semantically define
a Problem List and Allergy. We do not have this problem in openEHR as the
semantics of the concept are declared by the definition of an archetype and
all you have to do is specify the data that you need to capture as part of
that concept. What we do is share the concept ID (the archetype ID) which
is analogous to sharing SNOMED concept IDs and share the data structure
along with that. If you go and define your own data structure and assign
your own archetype ID for the same concept then you have just broken your
semantic interoperability.

You are absolutely correct, if we can agree then we wouldn't need to worry
about mapping semantics to interoperate, that is the premise of archetypes.

I'm not suggesting that every player in the whole health
system would be going around defining archetypes for
everything. But surely we're not suggesting that there would
only be ONE set of archetypes for the whole world (with
templates making the constraints for local variations)?

For agreed concepts, yes. Local archetypes can exist (as long as they don't
overlap), including specialisation of global archetypes, and they can get
promoted to higher levels of as consensus grows around that archetype.

Regards

Heath

17

openEHR does not intended for this to happen. However, this does not mean
that organisations can't have local archetypes but they should not
semantically overlap with those archetypes that are globally recognised.
This is the fundamentals of Archetype Governance which is under development
by the openEHR Clinical Review Board.

ok - I think we actually have almost the same world view. I
agree that if you can construct a globally recognised and
agreed upon archetype, that this should be used wherever
possible. I would think that clinical ENTRY archetypes would
be the main area where this is possible - after all we are all
human beings and so it should be possible to construct
common glucose reading/blood pressure etc archetypes.

Actually sections are purely organisational only, they do not change the
semantics of the entries inside them.

I guess I disagree about the possibility (or usefulness) of
defining globally recognised archetypes as you go further
up the tree (towards organising archetypes like
encounter, medication list etc). This is why I would see
a CCR as a composition archetype, with the specific
sections and details as per the CCR spec. I don't see
the possibility (or value) of defining the CCR as a
template of some generic 'discharge' archetype.

of the Care Provision domain for many years). It has taken > 2 years (and
it continues) to agree on the RIM structures required to semantically define
a Problem List and Allergy. We do not have this problem in openEHR as the
semantics of the concept are declared by the definition of an archetype and

So why do you believe it will be possible to get global agreement
on the definition of the Problem List and Allergy archetype?

Andrew

18

Heath,

I know what you are saying about RIM semantics but aren't the openEHR RM
classes, OBSERVATION, INSTRUCTION, EVALUATION, etc. implying a general
weak clinical semantic as a framework for hanging stronger semantic
archetyping. I can imply certain things about a stored openEHR
OBSERVATION based on the openEHR RM definition without knowledge of the
archetype applied to it, for a start it is considered an observation not
an instruction for instance.

As for terminology binding for consistency we would need to ensure that
the use of terminology binding in leaf nodes of archetypes was
controlled enough to ensure that the granularity of the concept matched
the allowed data constraints at the node and also that concept either
did not appear in other archetypes or matched exactly in terms of
constraints to data. It is what it is...there are no choices here.

We could also ensure that terminology bound child nodes in an archetype
definition can be related to the parent terminology binding in a known
way; this might be made explicit as a SNOMED-CT hierarchy. Parents and
child nodes are related through a relationship this is not explicity
stated in archetype definitions at this point.

These approaches will show any holes in SNOMED-CT that need addressing
and also extend the concepts to include data definitions where
appropriate.

Regards,
Brett Esler

19

Hi,

This becomes N level modelling…

  • openEHR has at least 3, RM, archetype, template

  • HL7 V3 at least 4, RIM, DMIM, RMIM, HL7 Template (CIM + CMET)

All of these have some usage description…and some ‘rules’ e.g must

have a single entry point, must be serialisable etc.

But with one big difference.
In OpenEHR the whole trajectory from level 1 to n via done in a strictly computable way.
This is not the case in HL7.

Gerard

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

20

The family of Observation, Instruction, Evaluation and Action Archetypes are containers.
But they do not change the meaning if archetypes they contain. A blood pressure stays a blood pressure.
In effect this specific family of archetypes constitute an extra model in the OpenEHR family of models.
This model is about the patient treatment cycle in which constructs like blood pressure, prescription, etc, play a role.

Gerard

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755