FHIR Chat · Capturing time spent in a particular state/condition · implementers

Stream: implementers

Topic: Capturing time spent in a particular state/condition

Morten Ernebjerg (Nov 09 2021 at 07:21):

We have a use case where we want to capture how time much a person spent in a poor body posture within some reference time frame (say, a day). Understandably, there does not seem to be e.g. LOINC codes capturing exactly this concept ("Time spent in poor body posture"). However, there are of course codes for body posture itself, e.g. SNOMED 249858009 - "Poor posture (finding)". My general question is whether there is some way on FHIR to combine such codes with time-intervals to capture that fact that a person was in the state described by the code for a specific period/length of time (similar to saying e.g. that a patient was unconscious for a specific period of time).

Technically, one could create a Condition, with the appropriate code and the time interval captured in onsetDataTime and abatementDateTime, but that definitely seems wrong since we are not really talking about a "condition (...) that has risen to a level of concern". Following option 3 in this guidance on the use of codes in Observation, we can capture the fact that a patient was found to have poor posture in an Observation with the SNOMED finding code, no value[x] and dataAbsentReason set to "clinical-finding". That seems more on the right tracks, but still leaves me with some questions:

1. Would following this guidance and additionally setting effectivePeriod to the period when the poor posture was observed convey the correct meaning?
2. Following on (1): Is there some way of aggregating the time spent in the relevant state over a fixed interval , e.g. saying "code applied for 3 hours on this particular day", rather than saying "code applied for this specific period of time"?
3. The value "clinical-finding" for dataAbsentReason is not in the extensibly bound value set. Is this value defined in another standard code system?

I suspect cases like these are becoming more common with the spread of wearables that generate many different kinds of data for various time intervals, so I would be very interested in any general guidelines that exist on this.

Richard Townley-O'Neill (Nov 10 2021 at 05:02):

On question 2 - could you use an Observation.valueQuantity of 3 hrs with an effectivePeriod of the day of the observation?

Morten Ernebjerg (Nov 10 2021 at 09:50):

@Richard Townley-O'Neill Yes, I think that would make sense. My only worry is whether it will be consistently correctly interpreted by all consumers since the code itself is just a finding ("bad posture") and does not provide any clue as to what the value means. Looking at option 2 in the section I linked above, (which I realized is more appropriate than 3), the recommendation is to only combine a SNOMED finding code with valueBoolean or valueCodeableConcept (basically to say present/not present). I suppose we could capture this pattern in our IG and document what it means (i.e. SNOMED finding code in code + reference period in effectivePeriod + time for which finding code applies within this period in valueQuantity). I wonder if others have tried something like this as well.

Lloyd McKenzie (Nov 15 2021 at 05:04):

@Morten Ernebjerg I would recommend an Observation with a custom code. When using resources, always think about where you want the data to show up and how the system behaves as a patient's situation evolves. Conditions generally show up in the patient's problem list and the Condition resource is updated over time to reflect their current state. (You'd have to look at history to understand past state). In your case, you presumably want to be able to capture multiple values over time - so you can see if interventions are helping. You also don't (necessarily) want to see this as a 'problem'. So my leaning is to define your own code for the Observation. (Though you can certainly propose it as a concept to be added to a standard terminology such as LOINC.)

Morten Ernebjerg (Nov 15 2021 at 08:44):

Thanks for the input, @Lloyd McKenzie - I will certainly go with Observation. A custom code would definitely allow to completely fix the semantics. However, I am a little worried that we will have a profusion of custom codes of type "Time spent in state X" where X is some state reported by a wearable device and for which we already have perfectly good standard codes (e.g. asleep, physically active, bad posture, having low blood-sugar etc.). That is why it seemed worthwhile to consider establishing a pattern to represent these cases as Observations using the pre-existing "State codes" , thus leveraging the existing terminology work rather than manually adding each combination to LOINC or using custom codes. Is there something that would speak against declaring such a pattern convention (like the one I mentioned above) in an IG, instead of using custom codes?

Lloyd McKenzie (Nov 15 2021 at 18:51):

There are possible mechanisms that leverage 'component' to qualify a higher-level observation code. It would be best to raise this on #terminology to get vocabulary input. @Daniel Vreeman - any thoughts?

Morten Ernebjerg (Nov 16 2021 at 09:23):

OK thanks, will do.

Morten Ernebjerg (Nov 16 2021 at 09:43):

Opened this thread in #terminology

Last updated: Apr 12 2022 at 19:14 UTC