Strange use of 'offset' as a settable RM attribute

Heath Frankel heath.frankel at oceaninformatics.com
Sun Feb 14 14:02:15 EST 2016


Hi Koray,
This is a constraint on the value that origin function returns rather than indicating it is a settable attribute. This was how Sam defined the events on an apgar score, 1 min, 5 min, etc.

Regards

Heath

_____________________________
From: Ian McNicoll <ian at freshehr.com<mailto:ian at freshehr.com>>
Sent: Sunday, February 14, 2016 5:10 AM
Subject: Re: Strange use of 'offset' as a settable RM attribute
To: For openEHR technical discussions <openehr-technical at lists.openehr.org<mailto:openehr-technical at lists.openehr.org>>


Hi Koray,

I agree - can you create a JIRA PR at ...

https://openehr.atlassian.net/projects/AEPR/issues/AEPR-45?filter=allopenissues

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859<tel:+44%20775%20209%207859>
office +44 (0)1536 414994<tel:+44%201536%20414994>
skype: ianmcnicoll
email: ian at freshehr.com<mailto:ian at freshehr.com>
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download]
Co-Chair, openEHR Foundation ian.mcnicoll at openehr.org<mailto:ian.mcnicoll at openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 12 February 2016 at 04:29, Koray Atalag <k.atalag at auckland.ac.nz<mailto:k.atalag at auckland.ac.nz>> wrote:
Hi,

We noted it is possible to set values from AE/TD to a RM attribute named "offset"
In the specs<http://www.openehr.org/releases/RM/Release-1.0.3/docs/data_structures/data_structures.html#_event_class> (looked at >1.0.1) it is not a regular attribute but a function which returns a computed value using diff HISTORY.origin and EVENT.time
Note that this diff can also be a negative value - which doesn't seem to be supported by AE/TD or in instance data

An example ADL:

POINT_EVENT[at0002] occurrences matches {0..*} matches {        -- Any event
               offset matches {
                              DV_DURATION matches {
                                             value matches {|PT0.125S|}
                              }
               }

Isn't this weird?
I would expect this to return a value if a valid ISO8601 time has been entered for both HISTORY.origin and EVENT.time but not set as an attribute directly.

Cheers,

-koray


_______________________________________________
openEHR-technical mailing list
openEHR-technical at lists.openehr.org<mailto:openEHR-technical at lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20160214/0c40cdbd/attachment-0002.html>


More information about the openEHR-technical mailing list