Constraints, differentials and composites

Sam Heard and Heath Frankel from Ocean

At first archetypes can be a little overwhelming. With time a large community has taken interest and now has a shared view of what an archetype is in a non-technical sense. Collectively we see archetypes as constraint statements on the _open{_}EHR reference model. Then there were templates. Templates allowed aggregation of archetypes into one larger constraint statement (e.g. an antenatal visit template with weight, urinalysis, BP, fetal hearth, fundal height, abdominal exam) and included some differential statements about, for example, not using some parts of one of the archetypes (e.g. no recording of clothing state with weight) or making a maximum value a little smaller (e.g. maximum systolic BP of 350 mm[Hg]) in line with the specific context.

So templates are composite constraint statements that include some differential statements. Now we have the idea of constraints, differentials and composites. Do these apply in any other way to archetypes?

As people began to create specialised archetypes it became clear that these were difficult to maintain. Any changes in the parent archetype meant that the child had to be updated; a challenging maintenance problem (ask Heather Leslie or the CfH program in the UK). IN response, Thomas Beale has extended the idea of a differential constraint to be a stand alone statement on specialisation. This enables the specialised archetype (as a normal constraint statement) to be generated from the differential constraint and the parent archetype. This resolves the problem of maintenance as the specialised archetype is stored only as a differential statement.

Differential constraints are therefore used in specialisation and in templates. What can we say about differential statements?

  • A differential constraint as a stand alone statement is a specialisation and has a parent constraint.
  • A stand alone differential constraint combined with a constraint -> a constraint. (An archetype + differential statement -> specialised archetype)
  • Otherwise a differential constraint can only be expressed as part of a composite constraint, which is a template.

It is worth pointing out that a composite constraint or template, while generally involving aggregation of archetypes, can involve a single archetype. It would usually, in that scenario, include a differential statement or it is not really a composite.

Operational models

The next innovation in _open{_}EHR was to generate templates that were expressions not only of the constraint, but also of the information model being constrained. This is going into more technical areas but stay with me. An archetype might say nothing about the participations on an entry like weight. But when data is added a user might like to say that the weight was reported by the patient. At the operational level this needs to be available. There are two means of operationalising the composite constraints.

  1. To add the constraints to an in-memory expression of the openEHR reference model. This requires sophisticated software that is only available from a few vendors at this stage.
  2. To add the constraints from the reference model to the composite constraints already expressed, providing a full statement of what can and cannot be represented.

We have called the later an operational template. It can be used to generate a large range of artefacts including programing objects and XML schemas. It can generate forms for data entry and validate the data.


 There are four types of artefacts in openEHR:

  1. Simple constraint statements or ARCHETYPES 
  2. Differential constraint statements which when combined with a parent archetype are SPECIALISED ARCHETYPES
  3. Composite constraint statements or TEMPLATES
  4. Operational models derived from composite constraints called OPERATIONAL TEMPLATES