Marking a Lab order as "Urgent" in Bahmni

In PSI Zimbabwe implementation we have a requirement where the Lab orders need to be marked as Urgent. This will be used by the lab techs to prioritize the lab orders accordingly. The Lab orders marked as urgent are also reported in the monthly report which is submitted to the Ministry of health.

When we explored Bahmni orders tab, we came across the functionality which is available for Radiology Order, where the provider can mark an order as urgent. Mingle card link : . We are also looking for similar functionality for Lab orders.

@angshuonline @sruti @binduak @shruthipitta @mksd @darius We are looking forward for your suggestions on this.

(The Mingle card is not public.)

I think there are two angles to this: 1) the technical and 2) the functional.

  • If this is done for radiology orders already then I shall assume that there is appropriate room in the data model to mark an order as urgent (here as it seems), and that whatever was done there could be done here as well.
    It would be useful to dig in an point us, in Bahmni Apps and elsewhere, to the place(s) where this urgency is consumed for radiology orders.

  • Obviously OpenELIS must support this, this is also to be investigated.

  • From a functional point of view it would be great to validate that all is fine from a medical standpoint. Again the fact that the data model allows it suggests that this is indeed the case. However only some urgency values seem to be allowed, modifying/extending the set might be require consensus. @jteich?

@rdeolal, @sruti can you move the card to JIRA please?

I think it will be good to have this feature. Even without the nuances of urgency values, it will be good to have them show up at top of the list. For example, for radiology orders that what happens. In ELIS, I would think - just fetching the list and sorting by priority in “to be collected sample” and “samples collected” lists, would be good starting point.

In my view, this can be done fairly quickly and easily.

I agree that this is good have for lab orders too. @angshuonline They want this to be a part of 0.90. @rdeolal Please confirm.

Yes that’s right. We want it to be a part Bahmni V0.90. Our first release is scheduled for Feb 21st. We want this feature to be part of this release.

This is a potential problem: the underlying OpenMRS platform doesn’t exactly support “urgent”. FHIR models the request priorities in increasing order as routine, urgent, asap, and stat, but in OpenMRS we currently only support the first and last. As a quick hack we could use “stat” in place of “urgent”, though it’s intended to mean “The request should be actioned immediately - highest possible priority. E.g. an emergency”.

@burke, @jteich, what do you think about adding some additional Order.urgency levels in OpenMRS core? (Currently we just support: ROUTINE, STAT, ON_SCHEDULED_DATE.)

To get this into v0.90 we would either need to do the quick hack mentioned above (use “stat” to mean just “urgent”) or else we’d need to:

  1. make this (tiny) change in openmrs-core
  2. do a maintenance release of openmrs-core
  3. make an 0.90 patch release that depends on openmrs-core 2.1.3

(As to the business requirement, yes, it’s definitely part of medical practice to be able to request lab tests, or orders in general, with different levels of priority. OpenMRS might want to have a short discussion to set a consensus on this, but I would expect that we’d definitely want to add “urgent”, and we’d probably also add “asap”, to match the FHIR consensus.)

Thank you @darius for the information on the FHIR standards of order priorities.

For the current use case I think using Routine and STAT might suffice. (@rdeolal can you please confirm that?)
It would be better to introduce the other priorities of “Urgent” and “asap” as a part of 0 .91. Because we are currently on openmrs-core 2.1.1 and upgrading to 2.1.3 might be a significant change for the patch 0.90 release I believe. @shruthipitta Can you confirm if bringing the new priorities later in 0.91, wouldn’t affect the current way @rdeolal 's team would choose to implement it?

Tagging @shilpab and @dreddy who were looking for a similar levels of priorities for their lab orders.

Link to Jira Card :

Whats the use case of “ON_SCHEDULED_DATE”? In what cases be it different from “ROUTINE”?

For PSI having “Routine” and “STAT” will suffice our need. And we will be ok to have other priorities to be made available in later version of Bahmni.

We did a small spike. When we setup the urgent button for Lab order we are able to see the “STAT” value present for “urgency” property in the atom feed.

We are not sure if currently OpenELIS is consuming this information to mark the orders as STAT.

We need your advise on how to take it forward in OpenELIS on below items.

  1. How to read from atomfeed and where to store this information.
  2. What all UI changes we are looking in OpenELIS.

We will be adding urgent button for Lab orders similar to Radiology orders. We will make this button as configurable for the implementation.

