This is the link to JIRA ticket: https://bahmni.atlassian.net/browse/BAH-450
@jteich - that was my understanding of stat. However, I am not sure if I still understand the different between “ON_SCHEDULED_DATE” and “ROUTINE” status that OpenMRS support but “ON_SCHEDULED_DATE” is not listed in FHIR.
Upon investigation, we discovered when the patient goes to LAB and gets a sample drawn, and when this syncs to EMR, we create an “ON_SCHEDULED_DATE” status for the order that we create. I am not sure if this is meant for such scenarios.
I am not in favor of another OMOD, and unsure about adding that to comment, as doctors can add comment for a test and you shouldn’t be replacing that. You may append URGENT. Please take care to internationlize
We will not be replacing any notes that are added by providers. We will append ‘Urgent’ text to the notes. We are doing similar changes whatever we have done for Radiology Orders.
Btw, I am saying “appending” texts reluctantly. The correct way to solve this is support it as per domain model. FYI, ELIS “sample” already has a “priority” column, which is for this purpose only.
I agree with Angshu that ‘priority’ attribute should be treated first class rather than mixing it with comment.
i remember that the print was being appended to comment and that was done because the domain model lacked support for it on openmrs, PACS and modality side. However, the use of print and priority is very different. For a fulfiller, It’s ok to look at whether result has to be printed, at the time of working with the line item and so having it part of comment suffices but for priority an ability to have it as a separate column and sort it by that column is very desirable, otherwise the user will have to keep searching for high priority/stat orders which is impractical/error prone. As far as i remember (i worked on it but it’s been a while) All openmrs, PACS and modality had support for priority, quite understanbly so, and so priority is being sent as a separate field to PACS and displayed in a separate column on modality. In ELIS also as Angshu mentions, sample has a priority column and so we should use that.
+10 to this. Before making a core Bahmni change to append “urgent” to the comment (hacky!), please do a minimal amount of investigation about whether you can use the OpenELIS sample.priority column. (And if that doesn’t work, why not?)
The original intentions for the current urgency values in OpenMRS core are:
- ROUTINE: do this now, with normal priority
- STAT: do this now, with priority priority
- ON_SCHEDULED_DATE: do this in the future, on the date in the Order.scheduledDate field.
- specific scenario: “do a CBC now, and then do another one in 2 weeks”
- we assumed we’d eventually add a value like ON_CONDITION_MET, but never designed this
As Burke and Jonathan say, we should deprecate ON_SCHEDULED_DATE because it’s orthogonal to urgency. If Order.scheduledDate is filled out, that implies the order is to be carried out at (approximately) that time, but it could still be routine vs stat.
Are you saying that we modify the urgency of an existing order to ON_SCHEDULED_DATE after the sample is drawn? That would be wrong from the OpenMRS domain perspective. Or are you saying that when a sample is collected in ELIS that had no corresponding order in the EMR, then we create an order with that status? (In that case I’d say we should use ROUTINE.)
I think we should try using OpenELIS priority column for this as we have it in the domain already. However, I am not sure if this change should be in 0.90.
But if we are taking the route of appending “urgent” to comments column, this is very “implementation specific” solution. So should it really be part of Bahmni core? Shouldn’t it be a part of their OMOD(they have one already)? @angshuonline @darius @mksd
The case I know of this - when a person knows that he needs to get a test done on particular date (as advised by the clinician), and he just heads straight to the LAB (without visiting the doctor first to order a test) and gets his sample taken. In this case you may think of it as “ON_SCHEDULED_DATE”. As of now, from Clinical, we can not order a test to be done with instruction for future date.
As others have said, that would still usually be ROUTINE sample processing by the lab.
Noting your point that we don’t have a way to have a test done at a particular date or time: a separate field for this should actually exist – even if only in text at first – since in acute settings many tests are ordered for the following morning, before or after a procedure (usually STAT), after a scheduled transfusion (likely Urgent or STAT) to see if the blood count was raised satisfactorily, and so on.
Thanks @jteich. I think all the more reason not to use “ON_SCHEDULED_DATE”, as I can’t really see the differentiation and also in case we are exposing/mapping the data through FHIR , we don’t need to break our head with additional values.
Out Of Scope
- Having column to display priorities in OpenELIS
Since it hasn’t been said on this thread, can one of you please clarify, have you verified in OpenELIS that there isn’t already a suitable column in the data model?
I understand that if nothing exists yet, it may be too much work to add it. But if there’s already something we can use, it would be nice to implement this right, rather than via appending text to a comment.
I’m trying to explore OpenELIS code since I don’t have context on it. I will take someone help who has knowledge on it and will update the details in the card once we have clarity.
We have basically breaking this issue into 2 cards/tickets : 1. For getting the “Stat” button on the EMR side for Lab orders 2. Sync this info to ELIS
While the first will be immediately merged with the product and will be available with the 0.90 patch. For the second one, @mahitha is still exploring the openELIS code to do it the right way as you mention. Since they are working against a deadline, should this approach be time consuming, they’d go with the approach of appending the priority with the notes. In which case we will not merge it, and wait till we implement it the right way.
And alternately, if they are able to fix this the right way soon enough for the patch (end of this week), we shall merge it. We will have a separate card for that as it will be a different PR.
Here is a link to the second Jira card. Some details need to be updated yet.
@sruti, this makes sense, thanks for sharing the details.
@mahitha I have emailed a couple of OpenELIS folks to ask how they suggest representing this, and I’ll share anything they tell me.
My understanding of sample table is, it has one row per one encounter. In one encounter we might have more than one order and all are need not to be priority ones. How can we use sample.priority here?
In OpenELIS dashboard, we are displaying one patient per row. That row gives us the details of all orders of one encounter. But we are displaying the comments in dashboard by combining notes from all orders of that encounter. Are we thinking similar structure for priority even? @darius @angshuonline @mksd @shruthipitta @sumanmaity112
I think it’s not a good idea to display all the urgent test order name in the dashboard. As you mentioned one row contains all order of a patient. If a patient has n number of test with multiple tests as Urgent, if you try to display them as CSV on the dashboard it will not be readable (as test names are generally have multiple words with special chars like , ; etc) and the UI of the dashboard will break.
@darius @angshuonline Continuing the discussion on OpenElis side, in OpenElis data model since the priority is at the sample level is it good idea to just display the High priority for the entire order ? And the priority goes like this:
Sample A: test A: Low priority, test B: High priority --> Entire sample is high priority. test A: High priority, test B: Low priority --> Entire sample is high priority. test A: Low priority, test B: Low priority --> Entire sample is low priority. test A: High priority, test B: High priority --> Entire sample is high priority.
@padmavati where does this data point live in OpenELIS? I don’t see the word “priority” anywhere relevant in that codebase…
By the way I asked an old OpenELIS dev at UW about this and he said:
If I remember correctly, [sample priority] was a feature added to the Vietnam implementation of OpenELIS, but it was never incorporated into the main (I-TECH) version. However, I haven’t touched anything OpenELIS related for several years now, so I may easily be mistaken.
Are you talking about how to display this in the OpenELIS dashboard? If priority is stored at the level of the sample, then that’s the level I’d display it in the dashboard…
The word “priority” is not present in the codebase, but there’s a field in sample table with datatype numberic(1,0) indicating we can add priority for that sample. Since, only Routine/STAT data are synced to atomfeed, we can use this to identify Urgent and Low Priority in OpenElis as suggested by @padmavati
@dipakthapa, what field is this?
I’m not familiar with the OpenELIS codebase, so I need more of a pointer than this.