By the way, shouldn't the 'property' of a DV_QUANTITY end up in the
term_definition of a node?
from the specifications, it says that must at least include 'text' and
'description', but more can be defined. For example, the specification
shows:
[?at4000?] = <
text = <"plan">;
description = <"The clinician's professional advice">;
provenance = <"ACME_terminology(v3.9a)">
>
Why don't use something like that to put 'property' (or even better,
'semantic group' to be more generic) and store the property there
[?at0001?] = <
text = <"measure">;
description = <"temperature measure">;
semantic_group= <"[openehr::127]"> --temperature
>
2012/6/24 Thomas Beale <thomas.beale at oceaninformatics.com>:
>
>
> 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"] = <
> 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
>
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
