Both ADL1.4 and ADL2 support assertions (rules in ADL2) http://www.openehr.org/releases/AM/latest/docs/ADL1.4/ADL1.4.html#_assertions
http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_rules_2 The bad news about that is that I believe that no ADL editor supports them yet (as far as I know). We are now researching in this area and will have some results in the near future. 2016-02-17 3:02 GMT+01:00 Koray Atalag <k.ata...@auckland.ac.nz>: > 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-boun...@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.ga...@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-boun...@lists.openehr.org] *On Behalf Of *Heath Frankel > *Sent:* Montag, 15. Februar 2016 07:53 > *To:* For openEHR technical discussions < > openehr-technical@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" <i...@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: i...@freshehr.com > twitter: @ianmcnicoll > > [image: Image removed by sender.] > > Co-Chair, openEHR Foundation ian.mcnic...@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.fran...@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 <i...@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@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: i...@freshehr.com > twitter: @ianmcnicoll > > [image: Image removed by sender.] > > Co-Chair, openEHR Foundation ian.mcnic...@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.ata...@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@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 > > > > > _______________________________________________ > 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 >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
