CCR and openehr

Clinical (archive)
21

Andrew,

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

Well, we will have to agree to disagree, but ultimately it is the clinicians
that will make the decision, not us techos.

However, from my past experience working on consultancies to develop
national discharge summary and referral templates that a flexible modular
approach is necessary to cater for the various situations where discharge
summaries and referrals are used. This means there are likely to more than
one template for discharge summaries and referrals and that a single "one
fits all" CCR like template will not be sufficient. This is especially the
case for the CCR as it is a summary document and experience shows that some
circumstances require more detail in certain areas are whole new sections of
data.

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

It is not the set of data elements that need to be collected that has taken
so long to determine (these are usually already well documented in clinical
literature) but the requirement to extend the RIM vocabulary (through a long
and tedious Harmonization process) and agree on particular combinations of
RIM classes and attributes to be used to map its semantics to those data
elements.

Heath

22

Brett,

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 you say, they are very generic concepts and effectively only represent
the class of the concept and the pattern for its data compared with a
instance of the concept. This is analogous to the RIM classes on the UML
diagram, but this is not where the semantics are carried, the semantics are
in the RIM vocabulary. The equivalent of this RIM vocabulary are archetypes
without the more clinically intuitive and extensible data definition
capability.

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.

Exactly what is done in templates. You can also have Cluster and Data
Element Archetypes to support the reuse of lower-level concepts such as Body
Site etc.

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 explicitly stated in
archetype definitions at this point.

Not explicitly, but there is a reference to a pre-defined code set that
might be a result of applying a complex query of relationships on a
hierarchical terminology such as SNOMED-CT. For example, all the Herpes
related viruses. This result set is stored in a Terminology Server such as
the Ocean Terminology Server and can be accessed by a system using the
archetype using the code set reference. This a bit like the HL7 V3
Vocabulary domains to external vocabularies but more fine grained and less
pre-coordinated. For example, the Australian code set of Herpes related
viruses may be different to the UK.

Heath

23

I have to agree to a high degree with Heath here (exception is on the HL7 harmonisation process).

I have been working on developing archetypes since original CEN work for ICNP / Mose / Nursys, and follow up work in templates within HL7 work. Further several Dutch projects under HL7 v3 umbrella for which I met with Heath.

I believe that the clinical expression of variables, values, datatype, cardinalities, relationships between variables (e.g. in scales) is the most demanding part of all work.
Using any formalism, (more HL7 v3 people are looking at the archetype approach for that, so the discussion on ‘best’ can be considered for the past), is important to bridge clinical to technical worlds.

In this formalism we need to be able to define discrete items (clinically: one observation or one measure, e.g. weight). Then we must be able to have archetypes that combine clinically natural combinations of discrete variables (blood pressure: systolic, diastolic, cuff size, position). Such examples can be globally standardized, at least to the level where the units are referenced appropriately, e.g. kg weight versus Lbs.

The we must have archetype to represent clinical constructs, such as assessment scales / instruments. These have usually a clinimetric / psychometric research based set of characteristic, assuming a 100% correct technical representation. This is doable with archetyping, e.g. the apgar score and Barthel index examples.

To me this is in specifying clinical content with a formalism is such a way that these small pieces can be selected upon choice to be included in different formats.

Each format can be seen as a template: a logical, clinical grouping or collection of archetypes (selection of 1, 3, 5 or 5.000.000 depending on purpose) meeting a specific purpose.

Purposes in the real world are: database design, screen design, HER / OpenEHR style, but also a technical artefact is an HL7 v3 message, or given discussion the CCR style of material.

In other words: archetypes will be globally definable, or at least referred to, where the template specifies many different implement able ‘things’ that will vary to purpose.
The flexibility Heath mentions is absolutely required. E..g. a discharge summary after delivery will have similar components (template level) compared to discharge summary after stroke care, (e.g. blood pressure template, weight), but also differ (first has Apgar score archetype, second has Barthel index). The template thus must hold place for 1-n scales to be includable upon choice of clinicians and depending the actual technical implementation.
For me encounter and medication list are definitely not archetypes: they differ too much in each circumstance, they are templates that will hold several to many archetypes.
The problem list within HL7 has been addressed and is now part of the set of messages useful for referral and discharge. That set is going for 3 year stable DSTU once ANSI has dealt with the bureaucracy. The allergy and intolerance is still a problem, not due to R-MIM modelling, but clinical and national registry etc level discussion on business needs. So the first step: sorting out the clinical content, is blocking the speedy consensus. So with respect to Heath comments on this: no agreement, it will work.

