Nearly forty years into digitalising healthcare has been a beneficial journey. Yet there also is a feeling of shortcoming, missed opportunity and backwardness when it comes to many people’s perception of where we are today. It is a sobering position to be in, given the promises and especially the opportunities. And while there is even a next wave of possibility emerging surfed by AI, AR, 5G, MD certified algorithms, consumer health, predictive modelling etc., I still need two X-rays if I want to see two physicians on one issue (I guess, I am only slightly exaggerating).
Clinicians blame it on usability challenges and documentation hell. Hospital CFOs blame it on cost and lack of investment funds. IT vendors blame it on end-user indifference and conservatism (“never change a running workflow…”), adverse reimbursement structures, which prevent innovative business models, etc. etc. It is a gordian knot.
Probably everyone somewhat has a point and the truth is, it really is hard. However, I fear that we, HIT professionals, still overlook a majour challenge and more often than not, put ourselves in a position not to address the real cornerstone: workflow.
We talk about it all the time, naturally. We call it workflow engine, decision support, integration or, simply, “more time for the patient”. Yet in the end what IT vendors deliver more often than not, is another product, yet not a solution. All too often, what we continue to focus on is technology, as if we have not moved on from the good old fashioned box-moving times. Those good ole times, when you created a beautiful and superior product, boxed it, shipped it to your customer and said: “it’s great, best in the world, go figure out, what you can do with it!”
That works for a hammer. Anyone can use it. But what about an API?
What I mean is our routinely negligence of the real-life workflows and actual purposes of our end users. Take a sepsis alert. It’s lifesaving decision support. Why would anyone not want it? Yet, even if vitals data was captured and fed real time into a patient record, even if standardized and harmonized data from disparate sources was consolidated and able to be analysed in real-time, even then, what does a nurse have to do, when she picks up the alert from the monitor? Who are all the various roles that need to be informed and with what information? Which is the most urgent step and what has more time? What could be automized in the first place? What are documentation requirements, so that the hospital will also be able to get reimbursed for the emergency routine? Where do I find an ICU bed? And, too, now that the alert is recorded, who is liable if anything goes wrong?
If all a tech company delivered is a smart algorithm and an alert… nobody will want it.
Maybe Sepsis is a bad example. There are sound protocols and every clinicians knows it by heart, do they? But what about less serious, still cost driving and patient jeopardizing workflows? Or, let’s take a different example, what about patient history? If a clinician has access to the integrated life-long patient record, but doesn’t have the time to read all that is in it? Will she or he be liable if they did not find an allergy or other relevant pre-condition? And if they are liable, would they rather not have access to a longitudinal record in the first place, than being obliged to read it all?
All too often we still find one of two situations: either the technology vendor offers new features and functionality, and clinicians raise their eyebrows thinking “More documentation, more data entry, more liability?” Or, while working with clinicians, the old ways and processes are shoe-horned into new technology in order for clinicians not having to change. Leaving IT providers frustrated again about the waste of opportunity for change.
In order to accelerate the digitalisation journey of our time and shorten the cycle of adoption and innovation, we need to start with ourselves, with us as innovators and providers of IT solutions. The thing we need to emphasize with our teams as much as with ourselves, is to always think with the end in mind. What is it, our end users need to do and want to achieve? What else could they achieve and what could be counteracting effects?
Take interoperability. In itself, it is nothing but a technical concept. Yet if we understand, why a role would like to interoperate, what information they need in order to execute what function, interoperability may become meaningful day one. And prioritized towards an achievable short term benefit, rather than boiling the ocean. And while avoiding information overflow at the receiving end, which may have caused prohibitive levels of data digestion cost.
As much as we as IT professionals would like for clinicians to leave their comfort zone a little more often and think outside their (workflow-) box, as much we should step outside our technology box, understand the why of a workflow, design a value proposition around it and only then start designing a technical answer for it. Why do we do something? What do we want to achieve? And only then: how do we do it.
Alfred Marshall, a famous neoclassical economist, once wrote (I am paraphrasing): 1. Use mathematics like a stenographic language, not as a purpose in itself; 2. draw your conclusions; 3. translate into English; 4. illustrate by examples, which are meaningful for the world; 5. burn the formulas; 6. if you fail on 4., burn the formulas and the English!
If we replace economic findings with workflow improvement and mathematics with technology, I think we should do the same: If you cannot illustrate your solution’s benefits with real life workflow examples, burn the whole idea. Purpose-free invention is called art. That is a whole different business. Regardless how beautiful the technology.