[FORGED] Re: Strange use of 'offset' as a settable RM attribute

Koray Atalag k.atalag at auckland.ac.nz
Tue Feb 16 21:02:27 EST 2016


Hi Diego,

That sounds like a sensible solution – does that mean it will need to be represented with a different statement/grammar? What changes are necessary to accommodate these kind of assertions? Sorry I’m not familiar with this.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Diego Boscá
Sent: Monday, 15 February 2016 11:49 p.m.
To: For openEHR technical discussions
Subject: [FORGED] Re: Strange use of 'offset' as a settable RM attribute

Probably these kinds of constraints should be assertions instead. This would allow to constrain both the attributes and define assertions on the functions.

2016-02-15 11:25 GMT+01:00 Sebastian Garde <sebastian.garde at oceaninformatics.com<mailto:sebastian.garde at oceaninformatics.com>>:
We have been through this a long time ago I think, with Koray having the exact question and opinion I had.

The downside if you don't allow this kind of constraint(!) on functional attributes in archetypes, here you cannot constrain the other two (real) attributes when modelling an archetype either because they depend on the actual time when documenting data and thus you don’t really have a way of constraining it at all.

How to actually handle this generically when you receive actual attribute values that are approximately correct, but not - say – to the second, seems problematic though as Heath has just said.
You can hardly reject an APGAR 5 min score because it was documented to be taken after 5 min and 2 seconds (who knows it that exact anyway!).
In other archetypes, a difference of a few seconds may of course be very significant.

Maybe all this is an indication that (some) fixed events like the ones in the APGAR archetype should be modelled differently - e.g. a repeated Cluster with an explicit time element (or a coded text with its values tied to the respective Snomed codes, something like this (even if it seems less elegant). And then avoid constraining the offset.
To me it is not too helpful to formally constrain the offset without also _formally_ defining what the base line (origin) is (=the time of birth). This is just indicated in the purpose of the archetype.
Since you cannot really easily do this, I don’t see much value in modelling this by constraining the offset. And there aren’t many other example where the offset is constrained in archetypes I have seen. Defining the precedence of time and offset would be another way as Koray says.

By the way, EVENT/Offset is actually not the only functional attribute that I have seen constrained:

•         is_integral for a DV_PROPORTION or

•         type for a PARTY_RELATIONSHIP (here type==name, which makes it a bit easier)

are others, but they are probably easier to manage than the offset.

We used to have a check in CKM to at least inform about these “commonly constrained functional properties” as we called them, but took it out, because it was too confusing.

Cheers
Sebastian

From: openEHR-technical [mailto:openehr-technical-bounces at lists.openehr.org<mailto:openehr-technical-bounces at lists.openehr.org>] On Behalf Of Heath Frankel
Sent: Montag, 15. Februar 2016 07:53
To: For openEHR technical discussions <openehr-technical at lists.openehr.org<mailto:openehr-technical at lists.openehr.org>>
Subject: Re: Strange use of 'offset' as a settable RM attribute

Does our opt validator validate a data instance against this? Yes.
It causes all sorts of problems in scenarios like apgar when event times are real rather than derived from the origin and this constraint.
Regards

Heath


On Sun, Feb 14, 2016 at 11:34 AM -0800, "Ian McNicoll" <ian at freshehr.com<mailto:ian at freshehr.com>> wrote:
Thanks Heath,

That makes sense. Does OceanEHR validate the constraint?

Ian

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

[Image removed by sender.]
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 14 February 2016 at 19:02, Heath Frankel <heath.frankel at oceaninformatics.com<mailto:heath.frankel at oceaninformatics.com>> wrote:
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

[Image removed by sender.]
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



_______________________________________________
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


_______________________________________________
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/20160217/d877bcf9/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 823 bytes
Desc: image001.jpg
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20160217/d877bcf9/attachment.jpg>


More information about the openEHR-technical mailing list