This is the link to JIRA ticket: https://bahmni.atlassian.net/browse/BAH-450
1 Like
@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.
@sruti, @mahitha I see that in the JIRA ticket it says
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.
Thanks @darius.
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
Hi @mahitha,
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.