Strange use of 'offset' as a settable RM attribute

Diego Boscá yampeku at gmail.com
Mon Feb 15 05:49:16 EST 2016


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>:

> 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] *On Behalf Of *Heath Frankel
> *Sent:* Montag, 15. Februar 2016 07:53
> *To:* For openEHR technical discussions <
> 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>
> wrote:
>
> Thanks Heath,
>
>
>
> That makes sense. Does OceanEHR validate the constraint?
>
>
>
> Ian
>
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: ian at freshehr.com
> twitter: @ianmcnicoll
>
> [image: Image removed by sender.]
>
> Co-Chair, openEHR Foundation 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> 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>
> 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>
>
>
>
>
> 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 <+44%20775%20209%207859>
> office +44 (0)1536 414994 <+44%201536%20414994>
> skype: ianmcnicoll
> email: ian at freshehr.com
> twitter: @ianmcnicoll
>
> [image: Image removed by sender.]
>
> Co-Chair, openEHR Foundation 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>
> 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
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> 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
>
> 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/20160215/ba029d34/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: not available
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20160215/ba029d34/attachment.jpg>


More information about the openEHR-technical mailing list