In some cases, it’s useful to be able to record that an OBSERVATION is a recording for the lifetime of a patient. Examples of this are lifetime maximum blood pressure, or a questionnaire where the patient reports whether they’ve ever used prednisone (yes/no/unknown). We can technically express this using an INTERVAL_EVENT, but it’s a bit cumbersome to calculate the exact lifetime of the patient expressed as a DV_DURATION, and then applying that to the width of the event. I was wondering whether it would be possible to add a third subclass of EVENT to handle this. Thoughts?
2 Likes
Well the History/Event structure in the openEHR Observation is just a technical representation of time-series data, including state values that remain true for some time Interval. It doesn’t know anything about ‘patients’ or patient lifetimes, or other real-world associations of the patient with the data.
The reason there are two sub-classes of EVENT are that ‘point’ and ‘interval’ are the only two mathematical possibilities, so I can’t see any more subtypes making sense.
I would have possible expected the detail about ‘lifetime’ to be recorded as a data item (archetyped) in /protocol, or maybe outside the Observation altogether.
I would just label the event name in the template with Lifetime, perhaps coded. There are all sorts of 'contextual events like this ‘pre-op’, ‘post-op’.
Understand but don’t agree that it is contextual in the same way as pre-op and post-op at all. I’d consider ‘lifetime’ as ubiquitous and universal, hence the suggestion to add to the RM.
Max or min or change over a lifetime is not uncommon. Lifetime is a special version of interval - with a fixed start date at DOB and an end date of today, rather than any ordinary interval.
I get the requirement, but the Events structure is just a technical data structure, and it knows about absolute and relative times w.r.t. an origin, but it doesn’t represent anything about significance to the outside world.
Now, I guess you might want to tag a specific Event in some way that made it easier / quicker to find in querying. It might be worth thinking about that if there is a general need to be able to tag specific Events (I assume this lifetime maximum thing is pretty rare). Do we have any other similar requirements?
(Note: we are adding a general ‘tagging’ capability to the RM already)
Would it be a possibility to add/modify the INTERVAL_EVENT to be able to record start and stop datetimes instead of a stop datetime and a width duration?
If we change existing semantics in the RM, it will break every openEHR installation on the planet, and all the existing openEHR data 
That’s the thing about the Reference Model - it’s a best attempt at a very stable model to represent all the cases we knew/know about. But it doesn’t cover everything.
We can add things to it fairly easily, as long as they don’t invalidate what is there. But this question of which 2 of the 3 possible things you can know about a non-instantaneous event (i.e. start, end, width) is an old one, we knew about it 20y ago. The model that is there today is the result of long discussions with the clinical professionals around at the time. We decided in the end to make it that EVENT.time was an absolute time corresponding to the end of the event, so that databases and software did not have to do any work to obtain that real-world time. This is less convenient for some purposes, where having the offset would be more useful.
We could in theory add a data item to INTERVAL_EVENT ‘start_time’ which is the value EVENT.time - INTERVAL_EVENT.width, i.e. what the function INTERVAL_EVENT.interval_start_time() already computes. This would cause some chellanges in software and databases, since that field doesn’t exist today, so it would have to be an optional field (it would still create work for implementers).
If I understand correctly, the reason you want that field is to be able to constrain it in some way in the archetype designer? If so, this is just another instance of a general problem where we want to be able to constrain a computed value, not just stored values. The tools sort of support this already with the ‘is-computed’ marker in the BMM model files that feed the Archetype Designer. We could add the function ‘interval_start_time’ into the BMM today, and mark it as computed, and you would then be able to write constraints on it.
There is some debate about whether we should keep or remove that feature - we need to review it anyway. So my main question would be: would it help to be able to see ‘interval_start_time’ in the Archetype Designer?