24

Well, we will have to agree to disagree, but ultimately it is the clinicians
that will make the decision, not us techos.

Actually, I'm understanding your point of view more now - I'm totally
in agreement that its not us technical people that makes these
decisions. The CCR may be an absolute abomination
as far as clinical forms go (I really have no experience in this area
at all, but I suspect you are right about a one size fits all
approach not working).

I was just asking from the point of view that, if it
say became mandatory (or even a selling point) in the US
to support CCR, how would you imagine it being supported in
an openehr system (as much as that would be a waste of the
features in openehr - sometimes you've gotta do some things just
to get the 'tick box' for certain markets)?

Andrew

25

William,

In this formalism we need to be able to define discrete items (clinically: one observation
or one measure, e.g. weight). Then we must be able to have archetypes that combine
clinically natural combinations of discrete variables (blood pressure: systolic, diastolic,
cuff size, position). Such examples can be globally standardized, at least to the level
where the units are referenced appropriately, e.g. kg weight versus Lbs.

No argument from me here.

The we must have archetype to represent clinical constructs, such as assessment
scales / instruments. These have usually a clinimetric / psychometric research based set
of characteristic, assuming a 100% correct technical representation. This is doable with
archetyping, e.g. the apgar score and Barthel index examples.

No arguments here either - some scoring I imagine is different from
jurisdiction to jurisdiction (alcohol usage scoring etc) but universal ones
such as apgar can definately be globally standardised.

In other words: archetypes will be globally definable, or at least referred to, where the
template specifies many different implement able 'things' that will vary to purpose.
The flexibility Heath mentions is absolutely required. E..g. a discharge summary after
delivery will have similar components (template level) compared to discharge summary
after stroke care, (e.g. blood pressure template, weight), but also differ (first has Apgar
score archetype, second has Barthel index). The template thus must hold place for 1-n
scales to be includable upon choice of clinicians and depending the actual technical
implementation.

For me encounter and medication list are definitely not archetypes: they differ too
much in each circumstance, they are templates that will hold several to many
archetypes.

I don't understand the distinction you make here - archetypes can hold other
archetypes and so I'm not sure why templates are introduced. For instance,
from the openehr sample archetypes

openEHR-EHR-SECTION.summary.v1

  SECTION[at0000] matches { -- Summary
    items cardinality matches {0..*; unordered} matches {
      allow_archetype EVALUATION occurrences matches {0..1} matches {
        include
          domain_concept matches {/clinical_synopsis\.v1/}
          domain_concept matches {/problem\.v1/}
          domain_concept matches {/problem-diagnosis\.v1/}
          domain_concept matches {/problem-diagnosis-histological\.v1/}
          domain_concept matches {/problem-genetic\.v1/}
          domain_concept matches {/risk\.v1/}
      }
    }
  }

So this summary defines this section to hold a collection
of other specified archetypes.
If this summary was 'included' as the content of a higher level
'discharge' archetype, you would have a flexible definition of a
discharge summary. Where does the template come into it?

What everyone seems to be saying is that clinicians need a lot of
flexibility in how they put together things such as encounters
and referrals. I 100% agree - which is why I would think each
jurisdiction would have its own compositional archetypes, suited
to its own particular use cases (maybe in a hierarchy of
australia discharge summary -> australia natal discharge summary etc).
These compositional archetypes would refer to globally
agree 'data items' archetypes wherever possible (blood pressure etc).

Instead my reading of the situation is that everyone wants
to just have a single global

openEHR-EHR-COMPOSITION.discharge.v1draft.adl

