As part of implementing PASI score, the requirement has come up to record % change since a previous recording. Has anyone else had this requirement, and if so how did you handle it? My initial thought was to use the INTERVAL_EVENT with a math function, but this has two issues (that I’ve identified, there may be more):
There’s no math function for % change, just for (absolute) change
Recording the % change for each data element would require a different data type than the DV_QUANTITY (qualified real) that’s used for the actual recordings
Events can support recording the “baseline” score alongside the score from “today”. Is that enough? Can the UI/business logic calculate the difference between 2 sequential/non-sequential events and display it on screen? Do we actually need to record this in the health record for posterity?
Is the % change part of the formal Score itself? I can’t access the original paper - Fredriksson T, Pettersson U. Severe psoriasis–oral therapy with a new retinoid . Dermatologica. 1978;157(4):238-44. I suspect not.
Or is this new requirement more of an additional meta-observation/consideration?
If so, it seems similar to the Growth velocity concept to me, which is modelled as a separate archetype because while it appears to be directly related it is, in a similar way, more like a meta-observation that needs to be recorded and graphed in it’s own right. It is related to the original, yet tracking the difference between two separate growth measurements/data instances. I note there are no common data points with the measurements for the original concept which also tips me towards not adding this notion of change in % to the PASI Score archetype.
This makes me very reluctantly wonder about the creation of a new archetype - data point to record the % change plus some way to identify the 2 events (- we may not always be able to assume sequential events related to the date of recording). Ideally, we don’t want this pattern to proliferate for every score/scale. Even wilder idea…can we generalise recording change between any score? Ugh…
Personally, I’d prefer if Option 1 was the conclusion
Can you persuade the clinicians asking for this, that the ‘%change’ a visual cue/convenience on screen as part of a consult rather than a data point that needs to be recorded for reasons.
Your #1 led us to the realisation that we can probably tag the baselines vs the regular recordings using the event names, and this means we can probably calculate the % change on the fly instead of having to persist it. Thanks!
If the data were going to be recorded (in the ideal) as % change from baseline (be careful - not the same as % change since previous measurement!), then I would say the simplest thing is to add a new code to the appropriate vocabulary, which is here.
Then no changes are needed in archetypes at all; it just means that you should constrain the math function field the that new code (when it is issued).
