Have a look at the following extract from the ordinal test archetype:
SOME_TYPE[at0000] matches { – root item
standard_ordinal_attr matches {
DV_ORDINAL [at0004] matches {
value matches {|0|}
symbol matches {
DV_CODED_TEXT matches {
defining_code matches {[local::at0001]} – +
}
}
}
DV_ORDINAL [at0005] matches {
value matches {|1|}
symbol matches {
DV_CODED_TEXT matches {
defining_code matches {[local::at0002]} – ++
}
}
}
DV_ORDINAL [at0006] matches {
value matches {|2|}
symbol matches {
DV_CODED_TEXT matches {
defining_code matches {[local::at0003]} – +++
}
}
}
}
clinical_ordinal_attr_1 matches {
0|[local::at0001], – +
1|[local::at0002], – ++
2|[local::at0003]; – +++
0 – assumed value
}
}
The red part above is how you have to constrain an ORDINAL with standard ADL, while the blue part is how you do it with a C_DV_ORDINAL and its special syntax, defined in the openEHR Archteype Profile. It’s an unavoidable consequence of the logic of constraint that when you want to constrain 2 covarying attributes (in this case, DV_ORDINAL.value and DV_ORDINAL.symbol), you can’t do it efficiently using standard ADL/AOM. Therefore we added the capability to do this with a plug-in type. DV_ORDINALs are ubiquitous in medicine, so it seems worthwhile. Similar arguments go for the C_DV_QUANTITY and C_CODE_PHRASE plug-in types.
The LinkEHR tool follows the EN13606-2 specification, which did not include these plug-in types, so it can only use standard ADL constructs to express the constraints.
Looking ahead, there are probably two solutions:
- we stick with the openEHR approach of plug-in types and syntax extensions (at least we know this works);
- or we invent a new ‘standard ADL’ construct that allows covariance to be better expressed.
If we went for the latter, it might look something like:
DV_ORDINAL [at0006] matches {
{value | symbol/defining_code} matches {
0 | [local::at0001],
1 | [local::at0001],
2 | [local::at0001];
0
}
}
(I used ‘|’ instead of ‘,’ since ‘,’ is already being used as the list item separator). If this existed, it is effectively telling the parser to build something like C_DV_ORDINAL on the fly. Of course, it would work for other types too. I am not sure that it is very intuitive though.
Another possibility might be (to try to stick with the more normal comma delimiter everywhere, and more ‘set logic’ feel):
DV_ORDINAL [at0006] matches {
{value, symbol/defining_code} matches {
{0, [local::at0001]},
{1, [local::at0001]},
{2, [local::at0001]};
0
}
}
Either way, the corresponding AOM construct would be somewhat complicated. It might be worth the extra complexity to obtain the generality, but it will certainly entail some additional complexity in parsers, validators and serialisers.
For DV_QUANTITYs, the argument is the same, except there is no special syntax, we just use a straight object-serialisation of the plug-in construct in dADL. Here are the two ways of doing a DV_QUANTITY, from the DV_QUANTITY test archetype:
standard_quantity_attr matches {
DV_QUANTITY [at0001] matches {
-- property matches {"temperature"}
units matches {"C"}
magnitude matches {|>=4.0|}
}
DV_QUANTITY [at0002] matches {
-- property matches {"temperature"}
units matches {"F"}
magnitude matches {|>=40.0|}
}
}
clinical_quantity_attr_1 matches {
(C_DV_QUANTITY) <
assumed_value = <
units = <"C">
precision = <0>
magnitude = <8.0>
>
property = <[openehr::127]>
list = <
["1"] = <
<b> units = <"C">
magnitude = <|>=4.0|></b>
>
["2"] = <
<b> units = <"F">
magnitude = <|>=40.0|></b>
>
>
>
}
You can see the covarying attributes in bold in the blue part. In the red part, there is no way at all to constrain ‘property’, because it is not in the reference model, and constraining assumed value is difficult as well.
