FHIR Chat · MedicationStatement.notTaken · implementers

Stream: implementers

Topic: MedicationStatement.notTaken


view this post on Zulip Melva Peters (Mar 19 2018 at 21:03):

Pharmacy WG made a change in the build (leading up to R4) that merged MedicationStatement.taken into MedicationStatement.status (not-taken) as a result of alignment with workflow patterns. As a result, MedicationStatement can no longer be used to get the “active medication list” for those medications that are not-taken. For example, the patient who tells her primary care physician “I’m not taking those prenatal vitamins that the OB prescribed”. The PCP could note that the patient isn’t taking the medication but would likely want to keep that medication on the “active meds list” for clinical decision support since the patient should be taking it.

A few WGMs ago, we collectively worked the following table in http://hl7.org/fhir/STU3/medicationstatement.html#11.4.3.3, which started with “The MedicationStatement resource includes both a status and a taken code. The taken code conveys whether the medication was taken by the patient from the perspective of the information source. The status code reflects the current state of the practitioner’s instructions to the patient whether the consumption of the medication should continue or not.” Unfortunately, this has all been removed in build (R4).

In New Orleans, Pharmacy resolved GF#15105 saying that we were going to ask Workflow for an exemption on the pattern, so MedicationStatement could revert back having taken and status as separate elements.

In some offline conversations held with Lloyd (representing Workflow) and Pharmacy co-chairs, it has been noted that MedicationStatement shouldn’t be used to convey practitioner’s instructions. Instead, Lloyd’s recommendation is to use MedicationRequest. In the past (DSTU2), the resource was named MedicationOrder, so it didn’t appear it could represent recorded/historical/OTC statements of medication use because it wasn’t an authorization to dispense. By contrast, in STU3, the argument is that MedicationRequest is more broadly scoped, such that the MedicationRequest.intent can differentiate between an “order” (i.e. authorization for action) versus “plan” (i.e. intention to ensure something happens without providing an authorization to act).

There are at least 3 options on the table for consideration:
1) Continue to ask for an exemption from the workflow pattern and revert back to taken and status as separate elements.
2) US Core switches to MedicationRequest to convey “active meds list” since scope has been expanded, so we can now include OTC meds and/or meds from other providers as MedicationRequest with intent = plan.
3) US Core embraces List to convey “active meds list” because MedicationStatement.status doesn’t work anymore when status is not-taken.

The Pharmacy Work Group is seeking input from implementers to assist in their discussions and in the final decision on how to proceed. Thank you.

view this post on Zulip Grahame Grieve (Mar 20 2018 at 01:18):

The relationship between MedicationRequest and MedicationStatement is challenging us. Personally, I think it's reasonable to capture the working instructions on a medication statement. That would usually be the practitioners instructions. That's not the same as disgreeing with Lloyd. I think the use case is very important.

view this post on Zulip Lloyd McKenzie (Mar 20 2018 at 01:27):

The question is whether it's appropriate to have both "this is what was ordered" and "this is what's actually happening" in the same resource. (And it's possible there could even be multiple conflicting sets of clinician directives simultaneously in force, so there'd be a challenge round which instructions to expose - and the question of whether you want to track who gave those instructions, when, etc.)

view this post on Zulip Grahame Grieve (Mar 20 2018 at 01:28):

I was going for 'this is what's actually happening' .

view this post on Zulip Lloyd McKenzie (Mar 20 2018 at 01:30):

Agree it should reflect what's actually happening - and in many cases that will align with what was ordered, but not always. And I don't think we can overload the resource by trying to convey both.

view this post on Zulip Grahame Grieve (Mar 20 2018 at 01:31):

I think that 'should continue' is distinctly not 'what was ordered' - perhaps we understand the use case differently?

view this post on Zulip Lloyd McKenzie (Mar 20 2018 at 01:34):

"not taking" is what's happening. "Should continue" is what was ordered.

view this post on Zulip Grahame Grieve (Mar 20 2018 at 01:35):

@Melva Peters so Lloyd and I do disagree... is 'should continue' something decided on request, or something that might be updated later?

view this post on Zulip Melva Peters (Mar 20 2018 at 02:07):

typically the should continue is decided at the point when a medication history is taken or when medication reconciliation is done. The patient may say I was prescribed drug A, but I'm not taking it and the prescriber may say the patient should be taking drug A. There isn't really a need for a new MedicationRequest since the patient likely still has it at home. I'll leave it up to @Michelle (Moseman) Miller to weigh in here on how they are using MedStatement to come up with the list of active medications.

