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
Oh, I see it now. The only thing I can thing about is that Percent (%) is a valid UCUM unit, 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
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.
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 - 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.
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:
mixing ‘close, close but different’ semantics in one archetype.
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 ’ - Answer is Yes/No.
For example:
If the delta is recorded, as it may well be on occasion or to provide the evidence for a Yes/No questionnaire answer, it is still only a delta that is only meaningful at the time of recording (ie as a point in time delta, but relating to original measurements at two discrete points in time that may be (correctly or incorrectly) expressed/interpreted as an interval of ‘last 30 days’ or ‘last 6 months’. It assumes that you have today’s weight and the weight exactly 30 days or 6 months ago. And we usually only have approximations or guesses of the previous weight.
I would not go that far - it’s still body weight we’re talking about. You could archetype two alternative History structures, one consisting of absolute values (usually just one I assume), and the other consisting of a delta value. If multiple observations of either flavour appear in the patient record over time it would be easy enough for application software to put them together in appropriate ways.
I agree of course that at the user / application / clinical level you need to know what you are doing with diffs.
I would have assumed the most common scenario wasn’t the cancer one you mention though - wouldn’t it just be weight management over time - either loss or gain, depending on patient situation?
Modelling for clinical and implementation clarity is really important. If we model something very elegantly but we can’t easily explain it for review or implementation then we have a problem. If we have both the weight as ‘actual’ and weight as ‘change’ that is theoretically ok. But when we can only reasonably record weight as ‘change’ over an interval then we start to get into what I’ll call ‘semantic acrobatics’ that potentially create confusion. In that situation it seems valid to me that they could/should be recorded in separate archetypes. Deciding on the scope of an archetype is not just about identifying the clinical concept; it is also critical to demonstrate clear design intent for the semantics. It may not be pure, it may not be elegant but it is absolutely clear how the designer intended the model for use.
Remember the weight difference/delta is not just related to the actual weight in the same instance, but is today’s weight subtracted from a previously recorded weight (?linked, both recorded as point in time events). And the %difference needs to be recorded using an interval event and calculated by the diff (numerator) divided by the first recorded weight within the time frame of the selected interval event *100. It is not clean when we have data elements designed for specifically different events within the same data element. This already happens with ACTIONS and pathway steps and it is really difficult to communicate design intent for each data element in the correct modelling context. Most clinicians are totally lost when you try to describe it, and I suspect that many implementers are as well TBH. ACTIONs are difficult to model and implement (and very elegant and well designed) however I wouldn’t want to create the same problem with OBS if I can avoid it.
I’m not going to die on a hill about this one
We calculate it but given it potentially changes every day it is not usually recorded alongside the weight on a daily basis. Visualisation by graph is often just as useful.
The other use cases in aged care/cancer screening and similar ones are more critical because they trigger care pathways or decision support so recording it is potentially useful as evidence underpinning the clinical decision.
Can’t really argue with that. Slight philosophical note: there is a question (maybe) to do with education of clinical modellers on these kinds of scenarios. While ‘IT’ representation of various kinds of data is one thing, there has to be an understanding on the clinical side of such data, even when it is quite technical - image series, differentially encoded weight over time, complex prescriptions. So maybe we need to think about how such things are explained clinically, and do better in some cases on how we get from clinical understanding to technical data structures / archetypes.
Yes… this is a good example of what I am saying above: we need to articulate all this in a technical/clinical level (the clinical is technical in this case) and then work backwards to see how well the RM / current archetype capabilities support it.
At this point I’m really starting to think of a library or compendium of ‘complex clinical data scenarios’ or similar where such things are routinely described, diagrammed etc. I think (certain) tech and clinical (+informatics) people should work on that - what do you think?
This is probably another topic, but the elegant, pure and academic should not override clarity for all participants. One of the main priorities/goals for clinical modelling should be representing the data unambiguously. If the technical representation causes obfuscation or confusion, especially if it reduces the opportunity for clinical verification or distributed template building at grassroots clinical level, then we need to carefully rethink our priorities. Broad clinician engagement (including non-technical) is one of the key differentiators and greatest successes of openEHR - it was your original vision.
Smart, intelligent technical design and tooling is how we achieve that goal and to date we usually do it pretty well. I see if we start to water down that original vision and follow other standards where grassroots clinicians are less able to engage without being trained up. The tail should never wag the dog.
Handling measurements is important, very useful to automate and deserves a lot of attention. In addition to percent change there is also need to sometimes describe things as percent of reference value / expected value (it’s a useful part of many algorithms…) And then we also need things like Z-score (number of standard deviations that measurement differs from expected) in relation to certain reference materials…
Certainly agree with all that. I’m just thinking about specific requirements like this (and see @Anders_Thurin comment) that are innately complex and technical, before thinking about any data representation at all. Some requirements are like this, and we won’t get the model part right if we don’t understand in detail what the clinical / medical / scientific model is … hope that makes sense.
Just as an interesting addendum, we have come across a requirement for Intradialytic weight gain as a %, which probably does merit it’s own archetype - partly because of the Intradialytic context but also because I can see this having value, without actually knowing the source weight’s i.e. it is the differential that is important here. To some extent the per and post wights are not relevant
