Integration of OpenMRS into generic radiology environments

Dear OpenMRS-Community.

First, I would like to apologize in advance if I missed something in order to make myself familiar by reading the documentation. I did read, but not everything is clear to me.

If possible, I would like to learn how current (2.3.x) and future OpenMRS platform versions together with current (1.5) and future Radiology Module versions are intended to integrate into generic radiology environments (HIS/RIS/PACS/Modality).

The wiki page of the radiology module states that “The module has not yet been officially released”, but addons openmrs org provides several versions of the module. I would like to know:

  • if the module version 1.5 provided is officially released, if functional extensions provided to OpenMRS by this module version are ready to use or if it is still subject to change?
  • If not ready for use, what the missing pieces are?

Reading this article about the LH-Radiology distribution led me to the assumption that, also for the generic OpenMRS product, from an interoperability perspective, FHIR is now intended to be used to exchange order information and status, diagnostic reports, etc. Is this assumption correct? Currently there is the FHIR Module available on addons openmrs org which I found will be replaced by FHIR Module2.

  • Is the statement made on github regarding Module2 correct?
  • If yes, I would be very happy to get some information about the status and roadmap of the FHIR Module2 and if the radiology use case is considered!?

Last, if not using FHIR or REST API interfaces to add, update, delete orders, when aiming OWA, would the actual Order Entry OWA also be a good candidate to be extended to enter radiology besides laboratory orders?

Many thanks,

Benediktus

1 Like

Thank you Benediktus, good questions. @ibacher have we looked in to radiology use case(s) for FHIR Mod2?

Benediktus, would you mind sharing - what is your use case or clinical situation where you would find this functionality helpful?

1 Like

Dear Grace.

I am working for the interoperability department at Siemens Healthineers. In interoperability testing one relies on different test partners. Saying this, besides using own products, 3rd party products are always beneficial to think outside the box as well as to find integration issues and bugs prior to field deployments. Experience has shown that this is beneficial for both parties.

I have had a look if OpenMRS would be a feasible product, and as we are mainly working in the radiology domain, my questions are pointing in this direction for now.

I am thinking of using OpenMRS as an order placer within demo/test setups. I am uncertain and curious about the messaging approach (HL7 v2 vs. FHIR) since the article linked in my previous post mentioned the move towards FHIR. Also, the status of the Radiology Module is unclear to me.

There are many other aspects we could probably consider with OpenMRS in the future. E.g. use of SMART on FHIR, once it is available.

Thanks for spending your time, best regards,

Benediktus

Hi @bolschok, welcome here! Thanks for your posts.

That’s very exciting, and at @Mekom we will certainly follow this thread and would certainly be happy to collaborate.

In particular this could become part of the OpenMRS 3.0 roadmap:

I am thinking of using OpenMRS as an order placer within demo/test setups.

We haven’t yet as it hasn’t come up, but we definitely do want to add this functionality at some point. I’m happy to work with anyone on adding this functionality to the FHIR module.

Thanks for your replies.

Special thanks for the welcome @mksd :slight_smile: . I found your website and a german phone contact. Since your location shows Berlin, it could be your contact. If so, would you mind having a short call using this number? Please tell if that is an option for you and when this would be possible in case.

@ibacher I will come back to your invitation to work on this after having the call with @mksd from which I hope to get some more insights if he allows.

Thank you so much and have a nice weekend,

Benediktus

Hi @bolschok, sure, I’ll DM you about scheduling the call.

@ibacher / others, I had a very interesting conversation with @bolschok today and here are my minutes:

  1. Whilst we (at Mekom) are working out a LIMS integration using FHIR messages and openmrs-eip, we will try to evaluate the overhead to also process radiology orders.
    The thinking is that it “should” be a very similar effort:
    • A Camel route to scan for radiology orders out of Debezium.
    • Each time a radiology order is detected → fetch both the patient FHIR resource and the radiology service request.
    • Create a bundle patient + service request.
    • Propagate that bundle into a Camel RIS/PACS route.
  2. “Someone” to develop a MF radiology order UI in OpenMRS 3.0. That’s just so that there is a UX to place them.
    @jdick, @ddesimone, do you guys need that in the short/medium term?
  3. Alternatively, just use the radiology module for a POC if there is too much overhead with the previous point, and assuming the radiology module provides such UI, presumably within the legacy UI. Maybe @teleivo can speak to this?
  4. Clarify, btw, what it is that the radiology module brings in terms of backend data model changes that are necessary. Bahmni does not use the radiology module and seem to be able to model radiology orders anyway. There is a knowledge gap here that someone needs to expand on. Maybe @teleivo can speak to this too?
  5. Assuming we have an appropriate way to represent radiology orders in OpenMRS, can the FHIR2 module populate radiology service requests that are useable and complete enough for the RIS/PACS to do what it needs to do with them? I guess that’s a question for @ibacher.

