Why Doctors Hate Their Computers
I read an interesting article about the use of software systems in American Healthcare published in the New Yorker on the weekend. The author, Atul Gawande, started his lengthy article (9000 words, 45m read time) describing his introduction to the national patient record system, Epic.
As he described the promise, and then realisation of Epic, it was easy to substitute EPAS in its place and the article would have read almost exactly the same for anyone familiar with the South Australian patient record system. After spending three years working on the new Royal Adelaide Hospital and with family in medicine, the experiences in the article sounded identical to what I had been told by doctors and medical staff here.
As Atul describes, a large part of the Epic issues stemmed from a people problem. Could this have been better change managed? Who is the end user in this situation anyway, probably not the doctors. Large risks like this often get criticised and blasted by the media for being massively over budget and taking too long, but maybe that is the cost of progress.
This reminded me of some insightful comments delivered in meeting we had on the hospital project from a senior manager of SA Health addressing the project team. He told us to ignore the negative politics and media surrounding the hospital and be confident we were delivering something good for the state. He had already endured a fair share trying to introduce EPAS, and knew that the benefits far outweighed the pain, and would have much longer lasting effects. Of course it will be hard, of course it will be expensive and take longer than anyone expected. But this is where one chord from the New Yorker article stuck out and resonated when interviewing Gregg Meyer, chief clinical officer at Partners HealthCare, who tells Atul:
“But we think of this as a system for us and it’s not,” he said. “It is for the patients.”
There are ten times as many public users of the Epic system as internal staff users, looking up lab results, doctors notes and prescribed medication. It is all too easy to get caught up in frustrations with learning new software and forget who else might be affected, but that is not an excuse for delivering a bad user experience.
While the Epic users try to stretch some of the boundaries of their new cage and implement their own solutions (which typically leads to the emergence of shadow IT), Epic is trying to address this by trying to establish an internal App Store for medical records. While this goes some of the way towards a self-service model, it is still a “walled garden” of curated experiences likely repeating the same limitations of the current system. But what if users could design their own apps to suit their own processes and integrate it?
I’ve seen processes and procedures vary drastically across departments within the same hospital, I can’t imagine trying to impose a suite of processes for a domain as complex as healthcare for a state-wide let alone national-wide medical system. But this very problem is what ignites my imagination and makes me passionate about what I do! As part of the team at Skyve, we’re trying our best to move away from megalithic systems and want to empower end users to not just be part of, but participate and own the process. Software shouldn’t be something you buy like a house or a car and replace every 10-20 years, it should grow with an organisation, live and be able to adapt.
This won’t change overnight, but with small steps (what if I could change this form to ask this question, or create a whole new form for this process?), it doesn’t need to be hard, expensive and lengthy. Just chip away at it, a bit at a time.