When Technology Fails to Fade into the Background


Vitruvian-man
My family physician's practice has been part of a bigger healthcare network for a couple of years. The promise was — let us take care of the administrative work. But it was a half promise. Because the other part of it is not so there is more time to spend with patients.

The system is still buggy and takes an enormous amount of time and cognitive load for the doctors to use — doctors who have a grounding in coding. Why isn't the front end providing a better customer experience? Maybe the IT group doesn't see doctors as customers. Maybe there was no update of a legacy system.

Brochures scattered around the office say “we're state-of-the-art,” the reality is even as patients we care more about security and simplicity than sophistication. When a doctor has to shave time off talking with patients, we all lose — they are the keepers of the experience, best suited to understand context, constantly learning from being with people, seeing what is going on with someone.

This is all too common, still. Information architecture, user experience, design — these are not just abstractions to describe professions, they are first and foremost tools. Just like conversation, we should use them to create better experiences. For example, design can be an agent of change in complex systems, when it is in service to people.

We get so wrapped up in the technology, that we pay little attention to who needs to use it and in which contexts. Forget personalization, “give me a system that works,” says my physician, “that takes into account what a doctor does.” His strategy? Spend as much time as possible seeing patients.

He is not alone. 

Why is healthcare tech so bad? Part of the reason rests with unanticipated consequences of changing the way we do things:

The unanticipated consequences of health information technology are of particular interest today. In the past five years about $30 billion of federal incentive payments have succeeded in rapidly raising the adoption rate of electronic health records. This computerization of health care has been like a car whose spinning tires have finally gained purchase. We were so accustomed to staying still that we were utterly unprepared for that first lurch forward.

Whopping errors and maddening changes in work flow have even led some physicians to argue that we should exhume our three-ring binders and return to a world of pen and paper.

This argument is utterly unpersuasive. Health care, our most information-intensive industry, is plagued by demonstrably spotty quality, millions of errors and backbreaking costs. We will never make fundamental improvements in our system without the thoughtful use of technology.

But this is not just about code, it's also about “who” — who is doing the coding, do they understand a physician's workflow beyond the graph on a PowerPoint deck? And it is also about “what” — costs and efficiency are a concern, but it costs twice as much to do a shoddy work of it. If we go with the metaphor that “time is money,” then wasting the minds of trained physicians and that of patients (also professionals with jobs) on administrivia completely misses the mark. Technology was supposed to make things easier.

Getting back to “who” — who builds those systems? Do they represent the users? Anil Dash says:

When Facebook decided to accommodate people regardless of what their gender expression is, they were making a statement about their values and who their service was for. A few million people around the world were suddenly a little bit more welcome into Facebook.

Which raises the question, well, whose values? Whose values are shaping these apps that we’re spending three years of our lives or 10 years of our lives tapping on it? More simply, who makes your apps?

This sounds like a simple question. And it’s really, really not. It should be kind of straightforward.

[…]

Who makes your apps? This shouldn’t actually be a mystery. And we know almost nothing about who’s making these apps. Actually, that’s not true. We know who it’s not. We know who actually is getting funded and being supported in creating these apps. We know that women are roughly about 50% of the population and roughly about 5% of who gets venture funding from the tech industry. We know that African Americans in the US are about 12% to 13% of the population and about 1% of who gets venture funding. And those statistics are born out in the apps that we use and who the creators are. If you go and look, if you’re able to find it, we know a little bit about who’s not there. And it’s not most of us.

We've all read the headlines about the Anthem breach, how about Carefirst Blue Cross hitting 1.1 million customers, Premera Blue Cross, and if still curious we can track a day in the life of a stolen health record.

So it's not just who is building the apps and portals and back end systems and if they represent and understand those these technologies should serve, but also what are their credentials? Because there is accountability that comes with the creation of a new kind of infrastructure — it may not be as physical as a bridge or a road, but it is used by people and it can harm people. Stories of identity theft, loss of privacy, and more dire consequences are one search query away.

Designing and building infrastructure in the public interest has a long tradition and as we migrate more of our transactions and services online, this infrastructure should also be built in the public interest. The Atlantic says:

The traditional disciplines of engineering—civil, mechanical, aerospace, chemical, electrical, environmental—are civic professions as much as technical ones. Engineers orchestrate the erection of bridges and buildings; they design vehicles and heavy machinery; they invent and realize the energy systems that drive this equipment; and they contrive methods for connecting all of these systems together.

It’s no accident that the most truly engineered of software-engineering projects extend well beyond the computer. Autonomous-vehicle design offers the most obvious contemporary example. When Google designs self-driving cars, it musters its own computational systems, like mapping and navigation. But it also integrates those into a world much larger than browsers and smartphones and data centers. Autonomous vehicles share the roads with human-driven cars, pedestrians, and bicyclists. Those roads are managed, maintained, and regulated. Self-driving cars also interface with federal motor-vehicle standards and regulations, along with all the other material demands and foibles of a machine made of metal and plastic and rubber rather than bits. Engineering addresses complex, large-scale systems.

[…]

Perhaps software calamities like data breaches and dieselgate will raise the hackles of the public, such that the standards for software development will be revealed and, in time, reformed.

Changing the world starts with changing our approaches, to upgrade them with the times, and with the responsibilities associated with what we build.

 

[Leonardo da Vinci]

, ,