Then… there will be the way back. The RIS/PACS will somehow convey FHIR image study resources back to OpenMRS. I guess we are not there yet but this will require some work as well. Alternatively, instead of image study resources, the RIS/PACS could simply send back observations. That would certainly make things a lot easier. From my conversation with @bolschok it seems that it was still unclear what the actual proper FHIR workflow should be, I’ll let @bolschok complement on this point.

@bolschok I hope this reflects what we spoke about, of course please add your points as well. Thanks again for your time earlier!

Or, possibly, we transform the imaging study into the required component obs. This is similar to how we (tried) to implement support for DiagnosticReport: it’s just a wrapper for some underlying Obs.

I’m going to hazard a guess that we need to do some work to properly support the data the RIS needs. At a minimum, we probably need to add some support for bodySite? This would be a good thing to discuss.

With the lab work we ended up implementing a polling workflow, as we needed a way to ensure that orders weren’t lost. This essentially allows us to treat OpenMRS as the source of truth for (clinician) orders and the LIS as the source of truth for results. I’m guessing the Debezium integration is solid enough that that’s not a worry and Camel can probably handle any sending retries that need to happen?

The FHIR workflow varies a lot, depending on how it makes sense to handle things. There are something like three pure-FHIR options here:

  1. Probably the conceptually simplest is to create a FHIR transaction Bundle that gets POSTed to the RIS FHIR server (assuming that exists). That’s functionality we don’t currently have in the FHIR module, but it’s not hard to do. This effectively creates the ServiceRequest and Patient resource in the RIS FHIR server at lets the RIS handle things how it wants.

  2. The somewhat more complex thing to do would be to use FHIR’s messaging specification to send a bundle of the resources. The advantage of messaging over pure REST is simply a) it’s channel independent and b) it has some semantics for failures and retries already built in. This might be the easiest FHIR-compliant way to go for a RIS that doesn’t support FHIR or doesn’t act as a FHIR server. (It can also be made to work with a FHIR server by posting the message to the $process-message endpoint, but this is more or less equivalent to the above).

  3. We do something to emulate FHIR subscriptions. The way the FHIR specification recommends doing this is something like a POST to a URL to update the RIS that there is a new order for it to process, to which the RIS responds by directly querying the OpenMRS FHIR Server to get the new results. The advantages here are a) the RIS only needs to understand how to act as a FHIR client rather than a FHIR server b) the source of truth for orders remains the EMR and c) if the subscription is just triggering the RIS to query the EMR, then a fallback mechanism (i.e., the RIS does a timed sync with the EMR) is simple to implement.

Of course, if you’re doing this over Camel, we can modify any of the above to suit whatever needs the RIS needs.

I assume the path backwards looks similar, but this does heavily depend on the RIS in question.

1 Like

Thanks for the minutes of the indeed very interesting and inspiring conversation providing some insights.

I would like to add that most, if not all vendors currently adhere to the IHE Radiology Scheduled Workflow (SWF). As to my knowledge, no efforts are made to change or replace SWF reflecting FHIR so far. HL7 v2 and DICOM remain to be the means to interface for current and legacy systems.

This means that even if efforts are made to implement FHIR Service Requests for radiology, current integrations into radiology environments would require a broker to translate “Placer Order Management [RAD-2]” and “Filler Order Management [RAD-3]” transactions to and from the “Department System Scheduler” (RIS) as described in IHE_RAD_TF_Vol1 and IHE_RAD_TF_Vol2 to HL7 v2. This is regardless of if a push, pull or subscription model is selected.

Nevertheless, I think from an OpenMRS perspective it might be useful to implement those Service Requests as I have learned that FHIR is planned not only to be utilized for messaging to the outside world but also to the front end. Please rectify if this is wrong. For us having this implemented and using OpenMRS as a test partner (if allowed) would be very interesting to integrate and test prototypes, test existing systems using a broker as well as probably propose new workflows besides what is already drafted.

Thanks for the time spent on my request,

Benediktus