Question about paths to C_SINGLE_ATTRIBUTE alternatives

Diego Boscá yampeku at gmail.com
Mon Oct 31 12:59:06 EDT 2016


I think we have discussed this several times (and I'm happy with
current ADL2 implementation :)

I believe that the only way of querying or filtering these paths is to
look in the RM for some attribute that is not in any of the other
types. If this is not possible (e.g. domain types are implicitly a set
of sibling nodes from the same class) you have to know the values that
would make that path unique (in case of the domain type in your
example it would be the implicit code_string values from the
CODE_PHRASE).
This makes your queries bound to a given version of your RM (also, it
makes the queries harder to be translated to other standards). I can't
think a better way of achieving this.

Regards

2016-10-31 17:15 GMT+01:00 Thomas Beale <thomas.beale at openehr.org>:
>
> These are ADL 1.4 archetypes, and the rule there was that alternative nodes
> had to be of different RM types, so that an instance in the data of DV_TIME
> under ELEMENT[at0004] could be connected with the DV_TIME child node in the
> archetype.
>
>
> ADL 2 gets rid of this subtlety and simply requires node ids on all nodes,
> but only requires definitions of them in the terminology section where they
> need to be distinguished.
>
>
> - thomas
>
>
> On 31/10/2016 16:08, pablo pazos wrote:
>
> Hi,
>
>
> I was chatting with Diego, about the need of nodeIds for ELEMENT.value and I
> detected some archetypes with alternatives but no nodeIds, I guess, created
> with the Archetype Editor.
>
>
> Examples from openEHR-EHR-CLUSTER.timing_daily.v0
>
>
> ...
>
>             ELEMENT[at0004] occurrences matches {0..*} matches {    --
> Specific time
>                 value matches {
>                     DV_TIME matches {*}
>                     DV_INTERVAL<DV_TIME> matches {
>                         upper matches {
>                             DV_TIME matches {*}
>                         }
>                         lower matches {
>                             DV_TIME matches {*}
>                         }
>                     }
>                 }
>             }
>             ELEMENT[at0026] occurrences matches {0..*} matches {    -- Named
> time event
>                 value matches {
>                     DV_TEXT matches {*}
>                     DV_CODED_TEXT matches {
>                         defining_code matches {
>                             [local::
>                             at0031,     -- immediately (stat)
>                             at0032,     -- in the morning
>                             at0033,     -- at night
>                             at0034]    -- in the morning and at night
>                         }
>                     }
>                 }
>             }
>
> ...
>
>
>
> How can software create paths to the specific ELEMENT.value constraint if
> the constraints don't have a nodeId?
>
>
>
> This remembers me of an old discussion about if the nodeIds should or not be
> mandatory. Opinions?
>
>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org




More information about the openEHR-clinical mailing list