Modelling and behavior of of the data type DV_ORDINAL

@mikael and everyone lurking!!

I’d also meant to say that I think we all still wrestle with optimising these patterns. I don’t think any of us who have been doing this for a while would be confident to say ‘you are doing it wrong’ - more ‘we feel your pain but here’s the journey we went on and where we ended up’.

I’m not sure if it is privilege or a curse to be exposed to so many information patterns. It is the power of the openEHR approach that makes it applicable to so many different areas of clinical records - we are trying to boil the ocean, just one cup at a time.

And all of this ‘wrangling’ is already happening in traditional non-openEHR systems around the world… again ,and again, and again. At least we are sharing the cost, the experience and hopefully building the standardisation pot.

There is joy … eventually…

1 Like

I am very sympathetic to that view for the same reasons, so don’t abandon it with archetypes! I just think this particular case is borderline…

For @mikael and other ontologists, you will recognise these custom systems as often being fiat categories / boundaries, created by great docs who don’t even know what ontology is, so they don’t think about subsumption relationships of a term (say, some particular TNM value) down through sub-populations (e.g. re-applied to different kinds of cancer with different mechanisms) - and the correspondence of terms to reality doesn’t come out that clean. Some of the scales from adult to children, or with relation to sex or race etc are not ontologically entirely sound.

This is not really to criticise such docs - I doubt that even today there is a single mention within medical school of the potential problems of sub-optimally designed scores/scales/classifications causing real downstream problems in clinical information systems later on… really we should start teaching ontology in primary school or early secondary school (and for fun, here is the book to do it with: The Art of Reasoning).

So, in some sense, we who come along with our keen sense of Aristotelian classification, are mopping up after some eggs have been dropped :wink:

I can agree on many things you say. However, this time the Swedish version of PEWS is a better candidate for using specialization in the modeling than in many other scores.

I am more than happy to discuss all details of the modelling when I have finalized the modelling and published the first drafts of the archetypes. However, I haven’t had time to solve the incompatibilities between Better’s Archetype Editor and the Swedish incubator in CKM yet, so I am not able to share the archetypes yet.

(In my everyday working environment in Sweden it is very rude to criticize a colleague’s idea before the colleague has had a fair chance to present the entire idea. I must therefore say that I am very surprised about some of the comments above.)

Hi Mikael,

You should be able to share a link from Archetype Designer that would let us have a look, in advance of the CKM issue being resolved. Use the share button to the left of the archetype Id. You many know this , of course, so this is also for those lurking!!


As one of those commenting, and perhaps being seen to be criticising, for me at least , that was not all my intent. I was just merely reflecting my experience of very similar issues. I don’t think any of us would claim that we are doing this ‘absolutely right’ or that others are ‘doing it wrong’.

So apologies on my part if any criticism was felt, it was definitely not intended, and I’m looking forward to seeing your approach.


Hi Ian,

I have now posted the archetypes and the considerations in the post Modelling of Swe-PEWS - Clinical - openEHR.



I guess It’s an overstatement saying Archetype Designer doesn’t follow ADL1.4 specification. It’s just strict when it comes to specialization - prevents changes, which break specialization (parent-child) relationship.

In Archetype Editor this was quite relaxed which further lead to inconsistencies.

I more and more think that this is something we really need to bring up to a proper discussion because there are many opinions, but I am unable to really find anything in the specifications. Do you have any suggestions @borut.fabjan ? Might it only be that informaticians/ontologists have one view and software engineers another?

For me, as an informatician, I simply see the value attribute in the DV_ORDINAL as a representation of a concept. The meaning of the concept is explained by the text in the symbol attribute. When I specialize the DV_ORDINAL, one of the options is also to specialize the concept that is represented by the value. This is done by changing the text in the symbol attribute to explain the specialised meaning of the concept.

This kind of specialization isn’t stranger than I in SNOMED CT can specialize the concept
117590005 |Ear structure (body structure)|
by adding the refinement
272741003 |Laterality (attribute)| = 7771000 |Left (qualifier value)|
into the expression
117590005 |Ear structure (body structure)| : 272741003 |Laterality (attribute)| = 7771000 |Left (qualifier value)|
which means “left ear”. This corresponds to changing the symbol in the DV_ORDINAL from “Ear structure” to “Left ear structure”.

