Adventures in Open Source Healthcare IT: OpenMRS w/ DCM4CHEE
I spent the past few days installing and playing around with OpenMRS and DCM4CHEE.
OpenMRS is an open source medical records system which I am told is popular in clinics around the developing world. It’s original use-case was providing the IT backbone of HIV clinics in Africa. However over time it has expanded into a more general and robust medical records system for keeping track of patients and their interactions with providers.1
DCM4CHEE on the other hand, is a fairly heavy-duty open-source Picture Archiving and Communications System (“PACS”) which allows for the storage and retrieval of medical images (ie: CT Scans, MRIs, etc), and is used in real-world applications around the globe. I have used dcm4chee in a few applications thus far, and can attest to its usability and robustness.
I became interested in OpenMRS because I was looking for an open source solution for the management of a mid-sized radiology clinic (basically a Radiology Information System, or RIS). At a basic level, I was looking for a solution that would allow the tracking of patient interactions within a radiology center, and the scheduling and tracking of radiology orders as they flow through the center (ie: Patient X is scheduled for a CT scan of the head on date Y, location Z, etc; Scan for Patient X was just completed; and so on).
The only candidate open-source solution that popped up was a third-party module built for OpenMRS called “Radiology Module with DCM4CHEE” (available here). Happily, as its name suggests, this module is designed to integrate with DCM4CHEE right off the bat, so that DCM4CHEE is aware of pending radiology orders, can communicate them to the actual machines which run the scans, can send back status updates on scans to OpenMRS, and so on.
Cutting a long story short, I was able to get the module up and running inside OpenMRS and successfully submitted a few radiology orders via it’s interface. Happily, the orders auto-magically showed up on DCM4CHEE’s modality work list (MLW).
Let me say that I absolutely admire the work done by the OpenMRS community under the open source banner. The platform looks quite impressive. Unfortunately for my use case (as of March-ish of this year when I last poked around), there were a few serious stumbling blocks:
- Radiology orders are not integrated with an appointment scheduling module. Furthermore, the available appointment scheduling module does not fit the use case of a larger clinic (you can’t for example set repeating provider schedules – and the interface for editing schedules appears to be broken).
- Multi-part radiology orders are not supported.
- It is not clear if radiology orders can be linked to specific services offered by the clinic (which, ideally would have specific average time durations, again, in order to facilitate scheduling).
- A lot of polishing and additional plumbing seems to be required to get the radiology module up to production level (including significantly improved test coverage), and it is a bit hard to guage the amount of effort required to amend the situation.
While I’m considering jumping in as a contributor to OpenMRS, I’m currently leaning towards simply rolling my own solution in a framework which I find easier to code in than Java EE (such as any Pythonic framework). My feeling is that I could code up what I need with significantly less effort and risk than trying to decode such a large and foreign code base, which in the end I may or may not discover to be designed in such a way to faciliate what I need.
However, I will definitely be keeping an eye on these fine projects, and will be looking forward to seeing how they progress!
- Disclaimer: This is not an endoresment, as I have yet to truly understand the limits and optimal use cases of OpenMRS, and a few worrisome bugs / broken features I have encountered in the online demo have discouraged me from investing 100% of the required effort to do so.