Testing the Archetype Editor for OBSERVATION, found that defining a POINT_EVENT structure, allows to create a constraint for EVENT.offset, while that is a function by the v1.0.2 spec.
Another weird thing is that defining a POINT_EVENT, and saying the HISTORY is periodic, makes the panel for the offset definition disappear, but the offset is still on the generated ADL.
It seems that we have never found a full agreement between those who agree with constraining the value returned by methods, and those who think that it is not a recommendable approach.
BTW, I just checked that in LinkEHR we cannot constraint offset or any other method, since our main source for the RM is the XML Schema and it doesn’t define them.
the ontological problem here is that when dealing with time, you always want to constrain at design time in terms of relative amounts, usually offsets, durations etc. But at runtime, the time data are absolute times, that you cannot know at the outset.
This would not be a problem if we had made offset a data element, but then the time-point of an EVENT would need to be calculated by adding the offset to the origin, and even worse, setting it in the first place would have to be done by a subtraction.
Prbabaly the right way to get around this is to allow constraints of the form:
and so on. We are just rewriting the expressions language, so we can finally solve this any many other more complex constraints, with a single language, which will be common to GDL, Task Planning and so on.
@Thomas, isn’t constraining HISTORY.period a way to define POINT_EVENT.offset() for all the events in HISTORY.events?
Since period defines regular occurrences of POINT_EVENT, that will determine the offset of each event from the HISTORY.origin.
For non periodic POINT_EVENTs it doesn’t make much sense to constraint the offset to a fixed value, and the period is obviously not used, so the only case we might want to constraint “offset” is when we want to constraint “period” (?)
Also defining a constraint for POINT_EVENT.offset is currently creating a constraint for the return value of the function, that is DV_DURATION, so for all the events in HISTORY.events, offset is for instance PT5M, which is not correct if we have more than one POINT_EVENT in HISTORY.events.
the AE should not allow constraining that specific function (offset), need to analyze if we have other cases to state a more general rule like “no functions can be constrained”.
the IM is OK, no need to change offset to an attribute, should be a function of the history origin and the event time as it is right now.
LinkEHR behavior is correct in not allow defining constraints for offset.
There is another issue though, for period constraint interpretation for INTERVAL_EVENTs. I sent a question about that a couple of days ago to the tech list. The problem is what the period defines for INTERVAL_EVENTs, the distance between the start of two consecutive events, the distance between the end of one event and the start of the next one, etc.
@Thomas, another note for the SEC, this diagram doesn’t seem to have constant distance between periodic interval event starts’ (yes a measured it :), and might be useful to fix the diagram and to add a note about the period on this case.
only in a general way and only for Event series that happen to be periodic. For example, the Apgar uses only the specific offsets 1 min, 2 mins, 5 mins and 10 mins.
@Thomas, isn’t constraining HISTORY.period a way to define POINT_EVENT.offset() for all the events in HISTORY.events?
only in a general way and only for Event series that happen to be periodic. For example, the Apgar uses only the specific offsets 1 min, 2 mins, 5 mins and 10 mins.
From the AE it seems not possible to constraint the offset in that way. Only fixed suggestions can be set. All is defining only periodic point events. Not sure how defining not constant offsets would be expressed.