view this post on Zulip Richard Townley-O'Neill (Mar 20 2018 at 03:01):

2 cents
The status should not be overloaded with some codes about the order and other codes about use. I think that status should be about the use of the medication. If you want to say in MedicationStatement that the medicine is not being taken, but it is still prescribed, I suggest putting "not taking" in MedicationStatement.status and creating a new data element for the "Prescription being ignored" information.

view this post on Zulip Jose Costa Teixeira (Mar 20 2018 at 06:54):

@Michelle (Moseman) Miller this seems related to some brief discussion about "statement of a request", if you recall that.
1 (eur) cent: I think that medStatement was conceived to be a statement of use. So it is not easy to put there "statement of request" nor "statement of dispense".

view this post on Zulip Jose Costa Teixeira (Mar 20 2018 at 06:59):

I think Melva's use case makes sense: patient has been prescribed elsewhere, and physician says "don't stop that medication". Another use case I have is: patient mentions he has been prescribed and dispensed some medication but asserts he is not taking it for whatever reason.

view this post on Zulip Jose Costa Teixeira (Mar 20 2018 at 07:01):

In both cases I think we'd be best by considering a "statement" of prescription, then a "statement" of dispense.

view this post on Zulip Paul Knapp (Mar 20 2018 at 07:04):

In an emergence, and perhaps other, treatment setting I expect they would want to know what you have and an indication of what you say you are taking since the reaction you are now having may be due to the fact that you just started taking something you have.

view this post on Zulip Jose Costa Teixeira (Mar 20 2018 at 07:05):

To address this: Could we extend our "xxxStatement" resources to contain and refer to another resource like request"?
so we can have a MedStatement (or device or biologicallyDerivedProduct or whateverStatement) also saying "this is a statement that a request is active".

view this post on Zulip Paul Knapp (Mar 20 2018 at 07:17):

Wouldn't the Request itself say the request is active?

view this post on Zulip Jose Costa Teixeira (Mar 20 2018 at 07:17):

yes, but we are talking about the case where there is no need to create a request.

view this post on Zulip Paul Knapp (Mar 20 2018 at 07:18):

Ah. Ok then.

view this post on Zulip Jose Costa Teixeira (Mar 20 2018 at 07:19):

e.g. patient goes for surgery and there is an active prescription, but the physician must take the info that patient was prescribed that drug, but does not need to create a prescription for that purpose.

view this post on Zulip Michelle (Moseman) Miller (Mar 20 2018 at 12:52):

@Melva Peters commented

typically the should continue is decided at the point when a medication history is taken or when medication reconciliation is done. The patient may say I was prescribed drug A, but I'm not taking it and the prescriber may say the patient should be taking drug A. There isn't really a need for a new MedicationRequest since the patient likely still has it at home. I'll leave it up to @Michelle (Moseman) Miller to weigh in here on how they are using MedStatement to come up with the list of active medications.

Generally speaking, I agree.

To elaborate, we persist all of the following on the same table:

  • Orders (an authorization to dispense)
  • Over the counter medications (no authorization needed)
  • "Statement of a request" as @Jose Costa Teixeira called it (patient reports an authorization to dispense from another provider - meaning our system doesn't have the official prescription, but we want to capture the existance of that existing prescription without creating a new/duplicate authorization to dispense; we refer to these as recorded or historical orders)

We have the ability to capture 2 statuses in our system.

  • the "order's" status ("order" = orders + OTC + recorded/historical/statements about orders), which is more about whether the patient should be taking the medication or not. The status is determined by the provider (often during meds reconciliation)
  • the taken status noting there can be multiple taken statuses (on different dates) for a single "order". The taken status is based on patient/related person feedback. We can not capture a taken status without the parent "order" being documented (even if it is just a recorded/historical order and not a formal authorization to dispense)

view this post on Zulip Lloyd McKenzie (Mar 20 2018 at 14:56):

Does the inability to record "taken" without an order hold for over-the-counter meds? Also, the many to 1 nature of taken to order seems to argue for separate records

view this post on Zulip Michelle (Moseman) Miller (Mar 20 2018 at 15:54):

Yes, same for OTC.


Last updated: Apr 12 2022 at 19:14 UTC