"Order Tracking" OWA/module

[burke (Burke Mamlin)]

@mogoodrich

The key (and perhaps only) domain model change for this would be adding an “Order Status” to an “Order”. Exactly how this would work is TBA but it seems likely it might need to be added as a separate domain object since Orders are immutable. Order Status would has a set of states like"Ordered", “Pending”, and “Reported” (names certainly could be tweaked).

In our original design for the order service, we included an order status that was meant to track orders through a workflow, but the design was overly complex, preventing some organizations from adopting it, and we ended up stripping out features to get an order entry service in version 1.10 that everyone was willing to adopt. (@darius, remember 2012? LOL )

I would be in favor of adding orders.order_status to align with FHIR’s MedicationRequest.status, ProcedureRequest.status, NutritionOrder.status, etc. Ultimately, this could be used to track orders from draft to activated to completed.

One of the tricky bits will be approaching order status in a way that is “future proof.” Do we need to fully model all possible states up front? Or can we design in a way that can tolerate new states later without breaking all existing code? For example, if you make a service method to get all “ordered” labs, will it break if a status of “draft” or “active” is added later? Encapsulating interpretation of the order status within a service layer might be a way to handle this.

The various order status fields in FHIR should allow us to distinguish active vs. completed orders and, when we’re ready for it, draft orders. We don’t need to introduce them now, but I would favor approaching order status in a way that could also accommodate common workflows in the future. Some examples from my own experience:

• received - The request has been received (e.g., nurse acknowledged the order, lab received the specimen, pharmacy acknowledging a script)
• draft - The request has been created but is not yet complete or ready for action
• needs cosign - The request is ready but should not be acted upon (marked “active”) until cosigned

@mogoodrich

Does this seem like functionality that would generally be build into an EMR? Or is even this level of functionality generally provided by a LIMS?

Tracking specimens and generating results are LIMS. It’s perfectly acceptable to do these in a module. When/if enterprise lab features are needed (running controls, tracking data about specimens or workflow that are not patient-centric, etc.), then integrating with a separate LIMS makes more sense.

A couple additional thoughts on order tracking:

• The order tracking features you describe seem to be focused primarily on test (specifically lab) orders. It might be worth considering how/if order tracking might apply to other types of orders (referrals, nursing orders, activity orders, prescriptions), since it could affect your design choices (e.g., instead of hardcoding lab result entry into an order tracker, have link/button that jumps to the appropriate page to enter a “result”… the first implementation jumps to a lab result entry form for lab orders, but a referral order might jump to a different form and a medication order might jump to an drug administration tool).

• Your approach applies to a lab workflow wanting to queue orders and facilitate entry of results (connected to and “completing” orders) across patients; however, another common & related workflow is for nursing to see a patient-specific queue of outstanding orders for a given patient (i.e., a patient-specific task list). Perhaps that deserves a separate module/addon, but since it’s closely related and would also depend on and affect order status, I thought I’d mention it.

@mseaton

Thanks @wyclif, makes sense. Question would be whether we want to be able to track this status over time in OpenMRS, which would have a more complicated OrderState object with startDate and endDate. This might complicate things more than needed though.

My instinct would be:

• Add this as orders.status (aligning with FHIR) as a mutable property of an order. We can log changes to order status for now.
• Encapsulate interpretation of raw status values within the service rather than just emitting raw data and expecting clients to interpret the values consistently.

@mogoodrich

@jthomas can we schedule a design call around this? Is there formal process to request that beyond posting here?

If you want to schedule a design forum, browse to Propose a Design Forum Topic - Development - OpenMRS Talk to request design time.