Major changes to radiologydcm4chee

We are making important changes to the radiologydcm4chee module and would like to inform the community at large about these changes. The module has been worked on by different groups historically and is currently undergoing major design changes to work with different PACS systems and a new front end UX. We are doing two one major change now: 1. changing the artifactid to radiology from radiologydcm4chee 2. changing the repo to radiology from radiologydcm4chee

Currently, the code is located here - We would like to change it to -

A number of new contributors are coming to work on this module. So, we would like to rename this before next week. So please give us your feedback before 5-Mar-2016, if you are affected by this change.

Regards, Radiology module maintainers (@teleivo, @sunbiz, @bgevam)


related to this I updated the modules wiki page to

section Background contains references to the former projects which actually created the module. the installation guide will be updated soon!

1 Like

Just wanted to ping @mogoodrich here and to raise awareness that there are a couple of modules that have been written and are in active use for placing radiology orders and integrating with a McKesson PACS system at University Hospital in Mirebalais, Haiti.


I would strongly encourage us to pull out any common radiology components from these modules as well, and try to arrive at a common set of base functionality. In particular there are various radiology-related domain objects in the radiologyapp module that could/should be pulled out, and likely some common messaging interfaces and queuing in the pacsintegration module that could be pulled out.

I’ll let @mogoodrich comment more on the details.


1 Like

Yes, as @mseaton says, definitely take a look at those two modules, and the RadiologyApp module in particular. When adding Radiology support for our implementation we specifically added functionality that we though was generic and reusable to the radiologyapp module. Specifically that module has:

  1. A new RadiologyOrder domain object that extends TestOrder
  2. “Helper” objects to encapsulate the idea of a RadiologyRequisition, RadiologyStudy and RadiologyReport
  3. A RadiologyService that primarily saves and retrieves these “Helper” objects (translating them to/from Encounters–the “Helper” objects aren’t domain objects themselves)
  4. A “UI Framework” set of pages for ordering studies and viewing results

If we end up with a “radiology” module and a “radiologyapp” module, it would seem to make sense that items 1 thru 3 above should live in the “radiology” module, not the “app” one.

The PACS Integration module was intended to handle the specifics of our communication with the PACS system we are using, so has less “general” functionality but is still worth looking at–perhaps some common interfaces could be pulled out of it. It generally listens for Order events and creates outbound HL7 messages to send to the PACS system, as well as listening for incoming HL7 messages and converting them into Radiology Reports and Radiology Studies.

Feel free to ask me further questions as you explore.

Take care, Mark

Thanks @mseaton and @mogoodrich for the PIH information. I wonder we are going to build a robust reporting system for managing report generation. Should this be a new module or integrated with radiology ?

@teleivo @sunbiz

dear @mogoodrich and @mseaton,

thanks for the hint, I intensely browsed these repos from the beginning I worked on the module :slight_smile: And it also seems that we agree on whats generic for adding radiology support to OpenMRS!

I incorporated

  1. and parts of 3), there are however slight differences in the objects. We do not use any helpers so far. Visits and Encounters is something we need to improve on. We are looking into the EMRAPI module to help us out with this, which you are using. A major difference of course is how communication with the PACS is handled. We are sending HL7 messages directly without using Mirth as a communication server.

UI: we are still relying on the legacy UI. We have forms to enter radiology orders, and see a list of all the orders with filtering options.

Current & Future:

  1. we are currently working on reporting of completed orders

  2. adding an optional review step into reporting

  3. attach radiology orders to existing encounter, active visit

  • Further down the line REST API

Try to religiously update JIRA and the wiki. I will definitely include you guys in any discussion moving forward. It would be great to get one module providing generic radiology functionalities for others to build on.

Just to come back to the original post I think there is no objection to rename the github repo to, so far :slightly_smiling:

1 Like

Thanks @teleivo. It’s actually possible that some of the “API” level functionality could go into the EMR-API module as well, though I haven’t though it through.

I haven’t looked at your code, but whether the HL7 messages are going directly to Mirth vs. going directly to PACS doesn’t necessarily seem to be a major difference in and of itself. The bigger differences I can see would/could be:

  • We may have different communications methods, but just may depend on our individual environments (ie, we are running Mirth on the same machine as OpenMRS) rather than whether the endpoint is a integrator like Mirth or a PACS system

  • Format of the HL7 messages: although HL7 is a detailed standard, when working with our PACS provider, I discovered that a lot of way they used it was pretty arbitrary (typical quote from them: “Oh, you can put the order number in field x,y or z, it does’t matter to us, just let us know when we will configure it on our end”)… I made no effort to make this configurable in the PACS intergration module–I just used HAPI to populate the fields I needed to populate. Though it’s quite possible that our HL7 message formats are more similar than I thought–I haven’t looked at what you are doing

For what it’s worth, I think having a “radiology” module that provides the domain objects and API + a legacy 1.9 UI and then a “radiologyapp” module that provides a 2.0 UI on top of that makes sense (that is, I don’t think we need to harmonize the UIs to harmonize the other components).

Take care, Mark

1 Like

I would like to keep the burden of installing this to the user happy with legacy so i agree with the approach of

The renaming of the repo has been completed! Thanks everyone for your feedback. We will incorporate the feedback and follow the design closely of the other radiology modules