# Question about paths to C\_SINGLE\_ATTRIBUTE alternatives

**URL:** <https://discourse.openehr.org/t/question-about-paths-to-c-single-attribute-alternatives/15458>\
**Category:** Clinical (archive)\
**Created:** [31 October 2016 16:08 UTC](https://discourse.openehr.org/t/question-about-paths-to-c-single-attribute-alternatives/15458 "2016-10-31T16:08:05Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)\
**Post date:** [31 October 2016 16:08 UTC](https://discourse.openehr.org/t/question-about-paths-to-c-single-attribute-alternatives/15458/1 "2016-10-31T16:08:05Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [31 October 2016 16:15 UTC](https://discourse.openehr.org/t/question-about-paths-to-c-single-attribute-alternatives/15458/2 "2016-10-31T16:15:43Z")

</div>

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](http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_node_identifiers_2), but only requires definitions of them in the terminology section where they need to be distinguished.

- thomas

---

<div class="post-metadata">

**Author:** ![yampeku](https://discourse.openehr.org/user_avatar/discourse.openehr.org/yampeku/32/25_2.png) [@yampeku](https://discourse.openehr.org/u/yampeku)\
**Post date:** [31 October 2016 16:59 UTC](https://discourse.openehr.org/t/question-about-paths-to-c-single-attribute-alternatives/15458/3 "2016-10-31T16:59:06Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [1 November 2016 10:22 UTC](https://discourse.openehr.org/t/question-about-paths-to-c-single-attribute-alternatives/15458/4 "2016-11-01T10:22:48Z")

</div>

I fully agree that they should be mandatory. Things like this make writing software based on OpenEHR more complex than it could be.

I also never understood that the DV\_-types do not have an archetype node id in the reference model. This adds complexity, because the paths in an archetype do not always match the paths in a reference model object. Sometimes you just need paths based on an archetype that need to work in reference model objects. For example when displaying information, rendering forms, evaluating rules or score calculations, or rendering a UI to edit stored reference model objects. Of course, you can write something that converts these paths from the AOM to the RM, but I don’t see why that should be necessary.

Perhaps someone can explain the reasoning behind these choices?

Regards,

Pieter Bos  
Nedap Healthcare

---

<div class="post-metadata">

**Author:** ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)\
**Post date:** [3 November 2016 02:57 UTC](https://discourse.openehr.org/t/question-about-paths-to-c-single-attribute-alternatives/15458/5 "2016-11-03T02:57:14Z")

</div>

@Thomas thanks for the pointer.

We were talking with Diego about the need of storing the nodeId in the IM for datatypes to allow querying over specific DV alternatives of an ELEMENT.value, because for path-based queries having nodeId for DV is easier to implement than trying to derive the DV from it’s attributes in the path.

I think this goes in the lines of what Pieter commented on his email.

@All is there any change request to the IM for adding a nodeId field for DATAVALUE, or maybe make it extend LOCATABLE?  
Is there any constraint for making DATAVALUE extend LOCATABLE?

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [3 November 2016 11:02 UTC](https://discourse.openehr.org/t/question-about-paths-to-c-single-attribute-alternatives/15458/6 "2016-11-03T11:02:41Z")

</div>

Hi Pieter,

this is because they don’t inherit from LOCATABLE, which is a modelling decision from a long time ago. I’m not aware that it has caused major problems (at least not reported ones) but I can imagine that it might seem better today to make DATA\_VALUE inherit from LOCATABLE, or at least to have the archetype\_node\_id field in it. I’m not that clear on how much it matters in anyone’s implementation. well the RM objects, down to the ELEMENT nodes, should have archetype paths that match the archetypes that create them, with the added complexity that real data may contain multiple instances that match a given archetype path, as . Can you provide more detail on what ‘conversion’ you are referring to here? thanks - thomas

---

<div class="post-metadata">

**Author:** ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)\
**Post date:** [7 November 2016 18:39 UTC](https://discourse.openehr.org/t/question-about-paths-to-c-single-attribute-alternatives/15458/7 "2016-11-07T18:39:01Z")

</div>

Hi Thomas, do you recall if we have any change request to make dvs inherit from locatable?

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [23 November 2016 16:15 UTC](https://discourse.openehr.org/t/question-about-paths-to-c-single-attribute-alternatives/15458/8 "2016-11-23T16:15:56Z")

</div>

So far we have a [Problem Report](https://openehr.atlassian.net/projects/SPECPR/issues/SPECPR-210) which I think needs to be discussed by the Specifictions Editorial Committee in the normal way to decide if it becomes a CR, what release it would go in and so on.

- thomas