This page makes two different proposals for improving ADL in a generic way, that would remove the 'custom syntax' used to efficiently represent constraints on Coded text, Quantity and Ordinals.
Coded text constraints - 'code' as a primitive type
In openEHR and CIMI we have debated the question of the so-called 'special' types in ADL. I think that the issues are not the same for all of them - i just depends on how we see them. I'll just talk about one here - the coded text one.
In 'standard' ADL you can write:
CODED_TEXT matches {
terminology_id matches {
TERMINOLOGY_ID matches {
value matches {"local"}
}
}
code matches {"at0111", "at0012", "at0013", "at0014", "at0015"}
}
In the current custom syntax, this becomes:
CODED_TEXT matches {[local: at0111, at0012, at0013, at0014, at0015]}
Reducing RM dependence, increasing archetype re-usability
This is not just a question of more or less efficient syntax. In the first one, you are constraining an explicit RM object of type CODED_TEXT, with some specific internal structure, coming from its RM. If I want to do the same for openEHR, the ADL code is different, even though the class definitions are very similar.
In the second example, the RM type CODED_TEXT is assumed, but no explicit RM definition of internal structure is assumed; instead, AOM has an internal model of that which has a 'terminology id' concept, and a 'code' concept. Clearly this can be mapped to the relevant bits of CODED_TEXT, DV_CODED_TEXT, CS, etc.
So the point here is that an archetype fragment containing a coded term constraint (probably the single most common constraint there is) can be represented in a semi-RM-independent way, increasing the direct re-usability (= minimising conversion effort) of the archetype text in e.g. 13606, HL7, other situations.
Put another way, if we build a minimal 'coded term' concept into the AOM, as we do today in openEHR, we are helping to reduce the Data type mismatch problem in e-health (a bit).
Enabling tools to know about coded elements
In the first version above, the class CODED_TEXT is like any other non-terminal type, and an archetype tool that doesn't have special code in it won't know it is really what we health informatics people know as a 'coded term', one of our most basic data types. I think this is important because of the ubiquity of coded terms in data and therefore archetypes - tools that can't recognise them obfuscate what should be clear.
Conclusions
One conclusion that could be drawn from the above is that we should simply consider a 'coded term' as a kind of leaf data type in ADL and AOM. We already have multi-part dates, times and URI as leaf types, which provide the same 2 advantages above for those types: why not for terms? If we did accept that, I am only talking about a minimal model, e.g. in ADL a coded term would be a lexical element of the form
...
This is essentially the same approach we use for representing the ISO8601-based date/time types in openEHR - a String 'value' and a collection of extractor routines.
A new ADL Syntax proposal: Tuple constraints
The second kind of 'special' type in ADL we use in openEHR is the C_DV_QUANTITY constraint. To revisit the underlying problem:
In realistic data, it is not uncommon to need to constrain object properties in a covarying way. A simple example is the need to state range constraints on a temperature, represented as a Quantity type, for both Centigrade and Fahrenheit scales. The default way to do this in ADL is:
value matches {
QUANTITY [at0014] matches {
property matches {[at4]} – bind to SCT temperature
units matches {[at5]} – bind to SCT/UCUM 'deg C'
magnitude matches {|32.0..212.0|}
}
QUANTITY [at0015] matches {
property matches {[at4]} – bind to SCT temperature
units matches {[at6]} – bind to SCT/UCUM 'deg F'
magnitude matches {|0.0..100.0|}
}
}
...
value matches {
QUANTITY matches {
property matches {[at4]} – at4 bind-> SCT 'temperature'
[units, magnitude] matches {
[{[at5]}, {|32.0..212.0|}] , – at5 bind-> UCUM or SCT oF
[{[at6]}, {|0.0..100.0|}] – at6 bind-> UCUM or SCT oC
}
}
}
In the above, the {} surrounding each leaf level constraint are needed because although such constraints are typically atomic, as above, they may also take other standard ADL forms such as a list of strings, list of integers etc. In the latter case, the ',' characters from such lists will be conflated with the ',' separator of the distinct constraints in the tuple. Use of {} is also logically justified: each such entity is indeed a 'constraint' in the ADL sense, and all constraints are delimited by {}.
...