Currently we are not be doing any changes in OpenELIS to display and sort on urgency information.

For the lab tech to see information, we will be passing the information through notes. Whenever the provider clicks on “Urgent” button and on save of encounter we will append “Urgent” keyword in the notes. This change will be part of the custom OMOD.

Why custom OMOD? Or did you mean on the ELIS side sync client code?

Angshu we will not be making any changes to ELIS side sync code. We will be using the Notes to pass this information in ELIS. For doing this we will be writing implementation specific OMOD. This OMOD will create a note “Urgent” in OpenMRS when the user clicks on Urgent button.

@rdeolal you could add this to Bahmni Core, or perhaps even into EMR API. I would imagine that other implementations could benefit from such a development.

I think FHIR has overdone it on this one with routine/urgent/asap/stat… I suppose urgent might mean ‘put this on top of everything in the routine queue, we need it very soon’ and stat might mean ‘do it right now’, but I doubt that many labs, or many clinicians, would make a distinction. Even in busy US labs, you send things routine or stat and that’s about it. I would only recommend adding the urgent and asap categories if we need to support other incoming systems that may use them; I would not recommend adding them to our UI.

Technically, labs have two time elements: when you want the lab drawn and how fast you want it processed. The typical example is “when patient comes out of the operating room, get a stat hemoglobin”. In other words, the operation might be tomorrow morning, but I want to know the patient’s hemoglobin level as soon as possible after the operation is done, because there might be a lot of blood loss in surgery.

Oddly, I don’t see a “time to do the order” in FHIR Diagnostic Order (although there is one in the Order resource). There are timed events in the Diagnostic Order, but nothing that singles out doing the test itself as a special event.

I agree a spectrum of “urgent/asap” is overkill and unlikely to have widespread agreement; however, there is utility of having something sitting between routine and stat.

routine means “prioritize this as you normally would”


stat means “drop everything (interrupt your current work) and do this immediately” (just shy of running down the hallway screaming “OMG, if you don’t do this immediately someone is going to die!”)

There are many cases where you want something to be prioritized (higher than routine), but it’s not so critical that all work must be stopped so it can be addressed immediately. I could easily see OpenMRS adopting urgent as the middle-ground – i.e.,

urgent means “make this a high priority, but you are not required to interrupt your current task”

So, I would support adopting routine/urgent/stat within OpenMRS core (i.e., three buckets of prioritization equivalent to normal priority, high priority, and top priority). While most clinicians & labs may be fine with routine and stat, supporting urgent, when adopted, would help allow stat to be reserved for only those things that truly deserve to be stat.

1 Like

I believe DiagnosticOrder was removed. In STU3, I think the timing of the order is in ProcedureRequest.occurence.

I agree ON_SCHEDULED_DATE here is conflating urgency and timing. Ideally, we – like FHIR – would treat these separately and our timing would allow for event-driven timing (e.g., when the patient gets admitted) along with a specific date or time to schedule the task. So, I’d be fine with deprecating ON_SCHEDULED_DATE as a value for urgency.

@mksd : Do you want the notes part to be included in the Bahmni Core / API instead of writing a separate OMOD. Our idea is when provider clicks on “STAT” button a note will be passed to ELIS. So getting “STAT” button and making it configurable we will do it on Bahmni Apps. But passing the Notes which is the second part, we were thinking of doing it as separate OMOD. Currently Bahmni allows to sync the notes from MRS to ELIS. We will be justing using it to display “Urgent” on ELIS, which will be incorporated in separate OMOD.

Do you want us to do the second part in the Core/API itself ?

Yes as a general matter of fact I am not in favour of yet another OMOD. Especially for a fairly small piece of work that could be hold by at least two modules that are part of the Bahmni distro (Bahmni Core and EMR API). Could you outline in more details here what this REST API would do?

I am also more in favour of EMR API vs Bahmni Core, as again, the former is included in a larger number of distributions. Keep in mind that I’m saying this in oblivion of the details.

We will do code changes only in bahmni core. Will use EncounterPreSaveCommand to do this.

Great, please could you create JIRA ticket for this and report a link to it here? In the description it would be helpful to others if you could provide technical details such as:

  • A clear description of the feature, or at the very least a link to the current Talk thread.
  • Components/modules/projects that will be touched (look at the ‘Component/s’ section of the JIRA ticket as well).
  • Most important: GitHub pointers to the places where you envision that the code changes will happen.