Nothing surprising here. Far and beyond IT, surgeons posses a rare and special type of ignorance... typical of your average over-powered decision maker with not enough time to understand or other incentives to make good IT decisions. This is really, really common in health IT, and not rare at all, but here's it's presented in the form of an over-entitled surgeon. Some people seem to think that brain surgeon is supposed to add gravitas to any conversation, in terms of understanding or something... but your average QA person is 1000x more likely to make a better decision than a surgeon, when it comes to IT.
And the source of the problems in this article? The legal dept. So please don't blame this one on anyone in IT.
My take away is close to the opposite, having worked around healthcare IT for many years. Systems are antiquated, un-integrated, use archaic and proprietary languages and databases, and the lack of cohesive design for usability encourages most clinicians to keep using paper.
IT as currently and usually practised, especially in a healthcare environment, is also mostly a disaster in terms of value for expenditure. $2 billion for an Epic system in a regional hospital system... Which was obsolete before it was installed. Heck, the Deustche Bank SAP core banking replacement only cost $1 billion.
Much of the "oh but it's regulated" excuses are just that, excuses to be ignorant and stay stuck in the 1970s.
It doesn't have to be this way, but it requires a lucky administration to find a way out of the mess given the market for lemons in IT management and systems integrators in healthcare.
Open source and Cloud solutions (from an operating model perspective way more than technology) appear to be the only way out of this mess of "your mess for less" IT because it lifts the veil of sales, consultant-speak, and opaque RFP processes in favor of actually-working-and-reliable software that anyone can see and touch.
In my experience of trying to sell software to healthcare organizations, they are practically immunized against better software.
They are institutionally allergic to agile, iterative improvement. It sounds too scary. They want big-design-up-front, even though that's guaranteed to deliver unusable software that's far more dangerous to patients than any transient bug.
This x100. Though I think it is changing as a younger generation grows into leadership positions, this will likely happen far later than other industries :(
> Much of the "oh but it's regulated" excuses are just that, excuses to be ignorant and stay stuck in the 1970s.
It is actually a serious problem.
You have a bunch of apparently sensible rules with apparently reasonable justifications, but without a holistic understanding of what those rules cost in terms of engineering and design trade-offs. Then compliance prohibits the use of commodity components not designed with those specific requirements in mind, which requires everything to be custom for the industry at extreme cost, which in turn impairs competition and allows the vendors who do pay all the compliance lawyers to sell low quality software for big money.
And it's not clear how open source or cloud would solve any of that, other than possibly through some kind of regulatory avoidance shell game, which sounds more like a loophole than a solution.
While that's true many commodity components also currently doesn't live up to the real requirements of those environments. I have a number of friends who work with enterprise Linux deployments. They are all doing very well financially.
How much of the problem is Epic, and how much is the desire of each client to develop their own unique byzantine workflows, that Epic has to implement? I wonder if this is like blaming C because so many programs written in C are bad.
I would say a mix of both, but more the problem is with the way the software fights your desire for custom workflow rather than encourage it or make it cheap.
I had a similar reaction to the piece, which painted doctors as not being part of the problem - when they have a profound amount of political power.
I had a friend who worked as a QA engineer (hospital processes) for a presitigious children's hospital. The QA department came up with any number of potential, well-conceived plans, but the falling-down point was always the doctors. One of the primary pain points was the lack of interoperability between different departments' record-keeping. Each department head had their favourite vendor, who would give them all sorts of goodies on the side, and as such, none of them wanted to change.
So, you'd have a heads of department meeting where the new QA plan would be discussed, which necessitated regularising the software across departments. The standard refutation was "If I can't use software X, children will die". Everyone knew this was utter bullshit, but there's nothing you can do when the head of department is considered the final domain expert. "Children will die", uttered by doctors and surgeons, killed more efficient processes in that hospital.
Another story of his was at another meeting where one specialist ventured an opinion. It was derided by one of the old-school, a veteran of nearly 30 years: "We don't do things that way; you'd know that if you'd been here any length of time". Said the opinion-venturer: "I've been here 17 years". That is one insular society...
The difference between doctors and engineers is that doctors indeed know which parts of the workflow are critical, and which will indeed cause children to die.
To this date, I'm not aware of any record-keeping software that's at least half as useful and efficient as the old and tried handwritten paper records.
There were only three useful IT innovations in medicine : (a) PACS [1] allows to easily compare and transmit X-rays; (b) lab work records; (c) appointments software.
My wife had some complications after childbirth that kept her hospitalized for a few days. Watching the staff fuck around with 3-4 EMRs to figure out what happened when was a ridiculous comedy of errors. It actually undermined my confidence in the medical staff -- they really struggled between shifts.
In the old days, the information was available at a glance, on a clipboard.
I worked on a healthcare IT system at one point as a consultant. I tried to the best of my ability to improve upon the UI or the software, at least for the small tasks commissioned to me. I think that most of the other programmers tried to do the same.
It was extremely difficult because the software was written over a long period of time by multiple generations of programming teams and programming styles. It was hodge-podge to say the least. Take that system and integrate it with another equally hodge-podge system. Then add a couple more hodge-podge systems to that. There were just lots of redundancies and disconnects. I did feel sorry for the people who were going to have to use that system.
I'd say that medical administrative software is ripe for "disruption" just because it sucks so badly. Except for the fact that the systems are a) huge b) require extensive domain knowledge c) are regulated d) sales of such systems are extremely political and e) there's no way to do an end-run around the administrators who are purchasing these systems. It doesn't seem very suited for a "move quickly and break things" scrappy startup.
And the source of the problems in this article? The legal dept. So please don't blame this one on anyone in IT.