Stream: implementers
Topic: Pharmacy Refill Use Case
Emily Subocz (Apr 17 2019 at 13:29):
Hi all,
We are looking into a Pharmacy Refill use case wherein we will need to house information about past and current VA prescriptions, tracking information for the deliveries mailed within the last 30 days, keep a list of all of the patient's medicines, along with some patient data including mailing address and email address. Our customer would prefer we use fhirversion DSTU2, but we are willing to use a more recent fhir spec if we find it is a better fit.
Our thoughts were that DSTU2 MedicationDispense resource would work, but that the STU3 or R4 MedicationRequest resource might be better suited. Does anyone have a take on which of these would work best?
Nathan Hall (Apr 17 2019 at 13:59):
Have you looked at MedicationStatement? https://www.hl7.org/fhir/DSTU2/medicationstatement.html . It is for R3 and R4 as well. It is a past, present, and future of a patient's medications.
Jose Costa Teixeira (Apr 17 2019 at 14:02):
MedicationDispense is the resource for actual dispenses
Jose Costa Teixeira (Apr 17 2019 at 14:04):
past and current VA prescriptions
seems a clear case for medicationRequest
Jose Costa Teixeira (Apr 17 2019 at 14:05):
tracking information for the deliveries mailed within the last 30 days
clearly Dispense. medStatement is when the patient says "i am taking metformin"
Jose Costa Teixeira (Apr 17 2019 at 14:06):
keep a list of all of the patient's medicines
why not bundle the known dispenses and known prescriptions in a List?
Jose Costa Teixeira (Apr 17 2019 at 14:06):
along with some patient data including mailing address and email address.
you can add a contained Patient resource i nthe list, and add the patient email and other details
Jose Costa Teixeira (Apr 17 2019 at 14:07):
so your overall resource would be a List (or a bundle?) with the information about prescribed AND dispensed dugs
Lloyd McKenzie (Apr 17 2019 at 15:27):
I wouldn't recommend using a 'contained' Patient. Remember containment isn't for ease of transport, it's because the resource can't stand independently. If you need to transport everything at once, just package it all up into a Bundle.
Jose Costa Teixeira (Apr 17 2019 at 15:31):
My reading was that address and email were just some "circumstancial" additional data on a patient that was not to be persisted, and the patient was otherwise already known.
If the patient mailing address and email are already in the patient resource, indeed best is just to bundle it together and not contained.
Lloyd McKenzie (Apr 17 2019 at 15:33):
If it's already known, you don't send it as contained, you just reference the existing resource.
Jose Costa Teixeira (Apr 17 2019 at 15:36):
ok
Melva Peters (Apr 18 2019 at 16:34):
I agree with @Jose Costa Teixeira , the use case seems to fit with Medication Dispenses which are the actual dispense events for a patient. You could bundle MedicationDispense with MedicationRequest (prescription/orders) and even MedicationStatements (records of other medications the patient says they may be on) if you have them for a list.
Last updated: Apr 12 2022 at 19:14 UTC