Modelling and behavior of of the data type DV_ORDINAL

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


Hi Ian and others! As a pathologist working at Skåne University, Sweden, I realise all too well I’m waaaaay out of my depth here at the OpenEHR discussion Forum. I’m a member of the Snomed Int’l Cancer Synoptic Reporting Project Group (CSRPG). A word of caution, perhaps. A point we discussed in that forum is the access to the TNM coding system: the AJCC has copyright and would expect Snomed CT to pay a large sum for permission to use the system. The UICC (= European) TNM does not have copyright in the same sense, but the AJCC is in the courts claiming that the UICC are using their system. Food for thought - food for lawyers!


Thanks Stefan,

It is an excellent point.

We do have a specific agreement with SNOMED International which allows us to publish SNOMED-CT bindings inside archetypes and templates as long as we make it clear that these can only be used (outside of the free Global Set) if the end-use application or user is licensed to do so.

Actually this is routine disclaimer that we make for any copyrighted scales/scores/instruments.

While openEHR archetypes are all freely available under an open license, the specific content of this archetype may be copyright protected. Any use of this archetype within implementations must be in compliance with the terms established by the copyright owners where a copyright exists.

Actually I noticed this is not in the current TNM archetypes (though AJCC is credited in the references) so we should add that -thanks. I’ll suggest we should so.

This satisfies the vast majority of potential copyright holders. Occasionally we do need to have more complex conversations but they often find it quite difficult to understand that openEHR is not an actual implementer.