Domain 2: Responding to complexity in the technology(ies)
Don’t make the mistake of treating a new technology as a plug-and-play solution. You need to ask a lot of questions about it before you can be sure it’s the right tool for the job. New technologies often look appealing and promising until we consider all aspects of the innovation process.
Find out more about the technology and assess its quality and implications. If you are not the creator of the technology, familiarise yourself with all relevant aspects of it or ask an expert. Look at it; play with it; do a ‘walk through’ the imagined use case. Will this product really help with what you are planning to achieve? Could a different technology (perhaps one that is already tried and tested) do a similar job with less hassle?
NHS apps library – a searchable database of quality-assured smartphone health apps
Publicly available ‘curated’ databases of apps – for example:
Find out more about where the technology will come from and associated challenges.
Ideally the building blocks for your chosen technology e.g. coding platform, devices etc can be accessed or purchased easily (no long waiting periods or unreliable supply chains). Ideally, the technology should not depend on a single vendor/device/coding language etc, but work (or have the potential to work with or easily change to) others as well. They will have been tested extensively so you don't have to worry about these components being dependable. Conflicts of interest and claims to intellectual property (IP) should be sorted out before the project begins. It should be clear who will fund the technology, what it will cost and which costs are covered (set up, maintenance, updates etc).
Identify and address the key points where technical complexity will impact on success.
Find out about any unknowns and dependencies as soon as possible, and develop a plan to deal with them, including alternatives or workarounds. Reduce unnecessary technical integration. Integration between multiple systems makes everything more complex. Ask whether it is really necessary or if there are ways to avoid or delay this, especially during initial testing. But bear in mind that some forms of technical integration (e.g. to make a new piece of software accessible from within a patient's existing electronic record) may make the technology simpler for a clinician to use.
Consider how the technology will disrupt the system.
Map possible disruptions and take steps to avoid or mitigate them. Can you modify the technology to make it less disruptive? Can you reduce knock-ons by adjusting other systems or processes? What measures might you put in place (e.g. small-scale pilot running in parallel with the old service, on-the-job training, help desk) to deal with the disruption until systems and processes have evolved to accommodate the new technology? We pick up this important point again under ‘the organisation’ below.