Steve Jobs and the tidal wave of apps that followed in his wake have spoilt us with software carefully tuned to the way our lives work. Whether its hailing a taxi, mapping our runs or counting calories they are intuitive and fit seamlessly into the demands of each task.
In designing their products these disruptive start-ups have worked so closely with the end customer, that they’ve conquered what is known as the ‘last mile’ of implementation (getting your product to work and be used regularly by the end customer) without us even realising.
In health, as one might expect, this doesn’t happen so easily.
We see wild amounts of funding, slick solutions, eternal pilots in clinics and finally the successful distribution of products into healthcare systems. Then what happens? The app that helped doctors communicate lies dormant because no one realised this particular hospital didn’t have Wifi. The pulse oximeter that was going to help doctors in a rural hospital in Uganda gathers dust because no one knows where to buy batteries. Patients are missed for their venous thromboembolism assessments (leaving them at risk of life threatening clots) because no one gave the doctors a login to the new app. Junior doctors have to race 10 minutes to the other side of hospital to process an arterial blood gas on a critically unwell patient because the machine in their ward doesn’t do lactate. A patient’s observations are not discussed one the ward round because the iPad battery is dead and thats the only device that can access them.
These frustrations are a daily occurrence and make implementing technologies in healthcare a huge challenge. Unlike many of the tasks we do as individuals each day, technology solutions for healthcare have to work for large complex teams and multiple stakeholders. Each of the doctors, nurses and physiotherapists can be managing a large set of patients – 20 or so per day on average. There’s little continuity, especially for the junior doctors – they help with different teams, patients come in and out, so often when assessing a patient their case is entirely new to them.
Technology should have flexibility within its design to be customised to suit it’s context. With software, this is certainly possible, but no one has done it yet.
Then theres the complexity of the tasks in hand: hundreds of tests, results, observations, interventions, diagnoses, discharges. And then the other stakeholders – the patients, the managers, the relatives. All of this differs surprisingly significantly from ward to ward, let alone hospital to hospital. Each time a new technology is brought in a detailed assessment of the system in which it is placed needs to be made. Ideally, that technology should have flexibility within its design to be customised to suit it’s context. With software, this is certainly possible, but no one has done it yet.
The problem with poorly implemented and maintained technologies is they cause more harm than good. In high stakes setting such as healthcare, the risks of moving to a less-than-perfect alternative are huge. Aside from patient safety, when they fail staff become more conservative and less likely to use new solutions in the future. As one nurse said: “In the Navy we still use paper, because paper doesn’t crash.” While it seems like a sensible (if not luddite) point there are hundreds of industries in which high risk tasks are executed safely using technology – the airline industry being the most obvious example.
Healthcare is not alone in needing reliable, fail-safe technology. It is, however, alone in actually having it.
Image courtesy Ted Eytan, under Creative Commons Licence