How to record no change in a parameter (height or weight for example)?

Good afternoon, dear colleagues. In data structures information model Data Structures Information Model (6.1.5 Change Data) i see examples how i can record increase\decrease or change of parameter, but how I can record no change in parameter?
In my opinion i can it by math_function actual, or by increase\decrease at 0 . But maybe there are other ways .

To my understanding, “actual” is the value for the interval event, because the “change” codes are actually for recording changes in data. So “no change” would mean the “change” codes shouldn’t be used.

1 Like

Thanks for your answer.

Hi Pablo,

I read the specs slightly differently - see #6.1.5 in the Data Structures Information Model.

While it is possible to record both ‘increase’ and ‘decrease’ as positive values, it is also possible to record ‘change’ as an event math function - "the value recorded is the difference between the value now and the value some time previously. It can be positive or negative."

I would assume that this could also be recorded as zero (0kg), for example if it is clinically relevant to record that there has been no change in weight during the specified interval. This could be a desired or concerning finding, depending on the context. For example it may be a first indication of something going wrong during a pregnancy.

The selection of ‘change’ is possible in the tool UI shown in German’s image, above.

I’d interpret ‘actual’ as the actual value relevant during the entire interval, which in this example could be 70kg at both the beginning and the end.

3 Likes

I agree with Heather that zero change is a possible ‘change’ here.

Looking at the initial screenshot, I would only caution against explicitly allowing both of

  • ‘change’ (or ‘decrease’ and ‘increase’) AND
  • ‘actual’

in one explicitly defined/constrained interval event.

E.g., if the interval event is named e.g. ‘weight change’ this is a change and should have the appropriate math function pre-constrained, i.e. alternatively documenting the ‘actual’ weight as part of this particular event should not be possible in my view.

3 Likes

In this bit of the original model, which was added due to (I think) Sam, my memory is that the ‘change’ function was intended to indicate changes over time in e.g. estimated foetal weight, and maybe things like fundal height. Could also be typical metrics for post-partum growth as well. I know Heather would have been thinking about the same kinds of things, and might have been involved in these discussions (would have been a few years later, but I just don’t remember, sorry).

The math_function attribute is only defined on Interval events. The codes are a bit confusing and should be fixed. Right now they are:

		<concept id="145" rubric="minimum"/>
		<concept id="144" rubric="maximum"/>
		<concept id="267" rubric="mode"/>
		<concept id="268" rubric="median"/>
		<concept id="146" rubric="mean"/>
		<concept id="147" rubric="change"/>
		<concept id="148" rubric="total"/>
		<concept id="149" rubric="variation"/>
		<concept id="521" rubric="decrease"/>
		<concept id="522" rubric="increase"/>
		<concept id="640" rubric="actual"/>

‘Actual’ means the actual (= current, at the timestamp of the measurement), and only makes sense for point events. So it shouldn’t be in this list. The only meaningful ‘actual’ values over an interval that are not differences of some kind are things like min, max, average, mode, median and (maybe) ‘total’ (is that ever used?) The only other possible values I can think of are something like ‘last’ (i.e. point value at the end of the interval) but I’ve ever heard anyone ask for it.

I think this error has been there because originally math_function might have been defined on EVENT rather than just INTERVAL_EVENT, but was then moved, and the value set not modified.

I remember debating (maybe 20y ago) about whether having increase and decrease was a good idea, because of the obvious possible confusion that a positive number associated with decrease might be processed by some software as an actual positive change. Personally I would avoid using them and just use change.

So possible changes to this terminology value-set:

  • obsolete actual
  • obsolete increase and decrease

Various people would need to look at whether any of these have ever been used in real systems, archetypes etc. So it might just be advice for the future. If they have been used, it needs to be worked out in those systems what the meaning really is. E.g. if actual were used, what does it mean for the interval values where it was used?’

EDIT: forgot to add, w.r.t. the original question, I’d recommend (as others above) that change with a 0 value is correct.

1 Like

Though point events don’t have a math_function, that is why I interpreted actual as a constant value during the interval event.

I don’t think your interpretation is wrong, it’s actually the border case for the concept of change which is no change, though I’m wondering if the specified change is a strict concept, I mean, if its semantics are for strict changes, meaning that change zero isn’t a valid value. I think the current spec leaves that to interpretation. My interpretation was that: change means strict change, and that actual in an interval event means no change.

For me the total value never made much sense, or at least I couldn’t find a case for it. I don’t know, maybe for medication administration for recording the total amount of medication administered in a period of time?

2 Likes

Thank you @thomas.beale for the detailed explanation, very helpful. (Although I agree with @pablo that ‘actual’ is part of this somehow - maybe the intention was to just say that this is the actual - at least roughly unchanged - e.g. height of a patient over that period).

It is used in the Fluid balance and Foetal movement archetypes for example:

Other archetypes where a total over a time period may make some sense (the way I understand it) are e.g.

I could find one example of an “actual” interval event:

3 Likes

Well, if it has been used, hopefully this is the meaning (= what Pablo said), because I can’t think of any other meaning that could make sense :wink:

Now that I think of it I hear my wife (midwife) yelling at me that it is also for cumulative blood loss during childbirth, since it’s the total that decides if/when the mother will need urgent intervention. So that takes care of total.

This doesn’t guarantee it has been used / not used in systems of course…

2 Likes

@pablo @heather.leslie @sebastian.garde @thomas.beale Thanks for discussion, I am glad to have brought this problem to your attention.

Could this be spelt out in the specification explicitly? Because this is the point that prompted my question on the forum. In this " 147|change| : this means that the value recorded is the difference between the value now and the value some time previously. It can be positive or negative" change to “147|change| : this means that the value recorded is the difference between the value now and the value some time previously. It can be positive, negative or zero”

I use “actual” and recording actual value of weight to record no change. If it possible to record zero with increase/decrease/change math function, it resolved my problem.

And is it possible to put example with 0 (no change) in this table?

1 Like

this request should go to the @SEC

1 Like