...
| Code Block |
|---|
definition
EVALUATION[id1] matches { -- Substance Use Summary
data matches {
ITEM_TREE[id2] matches {
items cardinality matches {1..*; unordered} matches {
ELEMENT[id6] occurrences matches {0..1} matches {...} -- Substance
ELEMENT[id3] occurrences matches {0..1} matches { -- Usage Status
value matches {
DV_CODED_TEXT[id18] matches {
defining_code matches {[ac1]} -- Usage Status
}
}
}
CLUSTER[id8] -- Consumption summary
occurrences matches -- ********
(/data[id2]/items[id3]/value[id18] /= [at17]) {1..*} -- at17 is 'never used'
{0..*} -- default is 0..* occurrences
matches {
items matches {
ELEMENT[id9] occurrences matches {0..1} matches { -- Form
value matches {
DV_TEXT[id19]
}
}
ELEMENT[id16] occurrences matches {0..1} matches {...} -- Method of use
ELEMENT[id10] occurrences matches {0..1} matches {...} -- Date commenced
ELEMENT[id11] occurrences matches {0..1} matches {...} -- Age commenced
ELEMENT[id12] occurrences matches {0..1} matches {...} -- Date ceased
ELEMENT[id13] occurrences matches {0..1} matches {...} -- Age ceased
ELEMENT[id14] occurrences matches {0..1} matches {...} -- Comment
}
}
allow_archetype CLUSTER[id15] matches { -- Cessation attempts
include
archetype_id/value matches {/openEHR-EHR-CLUSTER\.cessation_attempts\.v1/}
}
}
}
}
}
|
...
The potential advantage of such an approach is that it ties the occurrences of a subtree to the values of its determining data item from elsewhere in the archetype. The disadvantage is a) somewhat ugly ADL and b) it complicates the AOM, since 'occurrences' is currently a simple attribute of type `MULTIPLICITY_INTERVAL` in `C_OBJECT`. MULTIPLICITY_INTERVAL in C_OBJECT.
A related alternative may be to revert to stating an additional constraint in the rules section, but in the same way as above, i.e.:
| Code Block |
|---|
definition
EVALUATION[id1] matches { -- Substance Use Summary
data matches {
ITEM_TREE[id2] matches {
items cardinality matches {1..*; unordered} matches {
ELEMENT[id6] occurrences matches {0..1} matches {...} -- Substance
ELEMENT[id3] occurrences matches {0..1} matches {...} -- Usage Status
CLUSTER[id8] occurrences matches {0..*} matches {-- Consumption summary
items matches {
ELEMENT[id9] occurrences matches {0..1} matches {...} -- Form
ELEMENT[id16] occurrences matches {0..1} matches {...} -- Method of use
ELEMENT[id10] occurrences matches {0..1} matches {...} -- Date commenced
ELEMENT[id11] occurrences matches {0..1} matches {...} -- Age commenced
ELEMENT[id12] occurrences matches {0..1} matches {...} -- Date ceased
ELEMENT[id13] occurrences matches {0..1} matches {...} -- Age ceased
ELEMENT[id14] occurrences matches {0..1} matches {...} -- Comment
}
}
allow_archetype CLUSTER[id15] matches {...}
}
}
}
}
rules
/data[id2]/items[id8]
occurrences matches
(/data[id2]/items[id3]/value[id18] /= [at17]) {1..*} -- at17 is 'never used'
{0..*} -- default is 0..* occurrences |
This approach preserves the original simplicity of the ADL/AOM structure, and treats the tighter constraint as a rule that is attached to the /data[id2]/items[id8] (consumption summary) path, rather than being just a rule in a set of rules. The advantages here are that changes to the AOM are in the rules section rather than in C_OBJECT. A disadvantage is that it would be in theory possible to write contradicting constraints, which require more validation complexity to detect.