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