Hi Thomas, I actually didn't even consider the fact that DV_QUANTITY didn't have a node ID property, but good point. My point was that the units property provides the information required to determine if a speed limit value was mph or km/h.
Not sure I like the idea of adding the property attribute to DV_QUANTITY, this is metadata that can be derived from the archetype if required but I just don't see the use case. I think we have more than enough metadata in the instance already. Heath From: openehr-technical-boun...@lists.openehr.org [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Thomas Beale Sent: Wednesday, 15 August 2012 8:02 PM To: openehr-technical at lists.openehr.org Subject: Re: Should not node identifiers in runtime paths be mandatory? 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/20120816/b44b1d59/attachment-0001.html>
