On 15/08/2012 01:10, Heath Frankel wrote:
>
> Hi Seref/Thomas,
>
> Node IDs at0022 and at0023 have no semantic significance, they are
> just a value of a speed limit element no matter if they are in km/h or
> mph. These are just alternative value constraints on the value due to
> different units allowed and range when using that unit. When you query
> you would want to get all speed limit values and if you needed to
> compare then you need to convert based on the units.
>
Hi Heath,
you are no doubt assuming that the 'QUANTITY' type in the RM doesn't
carry archetype node+id information, which is indeed the case for
DV_QUANTITY as used in openEHR, but I was not assuming that for the
example. In that case you are right of course - querying would have to
take account of it in another way. One thing we potentially should do is
include the 'property' attribute in DV_QUANTITY, for just this purpose.
I will add something to the documentation to indicate these subtleties.
> The instance should actually look like the following
>
> items = <
>
> ["1"] = < -- ELEMENT
>
> archetype_node_id = <"at0004">
>
> value = < -- QUANTITY
>
> units = <"mph">
>
> magnitude = <25>
>
> >
>
> >
>
> ["2"] = <....>
>
> etc
>
> >
>
> However, one area that is problematic is in the validator, how do we
> know which constraint we should use when the constraints are
> ambiguous. The example provided previously does no have this issue but
> if you consider an element with an alternative values of type DV_TEXT
> allowing free text and DV_CODED_TEXT in some specified terminology.
>
> ELEMENT[at0004] matches {
>
> value matches {
>
> DV_TEXT matches { * }
>
> DV_CODED_TEXT matches { -- km per hour
>
> defining_code matches { |SNOMED-CT::| }
>
> }
>
> }
>
> }
>
> This cases doesn't require at-codes because they are different types,
> but they are still ambiguous due to the inheritance allowing any coded
> term to be used, not just the specified term.
>
> Here it would be nice to have an at-code in the instance to
> differentiate which alternative is being used.
>
*
* as it happens, due to another discussion I have already changed this
rule to say force at-codes even if the RM types are different under a
single-valued attribute. This will be annoying for some current
archetypes, but that's life.
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120815/dc1f421c/attachment-0001.html>
