Marking a Lab order as "Urgent" in Bahmni

There is a column which is neither mapped in hibernate nor used anywhere in the system. Hence, we can just use this unused field which will suffice our current requirement.

Actually its probably little more complicated that.

  1. right now bahmni creates accessions when it processes “lab order” from encounters and correlates that by “encounter uuid” (long history involved!)
  1. This “encounter uuid” finds it reference in openelis in “sample.uuid”. This means as it stands it is not possible to split up orders in an encounter into multiple “accession” records in ELIS.
  2. When results are published, EMR side, the same uuid field is used to identify which encounter and from it which orders must the results be associated with.

So, lets think of what we can do

  1. Option 1: We can split up the lab orders by sample type and priority.
  • Blood: RBC (urgent), WBC, Hemoglobin => 2 samples. Sample1 => RBC, Sample 2 => WBC & Hemoglobin.
  • This will need to be verified with the lab process. This will work only if the lab would draw different samples. If 2 tests of the same sample type are marked as urgent, then we can create 1 accession for the priority grouped tests of the same sample type. Note: this is because the priority is at the level of the “accession”.
  • We can not do this yet, as the code now correlates “accession” (sample_item in ELIS for multiple samples tests) by the encounter uuid.
  1. Option 2: If its just about figuring out which “test” in the accession, then maybe we can do something to mark/highlight which of the tests in the accession is of top priority. OpenELIS does not have this provision yet. We can possibly extend the “analysis” table, which is used for every tests relevant to a drawn sample.

So, in general, what do we want?

  1. Segregate by priority and sample type? - will require drawing sample multiple times.
  2. Keep within the same accession but indicate which of the test is priority.

I doubt the answer is simple. As with option 2, it still means that the sample is drawn and to be used for other tests just one of them is done on priority - this will not work, if the lab decides to draw only sample for immediate tests and ask the patient to come back later for the others.

There is some technical issues as I described above. To resolve this and to make sure that things on the EMR side will work no matter how the LAB process is

  1. We should keep the correlation by the “order id” not the encounter id.
  2. Refactor our code
1 Like

I see why I didn’t find that


If we do go this route, we should of course expose this via Hibernate.

Option 2 sounds better to me. If we want to minimise the changes we want to do in elis and if there is no requirement to have reports and analysis around high priority tests from elis, and the objective is to communicate to the lab technician, then high priority tests can be communicated through Notes on accession.

So basically mark the accession as high priority if at least one test is high priority and prepend in notes high priority tests.

For PSI we have implemented in same way. When we mark the order as urgent in Bahmni and this information is send to OpenELIS using notes. We have not marked the accession as high priority in ELIS.

The requirement was to see this urgent orders on ELIS for lab tech to prioritize urgent tests over others. PSI generates a report at the end of the month for lab orders which are marked as urgent. We are doing this report as custom SQL from Bahmni rather than ELIS.

Below are the snapshots for your reference:

MCH and HCT are marked as urgent in Bahmni

Notes column showing urgent info on sample collection page:

Notes column showing urgent info on sample collected page:

Hi,

After the discussion with Angshu, we had come to a solution from the functionality point of view as below:

  1. If a test is high Priority in the lab order then only the sample to which lab test belongs to, will become high priority not the entire order in OpenElis.
  2. And even if any of the test is not of high priority entire lab order is divided into samples(In OpenElis lab dashboard you would see one row for each sample). In this way we are solving two problems:
  3. Whenever a test is high priority, entire lab order need not be priority(Which means that for the remaining tests lab technician can collect the sample little later)
  4. Even for the remaining orders, lab technician doesn’t need to collect all the samples at a time.

From technical side, the changes will be:

  1. In EMR whenever a lab test is ordered an order ID will be generated(This is already there in EMR).
  2. When an order is syncing to Elis, we will be syncing Order ID as well.
  3. When results are syncing back from Elis to EMR, they are updated based on encounter uuid. Going forward results will be updated based on Order ID.

