Have a look at the following extract from the ordinal test archetype
<http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/ADL_1.5_test/validity/c_domain_types/openehr-test_pkg-SOME_TYPE.ordinals.v1.adls>:
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
<imap://tb015k8416 at
imap.blueyonder.co.uk:993/fetch%3EUID%3E/%5BGmail%5D/All%20Mail%3E4631/;section=2.2?part=1.2.2&filename=openehr_archetype_profile.pdf>.
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
<http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/ADL_1.5_test/validity/c_domain_types/openehr-test_pkg-SOME_TYPE.c_dv_quantity.v1.adls>:
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"] =<
* units =<"C">
magnitude =<|>=4.0|>*
>
["2"] =<
* units =<"F">
magnitude =<|>=40.0|>*
>
>
>
}
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.
- thomas
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120624/7921d77d/attachment.html>
