Questions about Pharmacy designs

Owned by David DeSimone
Last updated: Mar 24, 2022
2 min read

Designs are here:  https://app.zeplin.io/project/61af2b325f2c328f972eafbd/screen/61af53225f2c328f9730ed33


  • We'll need to figure out exactly what the tabs on the main pharmacy page should represent.  We were thinking maybe for phase 1, just have a tab for "today's prescriptions" and another one for "all".
    • "Today's Prescriptions"  - would include just active prescriptions ordered today.  I.e. a list of what you expect to most likely fill for the remainder of the day. 
    • All Prescriptions - a place to view all prescriptions is necessary but we have a concern about the implementation of this.  Due to high volumes of orders (we expect > 1000/day at one of our facilities), we are thinking we may want to require filtering based on patient before displaying any orders.
  • We will need to include patient identifier as a column.  Our primary use case for this page will be the pharmacists scanning a patient's card (which scans to the patient identifier) to display the active orders for that patient.
  • We didn't see any functionality in the designs for the ability to edit dispensed medications.  That is, if there is a data entry error in the dispensed details, there needs to be a way to correct it.  I assume there would just be an edit icon next to the dispensed med details that opens up the sidebar to allow for editing of those details.   Access to this could be limited by permissions to certain users and/or the user who entered the data originally.
  • It's hard to tell from the designs but it seems the pharmacy page is listed as a row-per-prescription and not a row-per-order.  The difference being that there may be multiple orders per prescription.  We should discuss this, but due to implementation complexities, we may prefer to display a row-per-order.  So if a clinician prescribed several meds to a patient, there would be several separate rows and the user would need to click on each one separately and dispense each one separately.  If we think this is too onerous for the user, we can re-think this.  But it seems the FHIR modeling for medication request defaults to a single medication so that is what we are thinking now.  But it would be good to know to what extent this was considered in the designs before we move forward with this.