which seemingly adds no useful constraints at all, and then
instead constrain everything with templates (of which we
haven't yet seen a spec?).

Andrew

26

Hi all

It is true to say that there are semantics in every information model - but the core semantics of the openEHR model is containing (hence the proposed key word in the openEHR query language CONTAINS). The effort in openEHR has been to separate the domain semantics from the recording semantics. An OBSERVATION class is there to support recording observations and can apply in science generally as in medicine - separation of method data (protocol), the measured data (data) and the state of the person at the time of the measurement (state) is a well documented pattern. Not separating this data leads to a lot of semantic issues about whether data is comparable or not and the state model for some measurements can become complex and requires the addition of ‘assumed value’ for utility.

The point is that there is no clinical or domain (beyond science) semantics so clinicians can describe archetypes without having to understand too many information constructs.

Cheers, Sam

Cheers, Sam

Brett Esler wrote:

27

Ian and Heath

The ability to apply a template to any archetype, and then use this ‘templated’ archetype in another template (which can also be called) is as far as we have got. Templates are compositional as well as constraining - I have not seen the use case for an inheritence model within templates as yet but I am interested.

The point would probably be when you want to use a template that is well described but add in another feature that is not available (without going through a length process)…this might be a tooling issue - only time will tell.

Cheers, Sam

Heath Frankel wrote:

28

Andrew,

I was just asking from the point of view that, if it say
became mandatory (or even a selling point) in the US to
support CCR, how would you imagine it being supported in an
openehr system (as much as that would be a waste of the
features in openehr - sometimes you've gotta do some things
just to get the 'tick box' for certain markets)?

So the answer is, Templates using existing Archetypes. And another template
can be developed for Australia's requirements, and another for UK
requirements, all using the same existing Archetype.

However, these Archetypes will certainly need work to support the
requirements of those nationally endorsed templates and I am sure that the
CCR will have much to contribute to this.

Heath

29

Andrew and William,

> For me encounter and medication list are definitely not archetypes:
> they differ too much in each circumstance, they are templates that
> will hold several to many archetypes.

I don't understand the distinction you make here - archetypes
can hold other archetypes and so I'm not sure why templates
are introduced. For instance, from the openehr sample archetypes

Encounter and Medication List are Compositions in openEHR. Templates are
used to further constrain these into a particular context such as a Diabetes
Review Encounter or a Current Medication List. Again you don't want to
specialise the composition archetypes for every possible context in every
country otherwise you won't have semantic interoperability between contexts
and jurisdictions.

If this summary was 'included' as the content of a higher
level 'discharge' archetype, you would have a flexible
definition of a discharge summary. Where does the template
come into it?

Clinically a neonatal discharge is not much different to a maternal
discharge or a day stay discharge except for the context and the data it
contains. So you don't need different composition archetypes, just a
different template to constrain (or hint towards) the type of data to be
record for each context.

What everyone seems to be saying is that clinicians need a
lot of flexibility in how they put together things such as
encounters and referrals. I 100% agree - which is why I would
think each jurisdiction would have its own compositional
archetypes, suited to its own particular use cases (maybe in
a hierarchy of australia discharge summary -> australia natal
discharge summary etc).

See above. But perhaps a specialisation of Discharge composition is not out
of the question but not on the basis of jurisdiction except within the
archetype governance framework.

Instead my reading of the situation is that everyone wants to
just have a single global

openEHR-EHR-COMPOSITION.discharge.v1draft.adl

which seemingly adds no useful constraints at all, and then
instead constrain everything with templates (of which we
haven't yet seen a spec?).

As you noted, these are draft archetypes and need work. Composition
archetypes can specify the sections (or entries) that they contain as
content but will also specify the category of the composition and the
other_context data that is associated with the composition. For example you
will not find any content constraints in the
openEHR-EHR-COMPOSITION.report.v1 archetype but will find an other_context
item structure. The discharge archetype is the placeholder for the concept
of a discharge composition, it is still to be determined what globally
acceptable constraints we can specify on discharge content and what context
data is required. Ocean has identified one data element (encounter ID) that
is a candidate.

Heath

30

Andrew

You could start with an integration archetype (using admin entry for the moment) to get the data absolutely in tune with CCR. Then we could do a transform to a properly archetyped environment. Both would be useful. I would be prepared to do the latter - why not have a go at the direct mapping into the openEHR environment yourself.

Cheers, Sam

Heath Frankel wrote: