Smart Inhaler Data

1

Hi,

We are planning to consume data sent across by a device that attached to an inhaler (a smart inhaler).

It records information like if the inhaler was used for control or rescue. It also has number of doses taken by the patient. It also captures medications, symptoms and triggers along with other indicators like was it used for preemptive purposes or used during night time.

Can you please provide guidance on which is the right resource for this?

2

MedicationAdministration would let you capture the the dose quantity, the time (from which you could infer day/night categorizations), the medication, the reasons (symptoms, pre-emptive/control/rescue would both count as ‘reasons’)

3

Thanks for the response - I have one additional query

One more we also have data coming for triggers - example: Exercise, Pollution, Tobacco etc. that needs to be tracked for this?

Please confirm how should this be tracked

4

Thanks for the response - I have one additional query

One more we also have data coming for triggers - example: Exercise, Pollution, Tobacco etc. that needs to be tracked for this?

Please confirm how should this be tracked

5

Those also sound like reasons for administration.

6

Tobacco usage should fall under Observation.

7

That’s true if you’re capturing what tobacco a person is using. However, this use-case is capturing that an inhaler needed to be used due to tobacco smoke - so capturing ‘tobacco smoke’ as a reason for administration would be appropriate. (We don’t actually care who was smoking.)

8

Wonderful thank you very much!

9

Three followups on this one, @lloyd.

Medication Administration has two properties for reasons… reasonCode and reasonReference. We’re trying to figure out where we should capture the nuance of whether something is a symptom (coughing, wheezing, etc.) or a trigger (allergies, smoking, etc.). If we try to use just reasonCode with a custom codeset, CodeableConcept really doesn’t allow for that nuance unless we hack it into the text (e.g. “symptom- coughing”). If we use reasonReference, it seems to be a better fit as the “type” on the reference would imply a symptom (Condition) or trigger (Observation). @lloyd, which way were you thinking?

Second, regarding dosage. Am I correct that dosage.dose would specify the number of doses/units taken, not the quantity of medication taken? The example on the site for Alprazolam 0.25mg Oral Tablet seems to indicate this (dosage.dose indicates 1 tablet administered, not 0.25mg). In this case, we would be recording the # of puffs from the inhaler, and the medication reference or dosage.text would be where the amount of medication per puff would be indicated.

Finally, asthma medications can either a rescue medication or a controller medication. While I assume this could be implied by the medication involved, it’s currently being explicitly provided to us as an attribute. Assuming we need to capture this explicitly, where would you map it? reasonCode doesn’t make as much sense to me, since this is really an attribute of the medication not an attribute of the situation. A custom use of “category” might work, or we could put something in “notes” to reflect it. Thoughts?

Thanks for your help.

10

Reference gets used when you’re pointing to a resource. Code is used when you’re pointing to a code. The code could pre-coordinate in the notion of it being a symptom, but in practice, if you have “Reason for administration=Environmental smoke, Asthma, Preventative” - with codes for each of those and your system recognizes the meaning of each of the codes, you can differentiate which element each should map to. It does require more work. If you wanted to, you could define extensions on each coding that would let you flag them. That makes life easier for you, but more difficult for those constructing the data they’re sending to you and there’s a risk that not all clients will bother to make the change.

Dosage can be expressed in different ways. However, the way you’re proposing (dose is in puffs, strength per puff is described in the medication) would be typical.

Rescue or Control would also be ‘reasons for administration’ (they could also be reason for ordering).

11

Thanks for the feedback. We’ll be taking the rescue vs. control back internally to see how they want to handle it. If the team wants that to be treated as a reason for the administration, then I agree. If it’s meant to be an attribute of the medication, then we’ll deal with it elsewhere.