@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? -- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com<http://cabolabs.com/es/home><http://twitter.com/ppazos> ________________________________ From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf of Pieter Bos <pieter....@nedap.com> Sent: Tuesday, November 1, 2016 7:22:48 AM To: openeh technical; openehr clinical Subject: Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives 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 From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf of pablo pazos <pazospa...@hotmail.com> Reply-To: openeh technical <openehr-technical@lists.openehr.org> Date: Monday 31 October 2016 at 17:08 To: openehr clinical <openehr-clini...@lists.openehr.org>, openeh technical <openehr-technical@lists.openehr.org> Subject: Question about paths to C_SINGLE_ATTRIBUTE alternatives 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? -- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com<http://cabolabs.com/es/home> _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
