Stream: implementers
Topic: Use of Timing for past events
Grahame Grieve (Feb 15 2017 at 02:24):
Lloyd and I are arguing about GF#12637. The task proposes the removal of the sentence "Timing schedules are not used for recording when things did happen, but when they are expected or requested to occur", so that Timing can (magically) be used for recording when things did happen.
But to actually remove that sentence, a lot of definitions need to be updated (e.g. definitions of Timing, the requirements, the comments, and the same for the elements Timing.repeat, Timing.repeat.count, Timing,repeat.timeOfDaym, Timing.repeat.when). And examples added. And probably a new element added to express mood. Also,l think this is *bad* idea (I wasn't there when it was discussed).
So I have refused to remove that sentence, and referred the task back to the committee (MnM). Which means that this task won't make the STU3 cut-off.
And that leaves Procedure.performedTiming as illegal- though it already is illegal, since it doesn't conform to it's own definition.
Lloyd McKenzie (Feb 15 2017 at 04:53):
It also leaves MedicationStatement.dosageInstruction.effectiveTiming as of questionable legality as this will often be used not to convey "how were you instructed to take it" but "how did you take it" as MedicationStatement is frequently used to capture over-the-counter and even illicit substances where no instructions were provided. (And even if instructions were given, MedicationStatement is intended to reflect what did actually happen/is actually happening, not what was supposed to happen.)
Lloyd McKenzie (Feb 15 2017 at 04:54):
It's not clear that a new element to convey the mood is needed - the mood should be implicit in the use of the data type. I.e. the element would need to indicate whether it's an intended timing or an actual timing.
Lloyd McKenzie (Feb 15 2017 at 04:55):
It would be helpful if you could indicate the reasons why you feel it's a bad idea. Certainly there are use-cases for discretely capturing the frequency, duration, min-max repetitions, alignment and offset from meals, etc. for things like exercise and medications that have happened in the past or are currently ongoing.
Lloyd McKenzie (Feb 15 2017 at 04:57):
I mis-typed. It's MedicationStatement.dosage.timing. And the description is explicit that the information indicates how the medication *was* taken, so it's definitely about the past.
Grahame Grieve (Feb 15 2017 at 05:16):
well, MedicationAdministration is a deeper mess then.
MedicationAdministration.dosage: Details of how medication was taken
DosageInstruction: How medication should be taken
I had interpreted this as 'the instructions the medication were taken according to', which is not the same. And how to reconcile MedicationAdministration.period vs DosageInstruction.timing? I thought it was clear, but to me, the definition of MedicationAdministration.dosage is wrong and impossible.
Further, all the definitions of DosageInstruction follow Timing: "this is what you should do"; it has the same problem if you just wantonly use it to be 'this is what we did do'
Grahame Grieve (Feb 15 2017 at 05:18):
I think that using Timing for what did happen is overkill. So far, I'm aware of:
- this event happened at a given time
- this event happened over a time interval
- this event happened on a given day, relative to an event (e.g. evening, or breakfast, etc)
Lloyd McKenzie (Feb 15 2017 at 06:01):
This isn't about MedicationAdministration - it doesn't use Timing. MedicationStatement does. If you're talking about medications and other things like certain physiotherapies, how often matters. And "how long" can matter too. Essentially, if it matters on the request side, then it matters on the event side. The reason it matters is because these resources are used to capture summaries of event patterns, not just discrete individual events. MedicationAdministration lets you say "on this date, at this time I gave drug x". MedicationStatement lets you say "I take this med 2-3 times a day with meals" or "I run for 30-45 minutes every morning before breakfast". If you want decision support to evaluate the adherence of the event behavior to the order behavior, then the event timing needs to be captured discretely.
Lloyd McKenzie (Feb 15 2017 at 06:01):
Agree that DosageInstruction needs to be recast to allow it to reflect both "instruction" and "behavior"
Grahame Grieve (Feb 15 2017 at 06:09):
MedicationStatement not MedicationAdministration. Made the mistake once and copy/pasted it
Grahame Grieve (Feb 15 2017 at 06:10):
"These resources are used to capture summaries of event patterns" - that pretty clearly is *not* the stated scope of Procedure, and it would be nice if that was more clearly stateed in the definition of MedicationStatement. The definition of Procedure makes it aligned tightly with MedicationAdministration.
Grahame Grieve (Feb 15 2017 at 06:11):
it might be useful to consider this difference in the event pattern itself, btw.
Grahame Grieve (Feb 15 2017 at 06:11):
I do not like data types that cross moods. The definitions are messy, because the elements that apply to both get screwy definitions, and some elements only apply to one mood, and not the others.
Lloyd McKenzie (Feb 15 2017 at 06:12):
Well, Procedure is currently an amalgamation of a detailed procedure record and a "statement-like" structure. It doesn't do either terribly well. There's a proposal to split it in STU 4. The detail would be useful within surgical and other systems, and the "statement" would be useful for capturing medical history and patient summary information.
Lloyd McKenzie (Feb 15 2017 at 06:12):
Most of our data types cross moods.
Grahame Grieve (Feb 15 2017 at 06:13):
also, I'm far from convinced that you can meaningfully say 'over this year, I took this medication at the following times' as opposed to 'for this year, I took this medication per the following instructions'
Lloyd McKenzie (Feb 15 2017 at 06:13):
All the other time data types cross moods.
Grahame Grieve (Feb 15 2017 at 06:13):
such as?
Grahame Grieve (Feb 15 2017 at 06:13):
no they are mood independent
Lloyd McKenzie (Feb 15 2017 at 06:13):
date
Lloyd McKenzie (Feb 15 2017 at 06:13):
time
Lloyd McKenzie (Feb 15 2017 at 06:13):
Right. And we want this to be mood independent too.
Grahame Grieve (Feb 15 2017 at 06:13):
I don't believe in that .
Grahame Grieve (Feb 15 2017 at 06:14):
anyway, you're basically making up stuff you wish to be true irrespective of the stated definitions.
Grahame Grieve (Feb 15 2017 at 06:14):
I think pharmacy will have to sort out the definitions urgently
Lloyd McKenzie (Feb 15 2017 at 06:14):
With MedicationStatement, we don't care what the instuctions were - we care about what the patient's actually doing. If we cared about the instructions, we'd send a copy of the order.
Lloyd McKenzie (Feb 15 2017 at 06:14):
I'm talking about the use-cases I've seen the work groups discuss.
Grahame Grieve (Feb 15 2017 at 06:15):
that's not how you read it when it says 'dosage instructions'
Lloyd McKenzie (Feb 15 2017 at 06:15):
But it doesn't say that
Grahame Grieve (Feb 15 2017 at 06:16):
I'm pretty sure "DosageInstructions" means 'dosage instructions'
Lloyd McKenzie (Feb 15 2017 at 06:16):
Element is Medication.dosage, definition "Details of how medication was taken". It's just that the type happens to be labeled DosageInstruction.
Lloyd McKenzie (Feb 15 2017 at 06:16):
The semantics come from the element, not the type
Lloyd McKenzie (Feb 15 2017 at 06:16):
(Though the type ought to be labeled in a more agnostic way)
Lloyd McKenzie (Feb 15 2017 at 06:17):
Anyhow, I'll be quiet for a bit and wait for @Melva Peters @John Hatem @Michelle (Moseman) Miller and some of the others more directly involved with these resources to say their piece.
Jose Costa Teixeira (Feb 15 2017 at 10:39):
well, the type says "How medication should be taken". and the definition states that this granularity should only be populated when the medicationStatement is derived from scheduled dosage instructions (in a labeled container, or from a request)
Jose Costa Teixeira (Feb 15 2017 at 10:40):
there is no guarantee that the medication in a statement was taken as per the instructions.
Jose Costa Teixeira (Feb 15 2017 at 10:41):
medicationStatement is kind of aligned with the mess that most systems do when capturing "medication lists". (i.e. ixing orders and events in one flat line)
Jose Costa Teixeira (Feb 15 2017 at 10:48):
all the medication event resources handle the event timing in a different way, instead of using dosageInstructions. I'd say that statement should also do the same, and not reuse the dosageInstructions for that. Or otherwise make it clear that one thing is the dosageInstruction and the other tihing is the actual dose.
Lloyd McKenzie (Feb 15 2017 at 18:20):
@Jose Costa Teixeira The element definition does make clear that it's reflecting actual use, not instructions. But the fact the type is called "DosageInstructions" rather than "Dosage" is certainly a source of confusion.
Igor Sirkovich (Feb 15 2017 at 18:47):
I see the confusion here. Maybe it would be better to call the type "Dosage" and to call the element in MedicationRequest & Medication Dispense "DosageInstructions"?
Melva Peters (Feb 15 2017 at 21:52):
Changing the type name to dosage.
Michelle (Moseman) Miller (Feb 15 2017 at 23:49):
Patient Care will discuss how to handle Procedure tomorrow (Thurs, Feb 16 at 5pm Eastern). I believe there are use cases to document a procedure of "attended counseling once a week" or "exercised 3 times a week for 30 minutes" especially in context of CarePlan.activity.outcomeReference, which can reference a Procedure.
Michelle (Moseman) Miller (Feb 17 2017 at 02:35):
Patient Care voted today to remove Procedure.performedTiming and instead add an extension for Procedure.schedule. I've applied those changes tonight.
CC: @Lloyd McKenzie @Grahame Grieve
Grahame Grieve (Feb 17 2017 at 02:58):
thanks
Eric Haas (Feb 17 2017 at 03:58):
We talked about Observation needing more of a fuzzy effective time than a timing element. code + offset. Should I make an standard extension for that? so can record things occuring at bedtime or half an hour before dinner.
Grahame Grieve (Feb 17 2017 at 04:04):
I think you should, yes.
Last updated: Apr 12 2022 at 19:14 UTC
