# Change over time in an OBSERVATION measurement, represented as % **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2022-02-04 08:24 UTC **Views:** 987 **Replies:** 15 **URL:** https://discourse.openehr.org/t/change-over-time-in-an-observation-measurement-represented-as/2329 --- ## Post #1 by @siljelb Hi everyone! Do we have a way to represent a change over time as a proportion rather than as an absolute measurement? For example: Weight change from one measurement to the next, we can express that in a number of kg using the OBSERVATION.body_weight and an interval event with the math function "change". However, in some use cases the change needs to be represented as % of weight loss or gain. ``` Measurement 1: 70 kg Measurement 2: 80 kg Change in kg: 10 kg Change in percent: 14 % ``` I'm pretty sure we don't have an elegant way to model this. An inelegant way would be to add a "Proportional change" or similar DV_PROPORTION element to the archetype, which would only be relevant when used with an interval event and a "change", "decrease" or "increase" math function. Is there some way to do this elegantly using some part of the specs we modellers don't know about? @thomas.beale @yampeku --- ## Post #2 by @yampeku Where would the '10 Kg' part be stored in the data? Is that another element in the weight archetype? Is in the interval itself? --- ## Post #3 by @siljelb The '10 kg' would be stored in the main "Weight" DV_QUANTITY element, modified to mean "change" and not "actual" by the math function of the event. --- ## Post #4 by @yampeku Oh, I see it now. The only thing I can thing about is that Percent (%) is a valid [UCUM unit](http://download.hl7.de/documents/ucum/ucumdata.html), and as such could be used in the quantity just fine by itself. Adding that as a valid unit in the archetype (I'm assuming an additional "0.0..100.0 %" constraint) would work. If you want to put both at the same time then probably a new element would be needed edit: maybe the 0.0..100.0 range must be clinically reviewed, I'm not sure if it would work for babies or infants --- ## Post #5 by @thomas.beale At the moment you can: * define the two change fields, and use application level calculation to populate the derived field value, i.e. the %. * define just the raw delta field, and compute the % change purely in the application layer - since it is derived by a simple calculation, this is always doable. There are things we might do in the future at RM level or elsewhere to create a standard data structure based on the History of Events structure that computes useful things for application developers. Percent change is just one; over a time series, 1st and 2nd derivative could also be calculated, and indeed, integrals could also be calculated. I would say that % delta is just derived possibility. --- ## Post #6 by @siljelb I'm not sure I understand, but here goes [quote="thomas.beale, post:5, topic:2329"] define the two change fields, and use application level calculation to populate the derived field value, i.e. the %. [/quote] So basically two instances of the relevant OBSERVATION (say, Body weight) each with a POINT_EVENT, and always calculate the % change on the fly? [quote="thomas.beale, post:5, topic:2329"] define just the raw delta field, and compute the % change purely in the application layer - since it is derived by a simple calculation, this is always doable. [/quote] So one OBSERVATION instance with an INTERVAL_EVENT with the "change" math_function, and always calculate the % on the fly? But what if I want to persist the %? --- ## Post #7 by @thomas.beale [quote="siljelb, post:6, topic:2329"] So basically two instances of the relevant OBSERVATION (say, Body weight) each with a POINT_EVENT, and always calculate the % change on the fly? [/quote] You can actually mix Event types within a single History structure. So you can have differential and absolute value events within the same series. I doubt if anyone's platform software would expect this, and there is no obvious way to archetype it in current tools, but it would be legal. You can see some [diagrams of mixed point and interval events here](https://specifications.openehr.org/releases/RM/latest/data_structures.html#_timing) - same idea in principle. It might be a reasonable idea to allow mixed deltas and absolute value Events in a History - I have to admit I hadn't thought of it until your question, so I would suggest we make this a discussion point for specifications group. --- ## Post #8 by @heather.leslie I'm not so sure that this example is a good clinical requirement on which to propose possible RM changes. * Recording an actual body weight at a point in time is one clinical concept. * Recording a change in body weight over an interval, as an actual in 'kg' or as '%' is a semantically separate concept. And if we record as % we need to ensure a clear linkage back to the original weight that the weight loss is relative to? While we can technically apply RM/tooling acrobatics to record the delta using the 'Weight' measurement using the 'Change' attribute over an unspecified interval of time in a single archetype, it doesn't mean that we should do so. I've always struggled with Sam's initial modelling of this in the original body weight archetype, going way back to 2004. It's a neat little package in theory but I'm concerned about: 1. mixing 'close, close but different' semantics in one archetype. 2. how we implementers communicate to implementers that Actual weight is associated with a Point in time event and 'Change' is the diff between two actual weights at points in time with the change period defined as an interval (or is it a point in time recording linking to the two existing OBSERVATIONs. *In fact I'm of the opinion that actual weight and the change in weight should be recorded as **two discrete clinical concepts in two separate archetypes.*** The commonest and cleanest clinical scenario is to record separate weights accumulating over time, maybe even graphed. No brainer, modelled well in the existing OBSERVATION. Recording the diff is more complex as we don't often record it as an independent measurement. Why? * Because the diff is relative and only relevant when knowing both the current and previous actual measurements. We need a clear reason to calculate it, much less record it, because it may be quite a different calculation yesterday or tomorrow. * In my experience, most often the calculation is triggered within the context of screening for cancer or debility/frailty in aged care or similar, most often needing to answer a questionnaire's question like 'has the patient lost >5k or 10% of their body weight in the