Pre requisite: Before rolling out this feature, all the patient results has to be synced to back to EMR, there should not be any awaiting patients in Elis.

2 Likes

Hi @padmavati,

I see the ticket Sync “Priority” of Lab orders to ELIS. can we expect this to be completed in 0.91 ? and also does this ticket scopes the work for color coding for visual indication of priorities in openelis? please let us know as for "Possible" this is marked as urgent requirement from our hospitals as well.

Hi @laxman

We are still in the development phase, so we might not be raising the pull request for 0.91. However we will raising the pull request in 0.92 version of Bahmni.

1 Like

Hi,

More details on the above solution approach with examples.

Assumptions:

1.Lab order will be splitted based on Sample types. 2. If any of the test is of high priority the entire sample is of high priority, which means that for the tests which is of high priority and for the test which is of low priority the sample will be collected at the same time.

Lab order: Eg: Sang - CD4(IPD), Haemoglobine(High priority) Urine - Protiens and Nitrites (High priority)

Solution: Lab order will be divided based on Sample type: Sang Urine Option1: Since one test from each sample is of high priority, the entire sample will become high priority. So it will generate two accessions but separated by sample types (unlike before). Option 2: We split out the tests of high priority into different accession Accession 1: Sang - having test(s) Haemoglobin Accession 2: Urine - having test(s) Nitrites Accession 3: Sang - CD4 Urine - Protien

What we heard from different implementations is even though only one test is of high priority in a sample, lab technicians will collect the sample at a time and distribute it to different tubes(to store the sample). So OPD/IPD patients will not come back to Lab to give the same sample for multiple times. So we are planning to go ahead with Option1.

Please let us know if you have any feedback.

Hi @padmavati,

If you display multiple row depends on Sample Type for a single patient, wouldn’t it be too much for dashboard? Currently, we are displaying one row per patient but after this changes there will be multiple row for a single patient. Lets say, lab user has to collect n number of sample for one patient, there will be n number of row on UI(dashboard). I feel this will the hit performance (loading time of dashboard).

Thoughts @angshuonline, @darius

Actually, it can get even more complex. (I am switching to english for the examples)

  • Blood - CD4, Hemoglobin (priority)
  • Urine - Protiens, Nitrites (priority)

Option 1: One test from each sample type is of priority, the entire sample will become high priority and different accessions would be created with the accessions marked as priority. (like Padma said above)

  • Accession 1 (priority): Blood - CD4, Hemoglobin
  • Accession 2 (priority): Urine - Protiens, Nitrites

Option 2: Split out the tests of priority into different accessions

  • Accession 1 (priority): Blood - Hemoglobin
  • Accession 2 (priority): Urine - Nitrites
  • Accession 3 (routine) consisting of 2 sample types: Blood - CD4, Urine - Protien

Option 2 is useful if the lab process is such that priority test samples are drawn separately. Meaning for the other non-priority tests, samples are drawn separately either then or later.

NOTE: To me, both the above options are both valid, depending on what the lab follows. In any case, we will have to introduce strategies for such accession creation in OpenELIS to support such modes of working.

Thoughts?

I agree that multiple workflows are valid, and we can’t decide ahead of time what all laboratories will actually do.

To try to keep the dev work here constrained we can assume (I hope this is safe!) that any one lab uses one particular approach at a time.

So +1 to using the Strategy pattern. (I think it’s sufficient to implement just one strategy, i.e. the one needed by your particular implementation, as long as you document how someone else can add another strategy in the future.)

I have raised a PR with option 1, here is the PR link

2 Likes

Thanks a lot @mahitha

This is the relevant card https://bahmni.atlassian.net/browse/BAH-457 I am assuming that the PR addresses the Option 1 strategy?

1 Like

yes, it is with Option 1 strategy.

1 Like

Thanks @mahitha, we(Possible team) were actually planning for this implementation. Afterall its done we can surely help with the review.