(Default) workflow between OpenMRS and OpenELIS

Now that my OpenMRS and OpenELIS talk to each other, I need to figure out how they could be integrated into our clinic.

This is my current understanding of the process/data flow so far:

  1. Bahmni: Create Lab Order from patient consultation page
  2. OpenELIS: Collect sample for this order
  3. OpenELIS: Run test and enter result
  4. OpenELIS: Validate result
  5. Bahmni: Result shows up on patient dashboard

Are there any additional confirmation and notification steps included or configurable?

While the above flow makes sense, it requires the clinical provider to explicitly poll the dashboard and scan for new results. In settings where the lab workflow itself can be ‘unpredictable’ (nobody collected the sample, no lab technician available, no power, no materials at the lab, broken machines), tests can take an unknown amount of time and when the result is finally there, nobody might take notice anymore.

Not sure how a reasonable solution for us would look like though, so I’m just starting my though process with this here and want to see if some of you already have some initial feedback.

Hi @cine,

In our hospital implementation, this system process is supplemented by an out of system process to manage patient queue. Clinical providers only open patient dashboard (to check test results) when they are consulting them. And patients go to consultation room only when their test results are entered in the system.

An alerting system built into Bahmni might still be useful.

Thanks,

I see, thanks Vinkesh.

On bahmnis main page, there is an orders module/app. In my installation it seems to refer to radiology orders only. Not sure how it could look like though, but is there a way to handle lab orders and returning results to make them show up there too? This way I might have a way to handle the patient queue in a simplistic way within bahmni.

And alerting would indeed be nice. And same could be said for a kind of confirmation of results. Ideally I could bring the delivery of result as close as possible to a clinical action based on this result. And make sure that someone handled accordingly - e.g. in the way that the clinical provider confirms that he/she saw the result.

Hi @cine,

We can configure orders app to show Lab Orders also, but i am not sure if it will help in patient queue.

Orders app is useful for Order fulfillment. Example workflow can be -

  • Doctor orders a radiology order in clinical app.
  • Radiologist can lookup for the patient in Order app’s queue.
  • After order is fulfilled in physical world, data can be entered in Observation Template configured for that order type in Order app.
  • Doctors can view the result in patient’s dashboard.

Please check https://bahmni.atlassian.net/wiki/display/BAH/Order+Fulfilment for configuring order fulfillment.

Thanks,

Hi All,

Bahmni OpenELIS Overview (Online session on 28-Jan-2016) https://www.youtube.com/watch?v=r3Pd0DDIRbM - great stuff there guys, kudos !!!

After watching the video, I was experimenting with the flow of data/information between Bahmni and OpenELIS and realized that in OpenELIS, when you create tests & panels, atom feed does not send it to Bahmni automatically. A corresponding concept set must be created in OpenMRS for the linkage to be complete as rightly indicated in the video.

However, in response to a question that was asked, regarding what data flows back to OpenMRS, I think we may want to look at the video time range, (39:27 to 40:15) https://youtu.be/r3Pd0DDIRbM?t=39m27s, again because apart from lab order results and associated attributes (abnormal or within normal range) which flows back to Bahmni, below also holds true.

When you add sample from a patient in OpenELIS and that same patient already exists in Bahmni, atom feed springs into action, sends that information back to Bahmni and initiates a visit as well as open an encounter for the patient in question, as though a provider placed a lab order from Bahmni.

1 Like

Thanks a lot Ekow! Glad you liked the video.

In general the rule is that if any “master data” entity that doesn’t exist in OpenMRS, then data related to that entity doesn’t go from OpenELIS to OpenMRS. For instance, if you create a new test in OpenELIS, but the “concepts” aren’t existing in OpenMRS, then sych won’t happen for that test, since OpenMRS does not know about the existence of the entity.

Hence we clarified in the video, that adding patients, tests, panels, and any such “setup” data, should always be done in OpenMRS, so that the configuration also flows into OpenELIS. After that any results, or samples recorded against these existing entities in OpenELIS, will flow back into OpenMRS, as long as OpenMRS has an entity to connect this data to.

I hope my explanation (and understanding) is clear. Is this your understanding too now? cc: @sravanthi17 @prabhuawasthi @vinay

Thanks Gurpreet!

Excellent explanation Gurpreet, & yes that’s my understanding too.

However, the only puzzling bit is the way a visit & associated encounter is initiated in OpenMRS at the instance of OpenELIS posting a result back to Bahmni, when such visit & encounter was not processed thru Bahmni.

Per my understanding, as long as the entity concerned (say patient) was created & exists in OpenMRS same entity is created in OpenELIS. I can understand if a seeing authorised medical personnel attends to a patient via the Bahmni UI and lab requests are sent to OpenELIS so that the corresponding results are sent back to OpenMRS.

But where no such visit & associated encounter has been started from the Bahmni front-end but by virtue of the fact that the entity (in this case patient & assigned lab tests) exist in OpenELIS and on that score that can initiate such visit & associated encounter backwards into OpenMRS is my concern here.

With the way it’s operating now, it invariably means that lab technicians using OpenELIS can actually start a visit in OpenMRS by simply selecting any patient and assigning some lab requests to them in OpenELIS. I think that should not be possible as it can lead to ambiguities in the very near future.

Thanks again Gurpreet!

@ekowkoomson1 - This was done to account for variations in workflow that happen in the hospital. Some usecases where it have been useful are.

  1. Patient just needs to walk into a lab to do a fasting blood sugar before the day’s OPD starts, instead of visiting the doctor one day earlier, and requesting a lab order.
  2. Order was made and sample collected outside the hospital (outreach clinics, for example) in paper, samples were collected at that point and brought to the lab.

With regards to visits created, they are marked by a specific visit type, that can be used to distinguish from other visits.

Can you explain more about the ambiguities that can arise out of lab technicians creating a visit?