Stream: implementers
Topic: MedicationRequest and insulin pump data
Michael Lawley (Sep 10 2020 at 01:14):
I am looking for some advice on representing certain data relating to insulin pumps.
In the first instance I am looking at temporary basals where there's essential an instruction to the pump to set the dose to {x} units / hour for the next {y} min. This translates well into a MedicationRequest, and adapts appropriately for the "suspend" case (set dose to zero for {y} min).
The case I'm stuck on is the "cancel temp basal" -- is the appropriate approach to set doNotPerform to true and then reference the original temp basal MedicationRequest with priorPrescription?
I am also wondering if MedicationStatement is the more appropriate resource to be using for both, but again it is not obvious how to represent "cancel"
Jose Costa Teixeira (Sep 11 2020 at 13:35):
Did you see IHE's MMA profile? Has some guidance on this type of administrations
Melva Peters (Sep 11 2020 at 16:05):
I'm not sure I understand. Is this a conditional dosing? For example, set to x per hour for y min "if the z condition" exists or doesn't exist? if so, there is an extension that is part of the current build for conditional dosing. This is in the current build not R4. http://build.fhir.org/extension-dosage-conditions.html
Michael Lawley (Sep 14 2020 at 07:52):
No, this isn't conditional. This is "change the dose to x/hr for next y min", then, before that y min timeframe is up, "cancel that change" (and revert to the underlying delivery profile. This corresponds quite directly to how people operate their insulin pumps.
I realise the "cancel" could rewrite/update the original change request to specify a different timeframe for "y", but the paradigm here is more of a messaging one than a document one.
Jose Costa Teixeira (Sep 14 2020 at 10:43):
Why are you looking at do not perform? why not status=on-hold?
Jose Costa Teixeira (Sep 14 2020 at 10:44):
so basically you could have one "umbrella" request (your basal) and the rest is changes that you can start and stop as you want.
Jose Costa Teixeira (Sep 14 2020 at 10:46):
I don't think there is any guidance on what to do if you have requests that overlap in time. The safest would be :
- start basal, from now until eternity
- start change, for 10 minutes - and put the basal on hold
- cancel change after 8 minutes, go back to basal=active
- close basal
Jose Costa Teixeira (Sep 14 2020 at 10:47):
these are medrequests with intent=instance-order
Michael Lawley (Sep 14 2020 at 11:39):
Ah, I have just noticed priorPrescription. It looks useful, but the definition/description is confounding; the short description mentions replacement, but the detailed definition does not.
Michael Lawley (Sep 14 2020 at 11:45):
The challenges I'm having are expressing the "put the basal on hold" semantics (priorPrescription is tantalisingly close), and "go back to basal=active".
The model itself is quite simple: 1. Do X; 2 Do Y instead for a bit; 3 Stop Y & revert to original plan.
What I think I shouldn't have to do at step 3 is re-state the original "Do X"
Melva Peters (Sep 14 2020 at 13:28):
@Jean Duteau
Vassil Peytchev (Sep 14 2020 at 14:26):
What I think I shouldn't have to do at step 3 is re-state the original "Do X"
Isn't that the difference between system design and interoperable data exchange? I agree that a user who is entering the command should not have to enter "Do X", but what is the problem of letting the user's "Stop Y & revert to original plan" action result in a data exchange stating "Do X"?
Last updated: Apr 12 2022 at 19:14 UTC
