CLUSTER archetypes

I have noticed a large number of CLUSTER archetypes
in the openehr archetype sample repository. I was wondering
if anyone could explain the relationship between
the CLUSTER archetypes and the ENTRY.OBSERVATION
archetypes (there seems to be some overlap between them).

I'm guessing this is a result of some work in Europe (NHS?) that
needs to be mapped onto CEN in a way that the
OBSERVATION/ENTRY system can't be. Can anyone
give a non-clinical explanation of the relative merits
of the approaches?

(I'm not 'having a go' at the approach - I'm just curious as
the thinking behind the work - it seems like it may
lead to a duplication of archetypes?)

Andrew

Andrew,

these archetypes are partly a result of NHS work. They exist because of
the need for re-usable pieces of content that occur particularly in
physical examination, gastro-intestinal (where some observations apply
in many places on the intestine) and so on. It is about re-usability.
THere is as far as I know no duplication, although as the Cluster
archetypes emerge, there may be some temporary duplication until the
full set of archetypes are rationalised.

It is nothing to do with CEN per se; openEHR's lowest level structures
are the same as CEN's - Cluster and Element. So these archetypes will be
connected into higher level archetypes by slots, in the normal way.

As such there is currently only one approach.

- thomas beale

Andrew Patterson wrote:

THere is as far as I know no duplication, although as the Cluster
archetypes emerge, there may be some temporary duplication until the
full set of archetypes are rationalised.

ok - it wasn't so much a straight duplication that I was worried about -
it seemed like a duplication of technique. So for example, glasgow
coma scale (an observation score) appeared as a CLUSTER, but
apgar (also a score) appears as an ENTRY.OBSERVATION. I don't
know enough clinically to know why these would be modelled
differently so was just wondering whether there were some different
approaches being used.

Andrew

Andrew Patterson wrote:

THere is as far as I know no duplication, although as the Cluster
archetypes emerge, there may be some temporary duplication until the
full set of archetypes are rationalised.
    
ok - it wasn't so much a straight duplication that I was worried about -
it seemed like a duplication of technique. So for example, glasgow
coma scale (an observation score) appeared as a CLUSTER, but
apgar (also a score) appears as an ENTRY.OBSERVATION. I don't
know enough clinically to know why these would be modelled
differently so was just wondering whether there were some different
approaches being used.

well, there probably are some different 'approaches' being used in the
clinical space - this is the thing about archetypes - it opens up a
whole new modelling space for domain specialists. It will be some years
before the methodologies are crystallised out. But technically there is
so far only one approach, which is what all the tools support. The great
thing about this (also a bit disturbing for some) is that technical /
engineering people can sit back and let the system users/domain
specialists actually do their work using our tools. Our responsibility
is to make the tools and formalisms work properly, but we no longer make
the pretence of trying to understand their domain in detail. We can't,
and it's not our job. We also no longer have to change any software due
to clinical requirements (well, almost no changes;-). I see the fact
that archetypes are actively being created by clinical groups, that can
be directly used by EHR and other systems, as evidence that the openEHR
approach is working.

- thomas beale

Hi Andrew,

The clusters have been part of recent archetype design evolution,
particularly because experience in modelling history and examination
archetypes indicated we needed an additional level of flexibility to capture
clinical data well.
My current understanding of CLUSTERS is as follows:

- Clusters are reusable archetypes for use in any ENTRY, and particularly of
value where recursiveness is important. As an example, consider a history
OBSERVATION archeype which can contain a Symptom CLUSTER (eg to capture data
about a presenting complaint of Headache), which can in turn contain further
symptom clusters to capture associated symptom details(eg vomiting or
photophobia).

- Clusters have no inherent event/timing, protocol or state attributes -
these come from the ENTRY archetype that contains the given cluster, where
appropriate.

- CLUSTERS tend to represent common and fundamental domain patterns that are
required in many archetypes and clinical scenarios such as size, symptom,
inspection and relative location. In recording clinical examination and
history details, they are useful in capturing those ubiquitous 'first
principles' of examination and history, and could often be best sourced from
a first year clinical student's textbook eg a checklist for a thorough
inspection would consist of size, shape, location, texture, edge,
temperature, surface, surrounds, etc etc - a re-usable component for
capturing inspection detail in many, if not most, clinical examination
scenarios.

Your question about the Glasgow scale as a Cluster archetype is very
pertinent and if you download again you will see it has indeed been
re-developed as an OBSERVATION. As part of some recent rapid development of
archetypes I explored GCS as a cluster, uploaded it for some sharing and
feedback, and only a few hours later revised it - you obviously downloaded
it in that window of a few hours!!!

In my opinion Glasgow Coma Scale are best captured as OBSERVATION archetypes
where it may be used for serial measurements, such as regular recording
during a period of neuro observations post-Head injury. In addition they
are effectively standalone concepts where the need for recursiveness is
lower.

Hope this helps

Heather

Hope this helps

Yes it has, thanks for the info. Do you see this technique
being useful wherever there is a common textual pattern used
in multiple archetypes? For instance, many of the
laboratory results have a 'quality' cluster that is the
same in each archetype. I imagine 'specimen quality'
may be a generic pattern that could be applied in lots of
different archetypes. Do you think it would be appropriate
for this 'specimen quality' cluster to be archetyped?

Andrew

Hi Andrew,

I want to put some words onto this subject...

What you mention below about cluster archetypes being used for
repeating/common textual pattern, had been a (painful) real-world issue
for me. While modeling endoscopic gastroenterology domain conforming to
a standardized terminology with structure (MST), I had three main types
of examination (colonoscopy, EGD and ERCP). Each exam consist of
findings about an organ. For example an EGD exam has structured findings
for esophagus, stomach and duodenum. In my sample archetype - MST-Colon
which you can find in the sample archetype repository, I used
ENTRY-OBSERVATION without problem because it involves only one organ:
colon. But in other exam types involving >1 organ, I need to put all the
contextual information such as Protocol, History, Events, and etc. into
the parent Exam findings archetype, not into individual organ findings
archetypes. My solution to this modeling problem is using ITEM_TREE
archetypes (under Structure directory) or CLUSTER archetypes, devoid of
such context information. So I can now insert them into appropriate
slots in the parent exam findings archetype. It feels silly putting into
each organ finding archetype, context info (with possibly same values)
and then doing the same to the parent exam findings archetype (an
OBSERVATION type).

Also another interesting use of such "Structural" archetypes (as others
had already mentioned) for me was using MST-Duodenum findings archetype
in both EGD and ERCP exam findings...So it definitely helps with
redundancy and I find it very useful.

As a summary I see use of CLUSTER or other "Structural" archetypes in
two different situations:
1) A must - when building archetypes that has slots for similar type of
archetypes with SAME context information or no context information is
relevant.
2) Optional/Useful - as reusable building blocks to be used in different
archetype slots.

Best regards,

Koray Atalag, MD

Andrew Patterson wrote: