INTERVAL_EVENT questions about the correctness of the specs
Description
PR is addressed in
Activity
Severin Kohler May 16, 2024 at 12:20 PM
For the INTERVAL_EVENT.time text i think we should also add:
”Time of this event. If the width is non-zero, it is the time point of the trailing edge of the event.”
refers to the end time of the interval, i would either add e.g. end time or word it like that.
Otherwise, its confusing.
Bjørn Næss December 26, 2018 at 8:21 AM
Some modifications on documentation would make an improvement.
At the same time. I have been thinking about the usage of INTERVAL_EVENT lately. Most recordings of OBSERVATIONs is some kind of interval. Clinicians or devices count/observes/measures in a period. The actual recorded data is a “best guess” number to represent the subject of care at that point in time. That’s why we normally use the POINT_IN_TIME event. When the amount of data grows we want to aggregate within intervals. Either on the capturing unit or in the user interfaces (query or in-memory). We might leave this operations to the application or we could look more into it, I.e.
- Do we need some aggregation functions in AQL ?
- Do we need some more patterns on the usage of current specification?
- Do we need some more lightweight RM structures to i.e record min, max, average, median of the same data?
Details
Details
Reporter
Components
Affects versions
Priority
Minor
1.
PP: On the INTERVAL_EVENT field descriptions I noted that those might not be 100% correct or clear. Before raising an issue on JIRA I wanted to know what you think.
INTERVAL_EVENT.width: Length of the interval during which the state was true.
since state can be modeled in two ways, inside the OBSERVATION and inside the EVENT, I think the description should not include the "during which the state was true" since not every instance will have a state in the EVENT.
TB: this is badly worded documentation... it actually means the value of the event, i.e. EVENT.data, and it rather casually uses the word 'state' in its informal English usage meaning the state/value/status/situation of something. But EVENT of course has a 'state' attribute, so, quite confusing. The proper wording would be 'the time interval during which the values recorded under 'data' are true and, if set, the values recorded under 'state' are true.
2.
PP: INTERVAL_EVENT.math_function: Mathematical function of the data of this event, e.g. “maximum”, “mean” etc. Coded using openEHR Terminology group “event math function”.
my interpretation of that is we use that function to summarize a list of numeric values into one value to be recorded. The problem I see is: this only works if the observation is numeric. I think we need to make the description clearer about what the function is, how should be used and also what is the domain / range of that function (maybe say that only applies to datatypes from the quantity package).
TB: agree
3.
PP: - another possible issue (not sure about this) is that the EVENT.data is a structure, so we can have many data points there, on that case, how is the math_function related to all the data points? What happens if one data point is the "max" value and other the "avg", we have just one math_function and 2 data points.
TB: the assumption is that the math function applies meaningfully to whatever data are there - so it's the application designer's responsibility to get this right. Normally, the math function is understood to apply to each data point, e.g. if it is 'mean' and there are 'systolic' and 'diastolic', then they are assumed to be both means (probably not terribly clinically useful but you get the idea).
All of this documentation could be improved - can you raise a PR for it - we can fix it in RM Release-1.0.4...
PP: is it possible to record a mean and a max value no the same EVENT.data? e.g. mean syst BP and max syst BP in an interval of time. Since there is only one math_function, for that we'll need a completely separated EVENT that occurs at the same time and has the same width. Is this the only way of representing this case?