Specialisation

Technical (archive)
1

Dear Everyone,

Background:
We are in Sweden starting a number of clinical archetype-construction
projects and we are hoping to re-use as much as possible from the
openEHR repository by specialisation.

So to my problem:
Looking at the openEHR-EHR-OBSERVATION.body_weight.v1 archetype
(hereafter named BW) and the
openEHR-EHR-OBSERVATION.body_weight-birth.v1 archetype (BWB), BWB does
not seem to be a specialisation of BW. BWB specifies the event to be
birth and clothing state to be naked, but relaxes the unit restriction
to allow grams (with "g" as the abbreviated from, not "gm", see ISO
Guide 31, item 3.1-a).

Then to my specific questions:
1. Are the BW and BWB wrong and should be corrected?
2. Can BWB be understood without BW or must each restriction be stated
explicitly? E.g., does BWB inherit the protocol restriction from BW?
3. What about weight gain and weight loss in BW?

Best Regards,
Daniel

2

Hi Daniel

The Birth weight BWB archetype is specialised in that it only has one event birth which is point in time - and so cannot be used for interval measurements (weight loss/gain). It was created to make explicit the recording of birthweight in a way that could still be used as a weight - but would allow instant search to find this important data.

The units problem is correct and has been added to the specialisation inappropriately. We are progressing fast on a pathway to have true specialisation archetypes (ie only contain the further specification and not the specifications held in the parent). The standardisation of units is always contentious - and has not been an issue previously.

We are putting many of these through quality control at the moment and would appreciate comments in the clinical list about archetypes.

It is probably important that you get to grips with Templates where things can be constrained without use of specialisation. Specialisation is proving most appropriate to add features to the concept - templates to remove them or narrow them.

Cheers, Sam

Daniel Karlsson wrote:

(attachments)

OceanCsmall.png

3

Hi Daniel,

I would suggest that you re-post this on the clinical mailing list.

Cheers,
Tim

4

Dear Everyone,

actually I was going to re-state the questions to the technical list,
but will cross post it to the clincial (will I be banned???).

For the clinical list read the original message below:

For the technical list, I would still like to have the details of
specialisation laid out. Are constraints inherited and thus implicit in
the specialised archetypes' definitions? Then, in the BW/BWB example,
are also the weight gain/loss inherited (which according to my layman
understanding is not very sensible for birth weight).

Clear semantics of specialisation would be necessary to bring further
any discussion on support from tools in this area.

/Daniel

Daniel Karlsson, PhD
Department of Biomedical Engineering/Medical Informatics
Linköpings universitet
SE-58185 Linköping
Sweden

5

Dear all,

As an other layman my two cents to the discussion.

Specialisation
Since archetypes express what can be maximally documented about a topic,
and because in the Template the archetype can be constrained maximally to fit the local context at that point in time,
I think there is almost no need for specialization.

In the example given below. It is clear that both BW and BWB example at the same time Body weight and Body weight at the time of birth can be generically handled and do not need specialization.
Body weight change is always relative to an other measurement. I see no reason why these aspects of what can be documented around the topic Body weight can not be in the same archetype. At Template design time the appropriate attributes will be selected or deselected.

A possible example
There is the generic Weight archetype as an Observation. Expressing all that can be documented about any weight observation.
And then we define a specific specialized one for Body weight or Organ weight or thumb weight or compound weight, etc, etc, etc
I do not think this is the way to go. The world is large and to many specialization’s will be produced.

I think it is wrong to have an archetype called Body weight. We only need ONE about all aspects of WEIGHT of anything.

My line of thinking is:
When all that can be documented about a concept is defined in an Archetype and the concept is weight than the topic is about weight measurement of anything.
Within the archetype there must be an attribute what the focus of the concept is. So we must be able to indicate in an archetype attribute whether this a person or a thing.
It must be possible to indicate what is observed.

At the Template level I see specialized Sections be constructed containing generic archetypes. Archetypes that define precisely in the context of measurements in newborns and grownups what will be documented about weights.

I’m curious to learn what are the real use cases for Archetype specialization.
I see the need for specialization in the Template phase under control of the knowledge domain.
In the meantime the tools must be able to support specialization.

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

6

Daniel Karlsson wrote:

Dear Everyone,

actually I was going to re-state the questions to the technical list,
but will cross post it to the clincial (will I be banned???).

For the clinical list read the original message below:

For the technical list, I would still like to have the details of
specialisation laid out. Are constraints inherited and thus implicit in
the specialised archetypes' definitions? Then, in the BW/BWB example,
are also the weight gain/loss inherited (which according to my layman
understanding is not very sensible for birth weight).

Clear semantics of specialisation would be necessary to bring further
any discussion on support from tools in this area.
  

Only just saw this. This is correct, and an implementation of
specialisation is underway in the Archetype Workbench, which will result
in specialised archetypes being represented in a differential form
rather than the present 'flat' form, where inherited constraints are
copied in. The existing document on semantics will be updated to reflect
details not already published. However, the basic approach is similar to
object-oriented programming languages:

