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
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.
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.
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:
A new RadiologyOrder domain object that extends TestOrder
“Helper” objects to encapsulate the idea of a RadiologyRequisition, RadiologyStudy and RadiologyReport
A RadiologyService that primarily saves and retrieves these “Helper” objects (translating them to/from Encounters–the “Helper” objects aren’t domain objects themselves)
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.
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 ?
thanks for the hint, I intensely browsed these repos from the beginning I worked on the module
And it also seems that we agree on whats generic for adding radiology support to OpenMRS!
I incorporated
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:
we are currently working on reporting of completed orders
adding an optional review step into reporting
attach radiology orders to existing encounter, active visit
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.
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).
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