Stream: Medication
Topic: MedicationDispense
Michelle (Moseman) Miller (May 05 2021 at 18:41):
Consider a scenario when a pharmacy attempts to prepare a dispense, but cancels it prior to the dispense being handed over to the patient. At a later point in time, the pharmacy makes a second attempt to prepare a dispense and successfully hands it over to the patient. Which of the following represents what you would expect to see?
Option 1: A single dispense record that is modified over time. The status lifecycle of the single dispense would be: preparation > cancelled/stopped > preparation > completed
Option 2: A dispense record for each attempted dispense event (e.g. one record has cancelled/stopped end state status; second record has completed end state status).
Lloyd McKenzie (May 05 2021 at 21:36):
My leaning would be the second - not that my opinion counts for much here :)
Jose Costa Teixeira (May 05 2021 at 23:47):
What is "cancels it"? If it is removed from the original packaging, it most likely cannot be un-dispensed. Also the reason for canceling may need to be recorded, and the reason for un-dispense may be tricky. If the second dispense is just a simple update to the previous dispense attempt, option 1 may suffice.
Jose Costa Teixeira (May 05 2021 at 23:48):
But anything beyond simple should be safer with option 2
Jean Duteau (May 06 2021 at 01:52):
i think that it is up to the implementation. I don't think we (the Core Spec) want to say anything about that. There are pros and cons to each option. I too lean towards #2 but I can see why #1 would work for some systems.
John Moehrke (May 06 2021 at 12:52):
2
Vassil Peytchev (May 06 2021 at 14:34):
What is the context? Is it a pharmacy IT system design? Is it patient-centric interoperability? Is it pharmacy IS interoperability? I think the answer will depend on the specific context.
From the patient care point of view, there should be only one Medication Dispense resource, the one that was successfully handed over to the patient. The information that there was a "failed attempt" is of no obvious use outside the pharmacy.
Jose Costa Teixeira (May 06 2021 at 17:38):
A failed attempt at dispensing may be relevant for inventory management as well.
Vassil Peytchev (May 06 2021 at 19:13):
That would be part of pharmacy IS interoperability.
Jose Costa Teixeira (May 06 2021 at 22:47):
Right. my comment was about the failed attempt being of no obvious use outside the pharmacy
Michelle (Moseman) Miller (May 17 2021 at 15:19):
Context is interop (sharing the dispenses across systems for various consumption purposes).
Scott Robertson (May 17 2021 at 18:38):
status=declined is the closest I see for "we started the dispense but we stopped and we may do this dispense in the future".
In my experience, I have not had a need to track the declined dispense internally. So, I would go with Option 1.
If there is an operational need to track the declined dispense, then Option 2 is necessary. I'm interested in thoughts on why the decline dispense would need to be tracked.
Jose Costa Teixeira (May 17 2021 at 19:06):
I can imagine that this would be the case if the dispense fails (jar is broken before giving it to the patient; realizing that there was a mistake/issue with the quantities while mixing a solution)
Jose Costa Teixeira (May 17 2021 at 19:07):
in that case you may want to capture that.
Jose Costa Teixeira (May 17 2021 at 19:07):
I don't consider this a dispense, but a consumption. So we may not need to capture this as a Dispense resource
Last updated: Apr 12 2022 at 19:14 UTC
