When healthcare needs technology, and when it does not

There is a familiar pattern in healthcare digital projects. A service has a problem. A product promises to solve it. The product is procured, configured and launched. A year later the service has a new system, new workarounds and the same problem. The post-implementation review concludes that adoption was poor and training insufficient. Both may be true. Neither is the root cause.

The root cause is usually that the decision to use technology was made before anyone had decided what the problem was. We build technology, including our own workforce platform, so we have no interest in arguing against it. We have a strong interest in it being used where it works.

Technology is a means, not a destination

Digital tools do a small number of things extremely well. They move information quickly and accurately between people. They make the current state of something visible to everyone who needs to see it. They take repetitive, rule-based work away from humans. They help people make consistent decisions when the rules are known. And they create a record that allows measurement.

They do not define what a service should do, reconcile competing priorities, change behaviour by themselves or repair a process that is broken in design. When a problem is fundamentally about one of those, technology will at best digitise the dysfunction and at worst entrench it.

Four questions before committing to a digital solution

1. 1Do we actually understand the problem? If the diagnosis is still "we have gaps" or "it takes too long", the answer is not yet. Technology chosen against a symptom will match the symptom.
2. 2Is the underlying process one we would want to run faster? Automating or digitising a process that is itself the problem produces a faster version of the problem.
3. 3What will the tool make possible that is not possible today? The answer should be specific: "see gaps six weeks out instead of six days", not "improve efficiency".
4. 4Who will own it and how will it be sustained? A tool with no local owner, no governance and no measurement will decay like any other change.

Signs that technology will add real value

• The problem is one of visibility: people are making decisions without information that exists somewhere else.
• Significant time is spent on manual, repetitive coordination: chasing, reconciling, re-keying.
• The same information is held in several places and disagrees.
• Good decisions depend on applying known rules consistently at a scale humans struggle with.
• You cannot currently measure whether things are getting better or worse.

Signs that the fix is somewhere else

• The service design itself does not match demand: no tool will staff a template that was never right.
• Roles, responsibilities or decision rights are unclear.
• Incentives pull against the behaviour you want.
• The problem is relational: teams do not trust each other, or clinical and operational leaders are not aligned.
• A previous system was abandoned for reasons that nobody has addressed.

Integration and adoption are design problems

When technology is the right answer, the work is far from over. Tools have to fit the operational reality: the actual workflow, the actual data, the actual people. That means integrating with how the service runs rather than asking the service to reorganise around the tool, training people on why as well as how, and adapting the solution as the real world reveals what the design missed. In our DRIVE approach we deliberately pair Implement with Integrate for this reason.

A simple rule

Use technology where it adds value, not as an end in itself. Start with the problem, redesign what needs redesigning, and bring in digital tools where they make the new way of working easier to run and easier to sustain. Done in that order, technology becomes what it should be: a quiet, reliable part of a service that works.