This approach might provide one more possible way of incorrect modelling, but I assume that these modelling errors are found and corrected in the usual reviews or in the ontology binding regression tests.

(We have discussed specialisations of DV_ORDINALs in our Swedish openEHR meetings where among others @erik.sundvall , @Asa_Skagerhult , @martin.grundberg and @stoffe have participated and it seems like we all understand the specifications in the above described way.)

Hi Mikkel,

I think we need to be careful here. There are well specified logic rules that support the specialisation of ‘ear’ to ‘left ear’.

But this is an extremely unlikely use case for content of an ordinal.

The ordinal will be used for scores and scales where the value associated with the text will be used as a count (towards a score) or to graph change in the values over time.

In the PEWS example, for specialisation we need to identify a parent model and each of the age groups have equal semantic weight - there is no clear parent or source of original truth on which to specialise.

And I am not convinced of the validity of specialising ordinal text values - for example Pulse frequency for score 1 for 16-18yo is a dual range of 41-50 and 91-110, yet for other ages it is a single range of 111-124, 121-134 , 131-144, 166-179 etc. This sequence or relationship makes no sense to me as a logical, semantic specialisation. And is nothing like the clear ‘ear’ to ‘left ear’ relationship.

IMO it is much cleaner and clearer to model as separate, age-specific archetypes that have common content in many data elements and different content in others.

Kind regards


Hi Mikael,

There is certainly active debate about ADL2 specialisation of CodedTexts which is basically the same issue.

  1. Specialisation: Currently AOM2 allows for specialisation of terms within a valueset but only if these ‘inherit’ from an existing code in the Valueset. On that basis, I think AD should allow you to do what you want, both for CodedText, Ordinals and upcoming Sclae datartypes. @borut.fabjan - why do you think this is currently disallowed?

in a set [red, yellow ,green] we can add light-red

  1. A few of us (mostly modellers!!) argued that we should also be allowed to extend the valueset in a specialised archetype (or template) as long as the new term logically belongs to the same ‘set’.

in a set [red, yellow ,green] we can add black

This is actually a much more common requirement, where a local community wants or needs to add some extra terms to an otherwise agreed set. This was hotly debated and the compromise was reached that this was allowable, as long as the Valueset binding strength was not set to ‘required’ . @borut.fabjan - this is relevant to AD!!

  1. Finally there is that ‘modelling’ discussion about where and when to assert inheritance, and although it is a tricky area, I agree with @heather.leslie above that the kind of inheritance you are proposing is not as helpful as it might first seem and can actually be misleading.

I have tried exactly the same kind of specialisation in the past GCS->paediatric GCS and I now think it is the wrong approach. The kind of ontological truth that can be asserted around biomedical facts such as body-site often does not transfer well to what are essentially record artefacts - derivations of the biomedical data but heavily contextualised.

So to sum-up.

We definitely need to be able to extend (or perhaps replace) valuesets in specialisations, and we sometimes need to be able to create pure specialisations from parent terms.

Whether it is helpful to do so, is a different argument! The nice thing about openEHR is that it allows for this kind of variation. We are all still discovering the optimal patterns as we encounter the challenges thrown by existing clinical records.
Heather and I might not agree with specialising the Ordinal in this case (based on our prior experience of trying to do something similar) but your archetypes will work perfectly well from a technical POV.

1 Like

This is a key point.

I happen to be in favour of more specialisation in general in archetypes to allow better re-use - e.g. examination CLUSTERs … but always observing this principle - i.e. the specialisation has to be understood as being between epistemic (record) entities, not (generally speaking) ontological entities, as in terminology.


All above (point 1,2) In terms of DV_ORDINAL is supported in AD.
See screenshot:

What is not allowed when specialising is to modify inherited (parent) items. For example, turning item red into light-red or black.

1 Like

Regarding documentation @thomas.beale can pull bits & pieces addressing specialisation.
In general terms: Archetype Technology Overview

I don’t think specialisation per se is ambiguous. However when you apply constraints (narrowing) for some DV it might become philosophical.

