Strange use of 'offset' as a settable RM attribute

Technical (archive)
1

Hi,

We noted it is possible to set values from AE/TD to a RM attribute named “offset”

In the specs (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

2

Hi Koray,

I agree - can you create a JIRA PR at …

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

Ian

3

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

4

Thanks Heath,

That makes sense. Does OceanEHR validate the constraint?

Ian

5

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

6

Thanks Heath,

Setting a value constraint makes sense – do you allow negative offset? We have some time series observation data where offset is negative. In practice it doesn’t make much sense but in reality it exists.

I can also imagine the sort of problems you may be facing – does this mean we should perhaps define priority/preference over EVENT.time vs. EVENT.offset. Obviously we got a problem when both exists.

7

it just checks that the value EVENT.offset, when called at runtime, is within some range or equal to some value. if EVENT.offset doesn’t return a valid value, its implementation has a bug. - thomas

8

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

(attachments)

WRD0000.jpg

9

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

(attachments)

WRD0000.jpg

10

yep - that’s why it’s there. in theory yes, and if the event values will be set from system clock values or device-generated values, this is correct. However, if they will be entered by a human from a drop-down choice or similar, then if the choices are ‘1 min’, ‘2 mins’, … ‘10 mins’, the events will clearly have exact and valid time offsets according to the constraint. I don’t think so - I think the current way of doing it is clinically very clear in the case of Apgar and any other situation in which the offsets are somewhat notional, and the times will be entered by the clinician (disregarding actual seconds differences). Historical note: the current way of doing this was the one requested by clinical people some years ago (I argued against it). But I don’t see a general problem with constraints on computed properties - to evaluate them you need functions to operate on the data, i.e. just a normal implementation. If someone wants to try and evaluate validity of data against an archetype using only a data view, e.g. in XML, then I think functional properties mentioned in archetypes will need e.g. Xquery or schematron or some other kind of evaluatable expressions that can be attached to the schema. Our early conceptions of how to do data/archetype validity checking always involved an ‘archetype kernel’ concept, i.e. a materialised object graph and archetype graph in the same compute space. In that approach you have all the functions of the relevant object types, and validating with function-based constraints is easy. There may be better conceptual approaches today. - thomas

11

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

(attachments)

WRD0000.jpg

12

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.

(attachments)

WRD0000.jpg

13

Using the rules could be a useful approach. One thing we decided in the SEC meeting last week was to rework the ‘rules’ part of ADL as a small core model in the BASE component and then re-use that back into ADL2 and also GDL. This will result in a new small BASE/Rules specification and the ADL2 and GDL models of rules will then be rewritten to be based on this. I’m working on the BASE/Rules component right now, and will put it up very soon in draft (status = DEVELOPMENT) form, so anyone can have a go at working on it.

I’ve managed to clean up some of the semantics around functions and variables etc, so I think the initial version will be reasonable. There are others who know this area better than I do, so I encourage them to have a look and if interested to contribute to improving the models, get involved.

BTW the ADL workbench does display rules:

  • thomas
14

Thanks Tom – this could finally make me an ADL Workbench user :wink:

(attachments)

ghbjdfhj.png