From a modelling perspective there are many data points that only make logical sense to be modelled as an Interval event, for example a travel record which should theoretically have a start and end date (date of departure and date of return. Sometimes the end date has not been completed if they are still travelling. Sometimes we need to record where they travelled to, but don’t have dates to set the interval.
I’m sure not having all relevant dates for OBS data IRL is a relatively common occurrence.
How do implementers manage this in practice? What are your tips, thinking, workarounds, for this scenario?
Sorry only just saw this! I think the kind of ‘event’ you are talking about here is a higher level phenomenon than the kinds of things Observation containing History of Events is designed to capture. An Interval Event in the Obs model is for things like some vital sign being at a value (say SpO2 = 95%) for some period (say 10mins).
To represent a ‘travel record’ with some data points like start data, end date, and others, it depends on the modelling intent, which I don’t understand yet. Quite likely an Admin_entry, unless it has direct clinical significance. Depends also on who is doing the travelling.
I think I had a similar conversation about the ‘travel history’ OPT for HiGHmed.
They modeled travel dates as INTERVAL_EVENT. The ‘event’ is really for events that happen at a certain clinical level, since EVENT is inside OBSERVATION which is a CARE_ENTRY.
IMO travel history should be ADMIN_ENTRY to start with, then each travel period could be just a CLUSTER with ELEMENTs representing each date and any extra context data required.
I agree with Thomas that OBSERVATIONs and EVENTs should be at a certain level of some clinical phenomenon, which, IMO, doesn’t apply for travel history.
This is what I wrote to a colleague about this topic:
The INTERVAL_EVENT is for information like:
duration of a saline solution administration
duration of a treatment (e.g. physical therapy)
duration of a vital signs monitoring (that is where the math function comes into place because you can have information about the AVG, MAX, MIN, etc. of, for instance, the heart rate in a period of time)
Not saying this is not “clinically relevant”, I’m saying this is not “clinical information per se”. So ADMIN_ENTRY might not be a bad fit in this specific case.