If parent defines a magnitude constraint 0 < x < 10 it’s pretty clear what’s allowed when specialising.

DV_ORDINAL {(at0006, ‘red’), ((at0007, ‘green’), (at0007, ‘blue’)}
If you specialise, you can’t just rename text “red” to “light-red”. But you can add a new item in the set.

However when it comes to DV_CODED_TEXT, or DV_ORDINAL, … we may end-up in murky waters where epistemology, ontology and logic may collide. Usually it all revolves around what actually means “narrowing”.

In terms of Archetype Designer we wanted to support a path to AOM2 and enforce specialisation with ADL14 archetypes - having parent & child in sync.

1 Like

Agree but you can do

DV_ORDINAL {(at0006, ‘red’), (at0006.1, ‘light-red’)(at0007, ‘green’), (at0007, ‘blue’)}

and with the latest spec proposals also

DV_ORDINAL {(at0006, ‘red’), (at0006.1, ‘light-red’)(at0007, ‘green’), (at0007, ‘blue’), (at0.9, ‘black’)}

as long as this is not a ‘required’ valueset . This was disallowed in the previous version of the AOM2 spec. i.e. you could not add a new term to the valueset, if it did not directly inherit from an existing term.

The key thing in both is that you are creating a specialisation of the valueset itself, and it is this that carries the extra members.

I think there is agreement that for ORDINAL, CODED_TEXT and SCALE that all of this should be possible.

i.e. what Mikael is wanting to do should be technically possible in the spec and in tooling. Whether it is a good idea from a modelling POV is a different question!!


BTW; This comment was about if the ADL in the post Modelling and behavior of of the data type DV_ORDINAL - #12 by mikael , which was created in the Archetype Designer was correct ADL 1.4 or not. It seems like most people argued that it is correct ADL 1.4 and in that case Archetype Designer do the right thing.

Hi Heather,

I totally agree with you that we need to be careful and I really hope that these issues are well documented now or in the future in some kind of archetype design pattern best practice document.

But still I would like to understand what are the allowed specialisations of the data types that contain some kinds of categories, like DV_ORDINAL and DV_CODED_TEXT, because there seems to be different opinions in this thread about what the technical specifications really states.

1 Like

Hi Ian,

Thank you for the clarifications.

For the record I would like to point out that I haven’t argued that specialisation of the values in DV_ORDINAL is a generally helpful thing. I only asked if it was allowed according to the technical specifications and tried to unsuccessfully keep the discussion on the technical specifications. The background was that I had found a specific modelling problem that I understood might be one of the probably rare situations where this mechanism is useful. But the modelling problem is discussed in another thread.

1 Like

I understand @ian.mcnicoll as changing the text from “red” for value 3 in the mother archetype to “light-red” for value 3 in the child archetype is allowed.

I also understand as @borut.fabjan first agrees with @ian.mcnicoll , but then state that it is not allowed to change the text from “red” for value 3 in the mother archetype to “light-red” for value 3 in the child archetype. Instead a new value, like 4, needs to be added for the “light-red” text in the child archetype.

This confuses me.

I can only agree that it is important to know what “narrowing” mean. That is why I am very found of supplement the information model with a formal ontology. :slight_smile:

@mikael nothing you won’t already know here, but I’ll state it for the benefit of others following the discussion.

We have a definition for ‘narrowing’ - it’s the golden rule of openEHR: a specialised model can only be changed with respect to its (inheritance-flattened) parent in such a way that its instances will also be formal instances of any of its flat parents, and the underlying reference model (RM).

In constraint-land, only ‘narrowing’ of existing properties can achieve that. The consequence is that querying for some attribute in archetype A will correctly pick up direct A instances, as well as instances of A’s archetype children. However, it is worth noting that new properties can usually be added in RM container attributes that remain ‘open’ for addition. This is what provides the flexibility while retaining computability.

This concept is the almost the as subsumption in terminologies, if you consider it to be: A’ is-a A if all of the a’ in the extension of A’ are also in the extension of A.; then the relationship between the intensional definitions of A’ and A is the equivalent of ‘narrowing’ in constraint models.