Let's fix radiology!

[Devin]

This is going to come off as a little cranky so just bear with me until im done venting please.

There seems to be a lot of confusion over the current state of radiology in OpenMRS.

So let me lay this out there for anyone who may be trying to get it functional right now.

It is severely busted.

At some point between 1.8 and 1.10 the core devs decided it would be a good idea to deprecate and as far as I can tell completely remove a core api called OrderTypes. That api was essential to the radiology modules, probably a bunch of other stuff depended on it too.

Reading through the mailing list I guess I can sort of understand the logic for wanting to redo that section. However it is never a good idea to break something like that during a point release unless its for cannot be avoided I.e security concerns etc..

To be blunt, it is my opinion that those changes should have waited until 2.x.

Understand my concern here. People are trying to use this product to manage healthcare records. Lives are starting to depend on this code you have been writing. But you've been making breaking changes thereby turning the codebase into a moving target.

Frankly a change like that could have caused someone to die.

Not every admin in a rural clinic is going to have the skill to fully vet each point release that gets applied.

In this case I know of at least one place where the entire radiology department went down until someone was able to do a post mortem and revert the entire upgrade by restoring from backup. 3 weeks later.

So please consider that before making apis disappear in the future. Maybe work a little closer with the module devs so that breaking changes dont just shut whole departments down.

So now I've gotten my rant out...

My employer wants to deploy openmrs as part of a total management system for a large healthcare network and ris functionality is a key component of that.

Therefore I have the unenviable task of figuring out how to fix the radiology module.

My plan at this time is to start by forking the radiology module with dcm4che and trying to update it to work with the current 2x branch.

If you are interested in pitching in as a dev or a willing vic... err I mean, beta tester, I can use all the help I can get. Just respond here. I will invite you to the git repo.

Fyi I am not at all convinced that the current work flow is correct. I am interested in having a discussion on the pros and cons of dcm4che and the myriad of other elements that make up the radiology module and I look forward to working with you in the future.

[Paul Biondich]

Devin,

Hi, I'm one of the founders of the OpenMRS community.  Let me start by saying I'm sorry that you're in this circumstance.  When I read things like this, it's a good reminder to all of us that we have lots of room to grow and get better.  Thanks also for being comfortable communicating these kinds of issues with the community.  We need to hear about these things, as they happen.  While we know that there are literally thousands of implementations that are underway at various capacities, if we don't get this kind of feedback, we'll continue to take shortcuts when we feel there's an opportunity to do so.

The Orders API is an interesting circumstance.  In many ways, we saw the previous version of orders as very much "incomplete" and needing fundamental overhaul.  Most all of those changes happened in 1.10 platform release.  Can you help me understand what happened in the implementations that you are aware of?  Did they upgrade to 1.10 platform before these issues happened?  We tried to go out of our way to communicate to the community that 1.10 upgrades should only happen if they need the new order entry functionality.  Clearly we fell short there.

There's a fairly significant difference between our reference application releases (which have the 2.x label) and our platform releases (which have the 1.x label).  I want to make sure you (and the rest of the folks on this mailing list) understand that 2.x is *not* a new version of the API... it's simply a new version of the user interface layer.  One can upgrade the platform underneath without having to migrate or begin to use the reference application UI framework.

For the short term, I'd like to see what we can do to help you work through your radiology implementation.  Can you give us more information about where it is, and what it's plans are?  Are you related to the author of the radiology and dm4chee integration?  We are actively working to add more substance to orders.  I wonder if we can coordinate with your implementation to build radiology order support into the 2.x reference application?

In the longer term, I'm wondering whether examples like this might stimulate us to find ways to "register implementations".  Doing so will perhaps allow us to communicate fundamental changes like orders experienced and coordinate with implementations in a more effective way.  I'm pretty certain that a call went out to look for people that were going to rely on legacy orders functionality.  Clearly that communication didn't get to you.

Finally, a friendly recommendation:  OpenMRS is largely a community of very committed volunteers who do their best to serve the underserved with whatever spare cycles they have.  Given your call for collaboration, you might have more success bringing people together with your initiatives with honey vs. vinegar. :)   We expect that of people who join our community, so take that for what it's worth.

Welcome to the community, and let us know what we can do for you.

-Paul

--
OpenMRS Implementers: http://om.rs/implist
Post: implem...@openmrs.org | Unsubscribe: implementers...@openmrs.org
Manage your OpenMRS subscriptions at http://om.rs/id

Register today for our Maputo 2015 Implementers Meeting: http://om.rs/moz15

[Burke Mamlin]

Devin,

If you're able, we'd be happy to have you join an upcoming design forum (Monday or Wednesday) to discuss design choices for radiology orders.  Our priorities have been on med ordering, then test ordering.  Radiology orders would most naturally fit as an extension of test orders.

@Wyclif – I was looking at the 1.10 Release Notes and searching for order entry information on the wiki and found mostly outdated information.  Do we have page(s) for developers describing how to use the new order entry API (e.g., hints on how to add a new order type)?

Cheers,

-Burke

On Fri, Nov 14, 2014 at 4:54 AM, Devin <dev...@gmail.com> wrote:

[Michael Seaton]

Hi Devin,

Given the "crankiness" of your email as you describe, my first instinct upon reading it was somewhat defensive.

But upon reflection I do think that we should take a closer look at many of the issues that you highlight, particularly our versioning.