- constraints are inherited, and can be overridden
- overrides are 'covariant' i.e. the constraints are narrower than the
parent, also can be thought of as 'subsumed'
- new constraints can be added where allowed by the parent archetype and
reference model

There are of course a number of fine details that need to be documented.
In the new version of the workbench tool, the entire archeytpe
repository will be compiled like a system of object classes, with proper
validation of specialisation relationships.

hope this helps.

- thomas beale

7

Hi Gerard,

I do not appear to have all of the original inputs to this thread, so I am not sure who made some of the original comments.

Specialisation
Since archetypes express what can be maximally documented about a topic,
and because in the Template the archetype can be constrained maximally to fit the local context at that point in time,
I think there is almost no need for specialization.

I almost agree - we should, I think make sparing use of specialisation but some good use cases are emerging -see below.

In the example given below. It is clear that both BW and BWB example at the same time Body weight and Body weight at the time of birth can be generically handled and do not need specialization.
Body weight change is always relative to an other measurement. I see no reason why these aspects of what can be documented around the topic Body weight can not be in the same archetype. At Template design time the appropriate attributes will be selected or deselected.

A possible example
There is the generic Weight archetype as an Observation. Expressing all that can be documented about any weight observation.
And then we define a specific specialized one for Body weight or Organ weight or thumb weight or compound weight, etc, etc, etc
I do not think this is the way to go. The world is large and to many specialization’s will be produced.

I disagree, Birth weight is a good example of an appropriate specialisation. It is a clearly understood and accepted specialisation of body weight which has quite specific and universally agreed constraints across all possible uses of the concept.

I think it is wrong to have an archetype called Body weight. We only need ONE about all aspects of WEIGHT of anything.

My line of thinking is:
When all that can be documented about a concept is defined in an Archetype and the concept is weight than the topic is about weight measurement of anything.
Within the archetype there must be an attribute what the focus of the concept is. So we must be able to indicate in an archetype attribute whether this a person or a thing.
It must be possible to indicate what is observed.

Again I must disagree. The value of the archetype philosophy as that it allows clinicians to agree the content and contraints upon clinical recording topics which are both manageable but have universality. If we attempt to over abstract the archetype to simply ‘weight’ and leave all the constraining to the template layer, we will simply end up with the same problems ‘downstream’. I can understand from an enginerring perspective the attraction of more pure abstract archetypes but from a clinical recording perspective the Is-a relationship should reach no further back than ‘Body weight’. This is the base class. Any other type of weight recording in clinical settings e.g weight of ingredients in a drug is quite a different concetp,although of course, in pure ontological terms it is_a weight.

At the Template level I see specialized Sections be constructed containing generic archetypes. Archetypes that define precisely in the context of measurements in newborns and grownups what will be documented about weights.

I’m curious to learn what are the real use cases for Archetype specialization.
I see the need for specialization in the Template phase under control of the knowledge domain.
In the meantime the tools must be able to support specialization.

Several use cases that I can identify:

  1. ‘True specialisation’ The case of Body weight/Birth weight above. I think this is a very good example of appropriate ‘true’ specialisation. i.e. further contraints upon an existing archetype. It is entirely appropriate to do so at archetype because Birth weight although clearly inheriting from Body weight, is itself a universal concept with quite specific and univerasally accepted contraints, not variant by speciality, locality or other context. I suspect there will be few instances of this sort of specialisation

  2. Semi-abstracted archetypes e.g the NHS specialisations of Inspection and Palpation for different organs or systems e.g. Paplation-External_Ear or laboratory results
    In these cases, this approach allows generic ‘first -principles’ of clinical examination to be inherited to the specialised archetype e.g site. appearance, tenderness, likely to be common features of all examinations. It also allows the slot constraint mechanism to use the IS-A relationship to simplify acrchetype slot definitions at both archetype amd template level. I think we will run into trouble if we try to over-abstract and end up with long chains of specialisations but it is useful if restricted to one or two levels.

  3. “Archetypes express what can be maximally documented about a topic” Agreed but the scope of the topic is not always completely clear especially around research requirements or in semi-clinical settings. A good example was raised at Alkmaar, of an adverse drug reaction form used in the context of clinical drug trials. Although the existing ‘clinical’ ADR archetype was almost acceptable, the requirements of data capture for drug trial purposes were subtly different in some aspects and not appropriate in a service delivery context. Specialisation of the clinical ADR archetype allows data to flow between the clinical setting and drug trial setting, without clinically inappropriate concepts being modelled in the parent. A similar scenario exists with research requirements where there are clear advantages to integrating research data to the EHR especially when the research starts to become accepted and starts to from part of service delivery , perhaps only locally at first. Specialisation allows ‘unstable’ research requirements to be modelled consistently with accepted archetypes with the expectation that if the ‘new’ becomes ‘current’ practice, the specialised elements will be promoted to the parent for universal use.

Ian