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 : https://bahmni.mingle.thoughtworks.com/projects/bahmni_emr/cards/2284 .
We are also looking for similar functionality for Lab orders.
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?
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.
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:
make this (tiny) change in openmrs-core
do a maintenance release of openmrs-core
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.
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.
How to read from atomfeed and where to store this information.
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.
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ā
and
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.
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.
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.