Questions about refinement via specialisation example (ADL2)

Specifications ADL
1

I’m a bit confused by the example given here in the ADL 2 spec.

The definition section from the base archetype is:

    -- openEHR-EHR-EVALUATION.problem.v1 --

    EVALUATION[id1] ∈ {                                              -- Problem
        data ∈ {
            ITEM_TREE[id2] ∈ {
                items cardinality ∈ {0..*; ordered} ∈ {
                    ELEMENT[id3] occurrences ∈ {1} ∈ {
                        value ∈ {
                            DV_TEXT[id4]                             -- *** NODE A
                        }
                    }
                    ELEMENT[id5] occurrences ∈ {0..1} ∈ {...}       -- Date of initial onset
                    ELEMENT[id6] occurrences ∈ {0..1} ∈ {...}       -- Age at initial onset
                    ELEMENT[id7] occurrences ∈ {0..1} ∈ {...}       -- Severity
                    ELEMENT[id8] occurrences ∈ {0..1} ∈ {...}       -- Clinical description
                    ELEMENT[id10] occurrences ∈ {0..1} ∈ {...}      -- Date clinically received
                    CLUSTER[id11] occurrences ∈ {0..1} ∈ {...}      -- Location
                    CLUSTER[id14] occurrences ∈ {0..1} ∈ {...}      -- Aetiology
                    -- etc
                }
            }
        }
    }

and the specialisation example is:

    -- openEHR-EHR-EVALUATION.problem-diagnosis.v1 --   -- specialises openEHR-EHR-EVALUATION.problem.v1

    EVALUATION[id1.1] ∈ {                               -- Recording of diagnosis
        /data[id2.1]/items[id3]/value ∈ {               -- redefine id2 to id2.1 (in terminology section)
            DV_CODED_TEXT[id4] ∈ {                      -- << This node redefines 'NODE A' above
                defining_code ∈ {[ac0.1]}
            }
        }
        /data/items cardinality ∈ {0..*; ordered} ∈ {
            before [id5]
            ELEMENT[id0.32] occurrences ∈ {0..1} ∈ {    -- Status    ++ This node added
                value ∈ {
                    DV_CODED_TEXT[id0.33] ∈ {
                        defining_code ∈ {
                            [local::at0.33, at0.34]      -- provisional
                        }
                    }
                }
            }
            after [id31]
            CLUSTER[id0.35] occurrences ∈ {0..1} ∈ {...}  -- Diag. criteria  ++ This node added
            CLUSTER[id0.37] occurrences ∈ {0..1} ∈ {...}  -- Clin. staging   ++ This node added
        }
    }

My questions follow:

  1. In the specialised archetype, the path to value is given as:
EVALUATION[id1.1] ∈ {                               -- Recording of diagnosis
        /data[id2.1]/items[id3]/value ...

why is the items path segment items[id3] but not items[id3.1] ? The definition of the object referred to by items attribute is modified (in two different ways) in the specialisation. Is an idNNN code only supposed to be modified when its meaning is modified? (as is the case with id1.1) Iow, is it the case that changes to id codes imply only a change in meaning and not a change in constraints defined by the following object (constraint) nodes?

  1. Why is the constraint that is at the path given above terminating with DV_CODED_TEXT[id4] and not DV_CODED_TEXT[id4.1] ? We just constrained the type to something that’s more strict than the parent archetype’s constraint at the same path?

  2. There’s a second modification (specialisation) taking place at the same level with 1) :

/data/items cardinality ∈ {0..*; ordered} ∈

why is this path not reflecting the changes made to id codes by the first one? i.e. ../data[id2.1]/.... The instances of newly inserted constraints in the data will be at path ../data[id2.1]/... as per the previous modification to id code.

  1. Look at this constraint:
defining_code ∈ {
                            [local::at0.33, at0.34]      -- provisional
                        }

is [local::at0.33, at0.34] still valid? My understanding of the spec after reading it again is that ADL2 replaces the semantic expressed in this syntax with defining an ac code which should point at a set of local codes (at) and using it as ..{[acNN]}(or something like this)

  1. There’s an overall ADL semantics mismatch here, at least acc. to my tired brain. When constraints are provided at the same level (i.e. they’re siblings) under a path and the path is that of a container type, then all the instances defined by constraints are valid members of the container. Great. Except, the two modifications under the EVALUATION[id1.1] have different paths, so they are sibling declarations of constraints, but they don’t constrain sibling elements/paths in the RM. This means that the structural semantics of the specialisation in ADL is different than that of non-specialised form. If true, I’m not sure of the implications, but this at least conflicts with what the spec says: there is no difference between parent and child archetype semantics except the child can ignore paths it is not modifying. Probably not significant, but I did notice it. Maybe I missed something.
2

The rule for when to redefine a node code is described in this section. Reproduced here:

A key question is: when does a node identifier need to be redefined? There are three possible situations:

  • when the node is the root node of an archetype, the meaning is always considered to be redefined;
  • it can be redefined for purely semantic purposes on other nodes, e.g. to redefine ‘heart rate’ to ‘fetal heart rate’;
  • a node identifier must be redefined if the node is being redefined into multiple child nodes, either under a multiply-valued attribute, or as alternatives under a single-valued attribute.

So by those rules, the id3 code doesn’t need to be redefined. The alternative, which was in an earlier revision of ADL was that a) if some node like the id2 node was redefined, all the node ids below it had to be redefined and b) if there was a constraint override on a node, the id had to be redefined. The new rules only require the code to be redefined if the meaning is redefined for some reason. If it stays the same, even when the constraint is redefined, then the code doesn’t need to change. With the previous way, codes were always be redefined but with no new definitions.

As far as we can tell, the current rules work fine in all the tools (which all use ADL2 these days, except the old Archetype Editor).

that would be a typo :wink: I’ll fix that.

Correct, value sets are no longer inline, they are mentioned once per archetype below. THis allows them to be referenced more than once in the archetype or any specialisation. With inline definition, you have to keep repeating the value set.

Well the first constraint is at path /data[id2.1]/items[id3]/value[id4] and the second at /data[id2.1]/items[id0.32], so those are not siblings. But I may not be understanding what you mean here…