There was a good dev list discussion started about this by Rowan around a year ago, which can be found here:
https://groups.google.com/a/openmrs.org/forum/#!msg/dev/zsbDrXcWMpk/1sPADWZb8UAJ

Personally, I think we have found ourselves in a situation where our current "minor" releases (1.7, 1.8, 1.9) are really major releases, and our current "maintenance" releases (1.9.1...1.9.8) are really "minor" releases.

I think many of us that have been around and involved in the community for a long time have an implicit understanding of this, and certainly view an upgrade from 1.7->1.8->1.9->1.10 as a major deal that requires significant testing and almost invariable backwards-compatibility issues to work out.

Perhaps it is time we break free from the shackles of wanting the "2.x" line of OpenMRS core to be some revolutionary improvement, and make sure instead we are using our versioning as intended - to communicate the general level of impact that an upgrade from one version of software to another might have to consumers.

Interested to hear others thoughts on the subject.

Thanks,
Mike

To unsubscribe from this group and stop receiving emails from it, send an email to implementers...@openmrs.org.

[Devin]

Thanks everyone.
I got my rant out now, and no one removed my head from my shoulders, that means it's time to get down to business. :)

@Paul - You asked if I knew what happened during the botched upgrade.  I have a pretty complete post mortem, but it boils down to a new admin who did not speak english, trying to impress his superiors by being proactive and updating all software on all of the systems under his command to the latest patch levels.  He had good intentions, but didn't realize the 1.10 would break backwards compatibility and it ended up killing radiology for a few weeks.  The problem is being addressed by introducing a more formal change review process with the exception of critical vulnerability fixes.

@Burke - I would love to jump in on those.  I've been tasked specifically with "integrating a radiology workflow into the new medical records system".  Probably a good idea to pull some radiologists in on those discussions as well.

@Mike - Thank you so much for taking what I said as the honest feedback that it was, rather than going on the defensive.  It was late at night and I've been at task for several days. 
I re-read my post and realize that some personal feelings crept into that post, which is atypical for me and I apologize.

By all accounts, from the website, it would appear that the radiology+dcm4chee module is working and mainstream.  It wasn't until time and effort had been put into researching why the upgrade from 1.9.x failed, that it was realized that this module is absolutely not compatible with 1.10.

I agree wholeheartedly that version = impact or at least it should.

Furthermore, I would take it a step further and say, you don't really have a release until you have fully documented it.
It's a problem endemic to opensource, and in fact most closed source apps as well.
No one wants to be the guy or gal stuck doing documentation, but let me tell you, that person is my hero.
The programmer who can document and update docs as they go along is also a rare breed and have my admiration.

That's my spin on it anyways. 

At most large enterprises, the IT policy is dictated from the top and reads like this.
"We should attempt to keep our systems secure, therefore updates on the minor have automatic approval."
Buyin from the CTO and change control board are typically only required and requested on upgrades to the major.

Intuitively most people are accustomed to the concept that 2.0 will break compatibility with 1.0. 
But 1.x to 1.y or even 1.z shouldn't require much in the way of preparation and testing, so this tends to be a delegated responsibility.

I believe that most corporate IT policies tend to incorporate that sort of thinking.
I realize this product is as far from corporate as possible and there are absolutely no guarantees, warrantees or other express promises made.
But your website is slick, the demo is awesome and it looks professional enough that any IT admin would be out of his mind to even consider the other alternatives.

Your product is so good in fact that today I was made aware that a national government wants to try OpenMRS in a pilot project for a nationwide integrated medical records system.
(That was water cooler talk, so it may or may not be a fact, and I've probably said too much already).

Just be aware, that you really do have a lot of awesomeness here :)

So here's the deal.

I'm really only here to help, but right now I need help.
 
I need to find a path between a functioning 1.9 with radiology+dcm4chee and a 1.10.x system with equivalent functionality.
For that, I need as much documentation as I can get on what the old system assumed, and what the new system assumes so we can try to map out some sort of internal replacement or better yet a direct mapping between old and new.

Failing that, I need to look at what it would take to "un-deprecate" that old API, i.e. what would be the impact of someone pasting that old stuff back in and rolling with it until we find a better solution.

Thank you so much for your time and patience.

[Darius Jazayeri]

Hi Devin,

Broadly speaking, the only thing that changed from OpenMRS 1.9 to 1.10 is OrderService, however it changed in significant non-backwards-compatible ways.

I know nothing about the radiologydcm4chee module, but I took a quick peek at it and I see a mention that it depends on OrderType, and this is what breaks with 1.10. In fact we got rid of the old OrderType (which was pointless) and replaced it with a new OrderType that is meaningful. The design thinking behind the new version is described here. I don't know if the actual implementation exactly matches this.

So, presumably you're going to have to create a facade for OrderService, and route any calls the module makes that are failing through the facade, and conditionally instantiate a different version of the facade depending on whether things are running on OpenMRS <1.10 or 1.10+. Strictly speaking you do also have the option of forking the module for yourself and changing it to be 1.10-compatible while dropping compatibility with prior versions; but that's not really the way to help. :-)

This wiki page describes how to make a module work in different OpenMRS versions: https://wiki.openmrs.org/x/K46UAw .

There are a few module that have this pre/post 1.10 pattern. Here is the commit to htmlformentry where that was introduced (there may be followup commits too).

Hopefully Wyclif can share the latest documentation we may have on the actual order entry API (which may be in the form of tests), but if you have specific questions, do ask on the list.

Also, if you want to have a synchronous voice discussion with someone about this, the Wednesday University call is good for that.

-Darius