archetypes - distniguishing multiple alternative constraints of a single-valued attribute

Here is a technical problem which is so far very rare, but probably requires a better solution than we have now. In the current release of the ADL specification, section 5.3.3 describes rules for constraints on a single-valued attribute:

5.3.3 Single-valued Attributes
Repeated blocks of object constraints of the same class (or its subtypes) can have two possible meanings in cADL, depending on whether the cardinality is present or not in the containing attribute block. With no cardinality, the meaning is that each child object constraint of the attribute in question is a possible alternative for the value of the attribute in the data, as shown in the following example:

ELEMENT[at0004] matches { – speed limit
value matches {
QUANTITY matches {
magnitude matches {|0..55|}
property matches {“velocity”}
units matches {“mph”} – miles per hour
}
QUANTITY matches {
magnitude matches {|0..100|}
property matches {“velocity”}
units matches {“km/h”} – km per hour
}
}
}

Here, the cardinality of the value attribute is 1..1 (the default), while the occurrences of both QUANTITY constraints is optional, leading to the result that only one QUANTITY instance can appear in runtime data, and it can match either of the constraints.

Two or more object blocks introduced by type names appearing after a single-valued attribute (i.e. for which there is no cardinality constraint) are taken to be alternative constraints, only one of which needs to be matched by the data.

Note that there is a more efficient way to express the above example, using domain type extensions See Customising ADL on page 117 for examples.

In the current work I am engaged in to tighten up the semantics of specialisation, we have the problem that if the above kind of constraint were stated, and needed to be specialised in a child archetype, it is difficult to achieve without [at-code] markers as we have on higher-level nodes in archetypes. Currently, no at-codes are used on objects nodes defining constraints on the ELEMENT.value attribute, becasuse none is needed - it does not add anything useful, and would require pointless pollution of the archetype ontology with obvious definitions like ‘quantity constraint’. However, in a very small number of cases, I believe that the above kind of construction, using more than one alternative is actually used. To allow specialised archetypes to redefine such constraints, we would need to mandate the use of at-codes where such alternatives were created.

If the impact was minimal, I would be tempted to propose that this rule be added to ADL, to ensure that specialisation can always work unambiguously.

any feedback on this idea welcome.

  • thomas beale

Hi Thomas,

Other than the requirement for specialisation, am I correct in thinking that this would give us ‘named choices’ which I have suggested in the past (along with named slots)? This would be very helpful in understanding the thinking behind the choice construction which is not always evident, particularly when selecting appropriate an appropriate choice at template time.

Does a similar issue apply to archetype slots? A common construct is to place archetype slots within a cluster so that they can be ‘named’. This seems to me to unnecessarily overcomplicate the archetype.

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll

Consultant - Ocean Informatics ian.mcnicoll@oceaninformatics.com
Consultant - IRIS GP Accounts

Member of BCS Primary Health Care Specialist Group – www.phcsg.org

2008/7/15 Thomas Beale <thomas.beale@oceaninformatics.com>:

Hello,

I totally agree. When we implemented the semantics of specialisation in LinkEHR-Ed we also took that decission. Since LinkEHR-Ed is mainly based on archetype specialisations, we always need to have identifiers for every node and for that reason we automatically complete every node with an internally generated [at-code]. In fact, we have never understood why the node_id attribute is mandatory in the C_OBJECT of the AOM but it is not in the ADL syntax.

2008/7/15 Thomas Beale <thomas.beale@oceaninformatics.com>:

Ian McNicoll wrote:

Hi Thomas,

Other than the requirement for specialisation, am I correct in
thinking that this would give us 'named choices' which I have
suggested in the past (along with named slots)? This would be very
helpful in understanding the thinking behind the choice construction
which is not always evident, particularly when selecting appropriate
an appropriate choice at template time.

yes - you could think of it like that.

Does a similar issue apply to archetype slots? A common construct is
to place archetype slots within a cluster so that they can be 'named'.
This seems to me to unnecessarily overcomplicate the archetype.

this is certainly the wrong thing to do, and the specification already
supports at-codes on slots, just that the current tools don't, or there
is mixed support at best (hence this workaround). This needs to be fixed.

- thomas

David Moner wrote:

Hello,

I totally agree. When we implemented the semantics of specialisation in LinkEHR-Ed we also took that decission. Since LinkEHR-Ed is mainly based on archetype specialisations, we always need to have identifiers for every node and for that reason we automatically complete every node with an internally generated [at-code]. In fact, we have never understood why the node_id attribute is mandatory in the C_OBJECT of the AOM but it is not in the ADL syntax.

Hi David,

two reasons:

  • it is not needed in a lot of places, e.g. OBSERVATION.data (HISTORY block), protocol (ITEM_STRUCTURE) block, and pollutes the archetype ontology with useless definitions like ‘history’, ‘tree’ etc.
  • it is not used or expected in Xpaths where there are not multiple children to be distinguished.
    The paths are now much more readable and sensible, e.g. the following from the EVALUATION.problem archetype on openEHR.org:

/data/items[at0002]/value – /data/items[Problem]/value
/data/items[at0003]/value/value – /data/items[Date of initial onset]/value/value
/data/items[at0004]/value/value – /data/items[Age at initial onset]/value/value
/data/items[at0005]/value – /data/items[Severity]/value
/data/items[at0009]/value – /data/items[Clinical description]/value
/data/items[at0010]/value/value – /data/items[Date clinically recognised]/value/value

The paths used to look like:
/data[at0001]/items[at0002]/value – /data[Tree]//items[Problem]/value
etc

OBSERVATION paths were worse.

The rule for using node ids in archetypes I believe should be as follows:

Node identifiers are required for any object node that is intended to be addressable elsewhere in the cADL text, or in the runtime system and which would otherwise be ambiguous i.e. has sibling nodes. This includes any child object constraint of a multiply-valued attribute, and child objects of single-valued attributes where there are more than one.

This doesn’t prevent you putting superfluous at-codes on nodes that don’t need them, but I think such codes don’t add anything, and tools should ignore them.

  • thomas

Hi

One important consideration is the embedded archetype. This has an archetype node id even if it is superfluous from a coding perspective.

Cheers, Sam

Thomas Beale wrote:

(attachments)

OceanInformaticsl.JPG

David Moner wrote:

Hi,

In LinkEHR, every C_COMPLEX_OBJECT must have its own at-code. From our point of view, when you define an archetype you are defining set of types (type = Object node) constraining the types (classes) of RM or the parent archetype if it exists. Then it is necessary to have a unique identifier for every single constrained type. This has nothing to do with the fact that some of these types need an ontological description with their associated text, description or terminological binding. But when this is not needed, we just leave the ontology reference void or with a generic description:

PQ[at0005] occurrences matches {1..1} matches { – PQ
units matches {
CS[at0009] occurrences matches {0..1} matches { – CS
codeValue existence matches {0..1} matches {“mm[Hg]”}
codingSchemeName existence matches {0..1} matches {“UCUM”}
}
}
value matches {|0.0..<1000.0|}
}

[“at0005”] = <
text = <“PQ”>
description = <“This is a PQ object”>

[“at0009”] = <
text = <“CS”>
description = <“This is a CS object”>

You are right when you say that this may “pollute” the ontology and the paths, but this is a minimal problem since at the end, archetypes should be managed by the appropriate tools that can hide this extra information very easily.

With regard to using implicit order-based ids, it doesn’t seem a very good solution since it may have conflicts with the values of some attributes of the RM in data instances, e.g the LOCATABLE.archetype_node_id which explicitly requires a valid atXXXX syntax.

2008/7/17 Thomas Beale <thomas.beale@oceaninformatics.com>: