Stream: implementers
Topic: MedicationDispense Relationship to Pharmacy Claim
Brian Rickabaugh (Mar 05 2020 at 16:36):
Philosophically:
Is the presence of an adjudicated, PAID pharmacy claim enough evidence to support (“prove”) the occurrence (or existence) of a MedicationDispense event within an ecosystem?
More generally, is it appropriate for pharmacy plan managers to publish MedicationDispense resources? Or, is MedicationDispense by specification strictly limited in scope to physical dispensaries?
In practice:
Within my dataset, I have a record of pharmacy claims that have been adjudicated for members: PAID, DENIED, REVERSED, etc. From this dataset alone, is it possible and valid to produce MedicationDispense events and provide them to a querying party? Would doing so adhere to the spirit and letter of the specification? Is there any grey area open to interpretation by implementers?
If you make the leap and connect the two events (claim adjudication → medication dispense), how would MedicationDispense.status be set immediately following adjudication event? Would “in-progress” be appropriate? If so, in the absence of any other future event being emitted (e.g., physical hand-off), would “in-progress” be an end (terminal) state for the resource?
Thanks in advance.
Jose Costa Teixeira (Mar 05 2020 at 16:52):
Brian Rickabaugh said:
Or, is MedicationDispense by specification strictly limited in scope to physical dispensaries?
I think it is acceptable to have a MedDispense as a notification, so I don't see it as a strict limitation
Jose Costa Teixeira (Mar 05 2020 at 16:54):
you could use Dispense.Category to indicate that this is a special type of dispense.
Lloyd McKenzie (Mar 05 2020 at 16:55):
An insurer might even have received a trimmed down copy of the MedicationDispense with the claim - for example conveying dosage information that isn't representable elsewhere in the Claim resource.
Igor Sirkovich (Mar 05 2020 at 17:10):
More generally, is it appropriate for pharmacy plan managers to publish MedicationDispense resources?
We did this in Ontario, Canada: we had repurposed the provincial claim data (Ontario government covers drug costs for people over 65, under 25 and some other vulnerable populations) to a repository of MedicationDispense resources. We had just left "whenHandedOver" blank as there was no information on the claims when/if a patient had picked their medication up.
Brian Rickabaugh (Mar 05 2020 at 19:40):
@Igor Sirkovich
What status did you use for these MedicationDispense resources?
Wouldn't the intent be to set whenHandedOver when the status was changed to "completed"?
Brian Rickabaugh (Mar 05 2020 at 19:56):
@Lloyd McKenzie
I think of the MedicationDispense (A) and Claim (B) resources as distinct, but related.
Event A can occur without B. For example, the dispensing of a trial medication to a patient at the point of care. This might also be true if a patient pays for a medication with out-of-pocket funds.
There is an expectation that a PAID claim event (A) would be followed by a MedicationDispense event (B). As such, I think the scenario you describe makes sense.
My question is, can you conjure A from B?
Lloyd McKenzie (Mar 05 2020 at 21:22):
Yup. You know who dispensed what to whom, how much and when. That's the core information needed to make an assertion of a MedicationDispense, even if the data didn't arrive that way. Obviously inferring clinical data from claims data carries risks, but of the types of clinical information that could be inferred, a MedicationDispense is relatively low risk. The best a MedicationDispense can tell you is "there's a decent chance this patient is on this medication". Inferring things like Conditions based in claim-based admitting diagnoses, etc. would be a much more questionable.
Igor Sirkovich (Mar 06 2020 at 00:09):
Brian Rickabaugh said:
Igor Sirkovich
What status did you use for these MedicationDispense resources?
Wouldn't the intent be to set whenHandedOver when the status was changed to "completed"?
We used "completed" status since our Business had defined that from the pharmacy & payer perspective, a dispense that was prepared, claimed, paid and not reversed was considered "completed" even if we couldn't assert whether a medication was actually picked up and consumed by a patient.
Brian Rickabaugh (Mar 06 2020 at 16:52):
In my context, a claim is marked PAID when: the pharmacy submits the claim, the claim adjudicates and the payer (my organization) has committed to reimburse the dispensing pharmacy. “PAID” does not mean that the patient has “paid” for the medication at the pharmacy POS counter. That is, the timestamp on the PAID claim is not when the medication changes hands. IMO, this would not qualify as a timestamp that could be used in the whenHandedOver field.
For example, there is a scenario in which the prescription is e-prescribed by the physician. In most cases, the e-prescription will be immediately sent to the destination pharmacy before the patient leaves the office. Once the prescription request is received, the pharmacy will: submit the claim, fill-it and drop it in a basket to wait for the patient – the claim is now "PAID". If you infer MedicationDispense at this moment in time, you should use "in-progress" (The dispensed product is ready for pickup.) for status, by specification.
If the patient decides to not pick up that prescription, after a couple of weeks and attempts to contact the patient the pharmacy will reverse the claim and put the medication back on the shelf. Is it valid to have provided MedicationDispense resources in the interim? I am concerned, as @Lloyd McKenzie points out, that downstream consumers could use these resources to influence clinical analytics and decisions.
To take a position, I am inclined to not overload a PAID claim event to infer MedicationDispense.
I am really interested in and open to debate.
Lloyd McKenzie (Mar 06 2020 at 17:11):
The existence of a dispense doesn't mean a patient is actually consuming a med - it just means that they are "likely" taking a medication. Even in the absence of the claims piece, a MedicationDispense would be created and then later cancelled a week or two later if the patient never showed to pick up the med. It's fine to do the same for claims-inferred data.
Patrick Murta (Mar 09 2020 at 11:27):
@Lloyd McKenzie & @Igor Sirkovich ....
Patrick Murta (Mar 09 2020 at 11:29):
Help me understand your perspective better. The HL7 site reads "The medication dispense is the result of a pharmacy system responding to a medication order." It seems a bit of a stretch to coerce a claim transaction into dispense resource?
Patrick Murta (Mar 09 2020 at 11:38):
Also, US Core provided guidance on this that medication request may be a suitable option? http://hl7.org/fhir/us/core/all-meds.html
Melva Peters (Mar 09 2020 at 13:37):
I don't agree that a medication request should be generated from a claim. The claim typically originates from the pharmacy and not the prescriber - I think it more closely aligns with the medication dispense. It is an event that has taken place and not a request for something to be done. In my experience, when a claim is sent to the insurer it is based off of the dispense that is captured in the sending system.
Patrick Murta (Mar 09 2020 at 13:53):
My thought was that the dispense event MUST come directly from the dispensing rx system. It sounds like others are interpreting this as meaning that a medication dispense can be derived or inferred from other events such as claims. Am I interpreting this correctly?
Patrick Murta (Mar 09 2020 at 14:05):
USDCI/US Core references medication request, not medication dispense, which add another perspective on this...
Melva Peters (Mar 09 2020 at 14:39):
The MedicationDispense resource is not used in the US as the dispense claim is based on the NCPDP standard. That isn't true in other countries.
Lloyd McKenzie (Mar 09 2020 at 16:15):
Resources are representations of known information about the real world. A MedicationRequest instance says "Someone ordered this drug for this patient". A MedicationDispense instance says "Someone supplied this drug for this patient". It's possible to flag an instance as being the authoritative/source-of-truth instance, but there will be lots of instances floating around that are not source of truth that have reduced information and/or may have been inferred from other data.
Patrick Murta (Mar 10 2020 at 12:14):
Great information... I also wanted to get the groups thoughts on medication statement as compared to medicationrequest and medicationdispense. As a payer, we went with medicationstatement with our first production implementation since it seems to be the most appropriate for claims derived RX and also for self report and OTC. Are you sensing a general moving away from medicationstatement? I find it it interesting that US Core seems to gravitate to medicationrequest.
Melva Peters (Mar 10 2020 at 13:37):
MedicationStatement (now called MedicationUsage in R5) is intended to be used when a patient or prescriber or caregiver says they are taking a medication, or have taken a medication or may take the medication again. For example, in history taking by a nurse. It is also intended for recording when a patient says they are taking an over the counter medication like an antihistamine. MedicationRequests are for orders, plans or proposals for medications - it is a request for something to happen. The primary use case is when a prescriber prescribes as medication for a patient. I don't believe there is a move away from MedicationStatement. It should be used for the above use cases, but shouldn't be used when recording an order/plan/proposal from a prescriber or a dispense record from a pharmacy system.
Lloyd McKenzie (Mar 10 2020 at 14:52):
US Core has had concerns/challenges using multiple resources to represent a medication list. There's still ongoing discussion about the need to support both MedicationRequest and MedicationStatement.
Jose Costa Teixeira (Mar 10 2020 at 15:31):
It seems that your question is not which resources to use, but rather what is the type of information in the medication list. If you want to say that medication was ordered, you have a request. If you want to say that medication was dispensed, you put a dispense.
Jose Costa Teixeira (Mar 10 2020 at 15:33):
If you want to flatten whatever information onto a summary which means "somehow it is known or thought that the patient is or will be on this medication" then you have a usage.
Last updated: Apr 12 2022 at 19:14 UTC
