For the Dispensing ESM, there are several outstanding questions we are going to need to discuss, both from a functional and technical level. It seems like it would make sense to have a regular forum to discuss these issue. Thoughts on where that should be? The TAC? Another existing call? A new regular call while the project is ongoing? Specifically, for some of the questions, we need input from both the functional and technical side, so it would be be good to get all the key stakeholders “in the room” together.
For example, one issue I had a question about is the meaning of “Completed” within the Dispensing ESM, as shown in the following screenshot. There are questions on both the functional and technical side around this.
What does it mean from a business perspective for an Order to be “Complete”? Does this simply mean that, say, if a Order has refills=3, that there are four (initial + 3 refills) medication dispense records associated with the order? What when partial dispense events, etc… do we need to actually calculate the number of pills dispensed, etc?
In the Dispensing UI, a row is actually a group of all the Orders associated with an Encounter… what does it mean for a group of orders to be “Complete” (I would assume the logic would be that group is considered Complete if all the Orders are Complete)?
Once we determine the logic, how should we capture it? Should we update the “Fulfillfur Status” on the Order to “COMPLETE”? Or should this be something that is calculated on demand? Or stored some other way?
Where should this logic live? In Core somewhere? It seems to me no–this should be owned by the “Pharmacy System”, which, in some cases, would be a separate, integrated system, and, in this case, the “Dispensing ESM” is just a simplified pharmacy system that just happens to build into OpenMRS. So that when posting the “Medication Dispense” objects to OpenMRS the “Pharmacy System” should also send a request to update the Order as being “Complete”. Do we have a pattern yet in O3 as to where business logic like this should live? Ie, is there something in O3 parallel to an OpenMRS module, where the API would extend the OpenMRS business logic, and the OMOD would extend the UI?
When determining all this, we need to consider the search requirements. The current screen design has a single table for displaying all Orders, which, while paginated, is not limited by date. In order to be performant, we need to make sure that determining whether a group of orders are complete is a fast operation (so likely stored somewhere and not calculated on the fly). (And assumedly the same would be required for the other statuses, such as “Active” and “Cancelled” )
Beyond just whether an order is complete, we need to calculate and display the refills remaining for display to the user. How does this factor in? Can we just calculate this client-side?
So, lots of questions here, I don’t expect them all to be answered on this thread, but wanted to get the discussion going.
While the primary purpose of TAC calls is for technical leads across orgs to coordinate & strategize, we aren’t making full use of the call, so it would be a fine place to kick off and have some/all of the discussion. If we have competing agenda items and you need more time for this project, then you could book some time on design calls or come up with another call as needed. Talk can be useful both to document/publicize the discussion and move it forward between calls. Alternatively, you could use Talk and target ad hoc calls when specific topic(s) need the bandwidth of a real time conversation.
Unlike test orders, drug orders don’t really lend themselves to a “completed” status, since this is only non-ambiguous for the portion of drugs that are given for a finite course – i.e., the administration of the entire course of the drug has been completed. Many HIV and NCD drugs are prescribed indefinitely, in which case “completed” is ambiguous (leading to several of your questions). For ordering providers, it’s more useful and avoids ambiguity to summarize dispense events for each drug order.
For dispensing, I would assume “Completed” refers to the pharmacists workflow – i.e., all work for this order has been done (at least for now).
I would have the same assumption, but not that the “Order” is complete, but all pending dispensing events have been completed.
Marking a medication order as “complete” is ambiguous in all but the simplest use cases. I would favor making it easy to review the dispensing activity for any medication (e.g., optionally expand dispensing information beneath an order). If we want to try to summarize dispensing (as an estimate of administration or adherence), we’d need an implementation-adjustable algorithm that provides a confidence score (not a boolean).
Agreed. Perhaps the interface(s) to request dispensing information for an order could (eventually) be in core, but the implementation of dispensing business would be in the purview of pharmacy system.
Yeah, thanks @burke … I generally agree with your points, but am struggling a bit with this, because I think the fundamental problem is we trying to build an (albeit simplified) dispensing workflow using only the OpenMRS / FHIR data module.
@pauladams@ddesimone it would be good to get a better idea of what “Completed” means in terms of the screen designs. And perhaps more controversially, do you think, for MVP, we could potentially punt the “Completed” logic to version 2 or later? Looking at the screen designs, it looks like with would have two main impacts:
We wouldn’t be able to filter based on Complete.
There would be no “Complete” status (likely the two valid statuses would be active and expired)
What would people think about, at least for Phase 1, only having three tabs: “Active prescription”, “Stopped/Expired Prescriptions” (could come up with better verbiage) and “All Prescriptions”? (side note, I think “Active” would be the default tab, and “All” might not be needed at all). “Completed” (and “Return to Prescriber”, but that can be a separate discussion) would be future features.
Note that we would have the “history” tab in Phase 1, so a pharmacist would be able to view all the dispensing events related to an order, we’d just not be trying to come up complicated logic to calculate and/or store whether an order is “complete”, and leave that to the pharmacist to determine.
I think the key distinction here is that what @mogoodrich is asking is about marking an order as having been completely dispensed from the perspective of the pharmacy, so it no longer appears on a work list of medications outstanding to dispense.
Maybe the easiest thing as a first pass is to make this an explicit step - the pharmacist needs to actually indicate that this order has been completely fulfilled, by essentially recording the fulfiller status.
I do think that this entire notion in the UI needs to be reconsidered as far as workflows are concerned - is there really a valid use case where you’d want to have a tab that shows all orders since the beginning of time? or all orders that had been completely dispensed since the beginning of time?
I defer to those who have done the user research and requirements gathering, but would have speculated that there are really a few generic “lists” that are likely useful:
Medication orders that we expect we need to fill that day (orders for patients who have an active visit, or potentially orders for patients who are scheduled to pick up medications that day but don’t yet have an active visit). There might be overlap with this and the support for patient queues. The use case being to support quickly filling and dispensing medications off of a work list.
Recently dispensed medications (eg. all medication dispensing events today or some subset of today). The use case being able to quickly go back and fix an error or make a change to a dispensing record recently entered.
Beyond that, I’d think that anything further would be done through a workflow in which the first step is a patient search, and once the correct patient was found, the user would be presented with their drug orders.
And anything that requires analysis of medication ordering and dispensing would be handled in separate reporting or programmatic dashboard workflows.
I had this thought to, but it strikes me that there’s an ambiguity with prescriptions for which there are outstanding refills. Basically, the current “dispense” is done (and so shouldn’t be in the “Active” list), but the prescription itself is still valid and presumably can be dispensed against.
I’m starting to think that the flow here should be something like:
Initial order comes in → MedicationDispense created → Medication dispensed and the MedicationDispense is marked as complete. Patient with active script returns to pharmacy → Pharmacist looks up list of patient’s scripts and creates a MedicationDispense if the patient has an active script → Medication dispensed and new MedicationDispense is marked as complete.
In this case, “Complete” would be something like the completed MedicationDispenses rather than trying to pin this to the order somehow. I’d also suggest that “Active Prescription” should really indicate “there is a pending MedicationDispense against a prescription” rather than just “all non-expired prescriptions”.
From that perspective, we could come up with, e.g., a backend task or something to automate the creation of MedicationDispenses, but we’d also have a manual process.
I’m not sure I 100% follow @ibacher . I think it’ll depend on how the Pharmacy screen designs and use cases evolve from here a bit. Can we not just make an assumption that 1 drug order should correspond to 1 dispense for the original order + 1 dispense for each refill? So a given order would be available for dispensing if the following are true:
The order has a status of Active (not discontinued, voided, expired)
The number of dispensing records associated with the order < (1+numRefills)
If necessary, some indication of whether a certain period of time needs to pass prior to refill
Might be worth breakingin this up into separate threads as I don’t want to derail the conversation in the previous two posts, but I wanted to flag the following previous quote from @mseaton for further discussion with @pauladams (and alsod @ddesimone@eudson@pirupius@grace ) as it could imply a potentially significant reworking of the screen designs:
Note that the current worklist (shown below) it not limited by date, and contains some derived parameters (last dispenser,status) so even with pagination would be an very expensive query and almost certainly involve some custom, optimized endpoints. I know I’m rehashing something we designed and reviewed months ago, but it might be worth at least quickly reviewing (or at least making sure we understand it properly) before digging into designing the search query. Having a more targeted worklist, or doing a patient search first before retrieving orders, would likely be much easier from a performance perspective.
Refers to a single orderable. This can be a test, a referral, a drug, or another order type. For the pharmacy system, we are only concerned with Drugs Orders. A drug order always refers to a single medication order.
Encounter
A collection of orders, notes, observations, etc. during a single clinical transaction. An encounter can contain 0…n orders and they can be of different types (not just drug orders).
Prescription
For the pharmacy system, a “prescription” can contain multiple drug orders – i.e., a prescription represents one or more drugs ordered by the provider to be dispensed.
Dispensing event
The record of a single episode of an individual medication (e.g., corresponding to a drug order) being given to the patient (fill or refill).
Using these definitions, I’m assuming:
The “Completed” status we’re talking about is really talking about Prescription completion (not Order completion).
The source for prescriptions is encounters with one or more drug orders.
Pharmacy dispensing is backed by a dispensing table, where dispensing events are created for each drug orders, which would include links to patient, order, and encounter along with a status, making it relatively quick (via indexing) to filter dispensing events by patient, prescription (encounter), and/or status of dispensing events.
Or what about:
Initial order comes in → All MedicationDispense events created (e.g., an order for Foobarcillin #90 tablets with 2 refills creates 3 MedicationDispense events only the first of which is “due”) → Medication dispensed and the first MedicationDispense is marked as complete, leaving any future dispense events for future refills.
So, assuming “future” dispense events (events generated for future refills) can be easily filtered out by an effective/start date timestamp, the list of outstanding (incomplete) prescriptions would be all pending dispense events grouped by encounter.
Yes, this is all correct (or at least matches what we have been designing around
I like this idea. Presumably implementations could then choose to add on logic to determine at what point these PENDING MedicationDispense records would be transitioned to EXPIRED or another status (similar to how there are different approaches to auto-closing active visits after certain criteria are met). Not sure if there are standards around this?
Yes, with the caveat that we are hoping we can use the OpenMRS “Medication Dispense” table (based on the FHIR Medication Dispense type) which might not be 100% in line with what would be expected in a pharmacy system dispensing table?
Hmmm… I could see how this could help us, but it also smells a bit to me, assuming I’m understanding it right?
We are building a Dispensing ESM whose use case is primarily for Pharmacists to view orders and record dispensing events. To implement the design above, I’d see us creating a Dispensing OMOD to back the ESM that has a listener that listened for all saving of Drug Orders, and when they come through, creates and saves corresponding Medication Dispense objects in the medication dispensing table with a status PENDING. Is that what others were thinking? It smells a bit (and seems potentially confusing/cluttered) to automatically create these entries at order time. But again, I do see how it could be helpful because it would make it easier to do lookups based on status.
I’m hoping we can keep it as simple as possible, and just create the Medication Dispense objects when an actual dispensation occurs.
Sure. The scope of an OpenMRS “drug_dispense” table would be to represent any dispensing information that would be useful to show providers (dispensing events linked to patient, drug order, encounter), which should align with (all or a subset of properties of) FHIR’s MedicationDispense resource. Any pharmacy business needs outside the scope of an EMR (e.g., inventory management, assignment of dispensing work to individual pharmacists, etc.) would be in the purview of the pharmacy module (i.e., in separate pharmacy module-specific tables/APIs).
That’s fine. The notion of pre-creating anticipated dispense events arose as I was thinking through the process of how the pharmacy module’s workflow would anticipate dispensing needs (i.e., who might be coming through the door next) without creating it’s own copy of the encounter table (which would stink even worse). If there’s no requirement to anticipate dispensing events (e.g., prepare prescriptions before the patient shows up) for now and just handling dispensing events patient-by-patient meets current needs, then maybe we don’t need to worry about it. But, it’s not hard to imagine a pharmacy wanting to prepare prescriptions before the patient asks for it.
