Stream: implementers
Topic: Diabetes 7-point profile self-monitoring and terminology
Arianne van de Wetering (Jan 31 2017 at 10:06):
We are setting up a pilot situation in The Netherlands where we are exchanging blood glucose data from a patient using his personal health record to his caregiver. This is done using FHIR Observation. Patient and caregiver use the 7-point profile (https://www.idf.org/webdata/docs/SMBG_EN2.pdf): so before breakfast, after breakfast, before lunch, after lunch, before dinner, after dinner and at bedtime.
We are struggling to find appropriate terminology. Started out looking at LOINC, but LOINC does not give the 'before meal' nor the 'bedtime'. Also LOINC does not distinguish between breakfast, lunch and dinner. This may not be relevant for laboratories, but it is for patient - physician communication and properly assigning blood glucose levels at the right point in the 7-point scale.
Is there any experience with this use case and which terminology was considered / chosen?
Lloyd McKenzie (Jan 31 2017 at 13:48):
If this is for the order, it would be handled by Timing.repeat.when. For the Observation itself, I'm not sure.
Arianne van de Wetering (Jan 31 2017 at 15:04):
Indeed, I mean the observation about the blood glucose itself as reported back by the Patient to the Caregiver
Eric Haas (Jan 31 2017 at 17:27):
WE are considering adding the Timing datatype to the Observation.effective{x] since its part of the Event workflow pattern. Also this same issue was broached in an earlierMhealth meeting I had.
so would it work if :
Observation
...
code = BG
...
valueQuantity = 100 mg/dL
...
effectiveTiming = Dinner
....
Eric Haas (Jan 31 2017 at 17:27):
Also an issue for nutrition observations too.
Arianne van de Wetering (Jan 31 2017 at 20:01):
the timing.when offers a valueset (https://www.hl7.org/fhir/valueset-event-timing.html) which seems to be created for this purpose of the 7 point scale. Adding that to the observation would indeed solve this issue.
Arianne van de Wetering (Feb 01 2017 at 09:26):
Actually, one more question: is it possible to also express '2 hours after breakfast/lunch/diner'? I see STU3 having 'offset' for this? So if the event is after meal, does an offset of 2 hours then mean '2 hours after meal'?
Lloyd McKenzie (Feb 01 2017 at 13:35):
The offset can be positive or negative. So with a negative number, you could technically say 2 hours before "after meal", though that would be weird. Two hours before bedtime would be reasonable though.
Arianne van de Wetering (Feb 01 2017 at 13:50):
Thanks for the explanation Lloyd.
The definition of offset on "http://build.fhir.org/datatypes.html#Timing" however, is unsignedInt?
I agree with your reasoning however and find it a lot more clear to use negative numbers for earlier and positive numbers for later.
Following your reasoning the example 'BID, 30 mins before meal, for next 10 days' on "http://build.fhir.org/datatypes.html#Timing" would have to be corrected along with the offset Type? It has an offset of '30', but if it is before it would have to be '-30'?
Should we raise a ticket?
Lloyd McKenzie (Feb 01 2017 at 15:09):
Yes, I think a ticket would be reasonable.
Robert McClure (Feb 01 2017 at 16:28):
@Lloyd McKenzie and @Arianne van de Wetering Your friendly terminologist here and I'm worried that an approach that ignores part of the meaning of the concepts in the FHIR TimingEvent code system (https://www.hl7.org/fhir/v3/TimingEvent/index.html) is simply bad form. You either need to craft a process that restricts the valueset of the noted codes to only those that describe "after event" timing, then only allow positive offests, and the same for the "before event" codes with a negative offset. Or you can allow either positive or negative offsets and restrict the timing concepts to those that only describe the event without a timing element added. You can't do what Lloyd suggested where you get to ignore the timing element of the concept while using the event part. That would be like using the concept "Acute renal failure" for any type of renal failure and adding the chonicity into some other attribute. You get the picture - No bueno! While I like the code system (latin - I'm a doc and all) if you chose to represent the timing part via the offset +/- and the event alone, I'd suggest a different set of concepts as these latin phrases are really used as timing+event ideas - no one alive would refer to a meal as "cibus".
Lloyd McKenzie (Feb 01 2017 at 17:58):
The event codes identify a specific point in time - the time you start a meal, the time you're done your meal, the time you wake up, the time you go to sleep, etc. It's quite reasonable to indicate that something should occur an hour before you go to sleep, but it's also reasonable that some test or measurement might need to occur an hour *after* you go to sleep. While it might be slightly weird to say "do something 10 minutes before the end of lunch" and extremely weird to say "do something 2 hours before the end of lunch", the meaning of it is clear - and I don't think we're abusing the terminology in any way by doing so. The offset needs to be able to be negative to support reasonable requirements. The fact it enables "weird" requirements can be addressed through usage notes, but shouldn't prevent us from meeting the reasonable use-cases.
Arianne van de Wetering (Feb 01 2017 at 18:42):
I find an offset of +30, meaning 30 minutes later when combined with after lunch, but meaning 30 minutes earlier when combined with before lunch really unclear.
What would an offset of 2 hours mean when combined with 'lunch'. Before or after? That would be unclear, right? Is an offset not allowed when the event does not include the word 'before' or 'after'?
So allowing the + and - for 'after' and 'before' is much better, and I guess Robert is not really disputing that.
I do tend to agree that I cannot think of a real use case for "10 minutes before the end of lunch", but addressing that through usage notes as per Lloyds suggestion is good enough.
Arianne van de Wetering (Feb 01 2017 at 18:51):
@Eric Haas adding the timing to the observation: should I raise a ticket or are you already in some kind of process to get this realised?
Eric Haas (Feb 01 2017 at 18:53):
I already (pre-) applied it and will get OO approval on Thursday..
Eric Haas (Feb 01 2017 at 19:16):
Arianne van de Wetering: I see the effective is 0..1, does that mean I cannot combine the 'after lunch' with a proper date/time (after lunch, which was at 16:00 hours)
Eric Haas: the timing datatype can have a datetime and when. At least I don't see an invarient prohibiting it
Eric Haas: A change to the cardinality of Observation.effective[x] would require a new tracker and a very compelling argument and use cases.
Arianne van de Wetering: the timing can indeed also have a datetime the event took place.
But if you do an observation with just a datetime (another blood glucose measurement, just because you feel dizzy or whatever) then the datetime ends in a different field than when doing the regular after lunch thing.
In general I am not fan of letting the same thing land at two different locations... When reading the resource and plotting every observation over the day, you would have to look for datetime at two different places...
don't know if that's compelling enough though
Eric Haas (Feb 01 2017 at 19:18):
Not sure how changing the cardinality would alleviate having to look in different fields.
Arianne van de Wetering (Feb 01 2017 at 19:23):
You could profile that the datetime the observation took place always ends up in the same field (effective as dateTime).
Eric Haas (Feb 01 2017 at 19:33):
I think this comes down to asking for a way to provide for is a translation of what 'lunchtime' means and I think that is outside the FHIR scope. Each implementation could map "at lunch" to a datetime range.
Eric Haas (Feb 01 2017 at 19:34):
I mean outside the scope of Observation and Observation.effective. There a ways to map concepts in fhir.
Arianne van de Wetering (Feb 01 2017 at 19:48):
No, I mean quite the opposite. The exact date/time the observation was done is a different thing than the event.
so: a measurement was before my lunch today. I did the observation at 11:45.
yesterday the before lunch observation for me was at 13:30 hours, because I had lunch later due to a meeting or whatever other cause
next to the event (before lunch, after lunch) the exact timing the observation was done also has value
Eric Haas (Feb 01 2017 at 22:47):
I totally misunderstood your use case. if a patient reports a event as occuring at "dinner" that would be the effective time. If you want to have an actual time eg 5:55 PM and then associate this with the "dinner" observation, I would express it in the code as "dinner BG" or as a component or create an extension.
Arianne van de Wetering (Feb 02 2017 at 07:41):
Raised GF#12759 - timing offset should allow for negative and positive numbers
Wilfred de Jonge (Feb 02 2017 at 11:37):
Hi all, I'm the one that made Arianne ask this question about the 7 point scale :-). The TimingEvent can do the job, combines with the effectivedatetime in an Observation. See the screenshots from the iGluco app. This information is sent to the GP.
Screenshot_20170202-121922.png Screenshot_20170202-121910.png Screenshot_20170202-121934.png
Marten Smits (Feb 02 2017 at 12:54):
@Arianne van de Wetering @Lloyd McKenzie @Eric Haas As I understand, it should look like this:
<Observation xmlns="http://hl7.org/fhir">
<status value="final"/>
<code>
<coding>
<system value="http://loinc.org"/>
<code value="14760-3"/>
<display value="Glucose [moles/volume] in capillary blood by Glucometer -- 2 hours post meal"></display>
</coding>
</code>
<subject>
<reference value="Patient/1"/>
<display value="M. Smits"/>
</subject>
<effectiveTiming>
<event value="2017-02-02T14:30:00+01:00"/>
<repeat>
<when value="PCD"/>
<offset value="120"/>
</repeat>
</effectiveTiming>
<performer>
<reference value="Patient/1"/>
<display value="M. Smits"/>
</performer>
<valueQuantity>
<value value="6.3"/>
<unit value="mmol/l"/>
<system value="http://unitsofmeasure.org"/>
<code value="mmol/L"/>
</valueQuantity>
</Observation>
Marten Smits (Feb 02 2017 at 12:56):
Personally I think "repeat" is a little bit misleading, should I put a count "1" in there?
Eric Haas (Feb 02 2017 at 22:16):
I'll stick to my guns and if you really want both the when and the timestamp then your question in the question answer pair using the FHIR Observation resource should be - my "lunchtime ( dinnertime, etc) BG" the answer would be '80 mg/dL' with a timestamp. Alternatively you could ask two component questions 1) my 'BG' and 2) 'when' with component answer 1) would be '80mg/dL' and answer 2) would be "lunch" with a single timestamp.
Grahame Grieve (Feb 06 2017 at 06:40):
so I think that this neesd solving, and we already knew that from meeting with openMHealth
Grahame Grieve (Feb 06 2017 at 06:41):
but I really doubt that sticking Timing on Observation is at all useful without a big redefinition of the TIming datatype, since all it's definitions are future, and also of all the event codes.
Grahame Grieve (Feb 06 2017 at 06:41):
and we don't want to be doing such a redefinition right now
Marten Smits (Feb 06 2017 at 08:30):
What would be an alternative we could use right now? We have an implementer that wants to exchange this information. We told him he could use a Timing extension right now, until we figure out how to solve this in the future.
Grahame Grieve (Feb 06 2017 at 09:02):
well, what parts of timing are relevant? just the event code?
Marten Smits (Feb 06 2017 at 09:04):
Event code and an Offset (So, 2 hours before lunch). We could create a complex extension for that as well...
Grahame Grieve (Feb 06 2017 at 09:04):
@Eric Haas is that all?
Eric Haas (Feb 06 2017 at 09:11):
yes I was thinking just the event code all along. I think offset makes sense if a patient is reporting.
Grahame Grieve (Feb 06 2017 at 09:17):
so we shouldn't include Timing just for event+offset.
Grahame Grieve (Feb 06 2017 at 09:18):
does event + offset do all that omh want?
Eric Haas (Feb 06 2017 at 09:26):
I cannot say that for certain ....but I think it covers the the patient reported times like "at night" or "before work" ,"at lunch" or "around noon"
Grahame Grieve (Feb 06 2017 at 09:29):
I think we'd need a couple of more codes?
Arianne van de Wetering (Feb 06 2017 at 09:38):
For the 7 point profile for diabetes we need: 'before beakfast' (fasting blood glucose), 'two hours after breakfast', 'before lunch', 'two hours after lunch', 'before diner', 'two hours after diner', 'before sleep'.
And then there may be some additional measurements done by the patient (for example before/after some intense physical work activity), but those can be captured using date/time and some free text comments.
Grahame Grieve (Feb 06 2017 at 09:44):
are those codes? or '[x] hours before [event]"?
Arianne van de Wetering (Feb 06 2017 at 09:59):
I prefer [x] hours after [event], because it makes things generic and flexible
Eric Haas (Feb 06 2017 at 16:41):
I was not trying to enumerate all the daily events - yes there would be more. starting with the timing codes.
Eric Haas (Feb 06 2017 at 16:44):
so a signed integer to express time before and after an event. But this still is not a way to express BOTH a datetime and an event. The efffective time is 0..1 See
Eric Haas (Feb 06 2017 at 16:45):
Grahame Grieve (Feb 06 2017 at 19:26):
why doesn't it work for both? effectiveTime = [date], code = 'before lunch', offset = -1 hr
Eric Haas (Feb 06 2017 at 19:35):
Its unclear to me what you are thinking...
This is what I understand we were talking about:
- effective[x] 0..1 dateTime|Period| EventTiming where EventTiming is code + offset.
Adding essentially a mapping of the code+offset is not something I think the effective element should be used for.
Grahame Grieve (Feb 06 2017 at 19:37):
I thought it would be additional attributes since you'd at least need a day for the observation, which is effectiveTime
Eric Haas (Feb 06 2017 at 19:42):
Now I see the flaw in my understanding
so
Effective
dateTime 0..1
Period 0..1
event 0..1 code
offset 0.1 integer with invarient or new datatype = eventTiming
Grahame Grieve (Feb 06 2017 at 19:45):
if you mean this:
Effective dateTime 0..1 Period 0..1 event 0..1 code offset 0.1 integer with invarient or new datatype = eventTiming
Eric Haas (Feb 06 2017 at 19:49):
If patient reports to me it happened last night at dinner or about three weeks ago. that is the effective time relative to issued date. I am assuming no machine is reporting this information real time.
Eric Haas (Feb 06 2017 at 19:50):
That is different than an app where you pick the Dinner time BG and the the app records the time it was recorded.
Grahame Grieve (Feb 06 2017 at 19:51):
effectiveTime is not the time it was recorded. that would be issued in this case
Eric Haas (Feb 06 2017 at 19:55):
When I looked at this I interpreted it as effectiveTime
Eric Haas (Feb 10 2017 at 02:07):
@Grahame Grieve following up on this -we need an eventTiming datatype or something for fuzzy effective times . I'll concede the issued time is the app reporting time. Next steps? assume this is a topic for the next round
Grahame Grieve (Feb 10 2017 at 02:20):
y. will have to be extensions for now
Arianne van de Wetering (Feb 10 2017 at 12:53):
Another question: the offset is currently defined to be in minutes and minutes only. Why?
I would interpret a patient statement: "2 hours after meal" differently than "120 minutes after meal", due to the extra precision added with the minutes statement.
I would prefer to also allow the unit 'hour' in offset? At least for the self measurement use case.
Lloyd McKenzie (Feb 10 2017 at 20:58):
We were trying to keep things simple - the data type is already rather complex. Can OO, Pharmacy and PC have a discussion about whether the distinction between specifying minutes vs. hours is necessary/relevant?
Eric Haas (Feb 17 2017 at 21:47):
@Grahame Grieve Ok check out the core eventTiming extension for Observation I drafted. Comments welcome.
Last updated: Apr 12 2022 at 19:14 UTC
