Throughout history, doctors and others delivering health care have typically used a simple model when treating patients: deliver an intervention, such as a medicine or a surgical operation, and watch the patient improve (or occasionally not). The key point is that most people expect medical treatment to comprise what is typically a single action, followed, hopefully, by recovery. This is the basis for example for the classic randomised controlled trial (RCT) formalized by British epidemiologist Austin Bradford Hill in the 1940s.
Digital health however comprises many interventions. First comes the technology which is software or software + hardware and almost never delivers any benefit at all. Indeed if nothing else changes it typically adds to costs.
The benefit comes from the second intervention the technology enables: typically an improvement in the care pathway for treating a disease. Examples include enabling a patient to be treated at home, rather than in hospital (so called “hospital at home”); rapid tests that enable a clinician to diagnose a patient in one sitting rather than having to return for the results, and waste valuable time during which the condition might worsen; and encouraging lifestyle changes such that moving patients with Type II diabetes into remission.
However changing care pathways requires design and subsequent training for staff involved. In addition, taking the example of hospital at home mentioned above, they might require fewer hospital staff and more community care staff, so there may be a need to let some people go and employ others. Finally the patient may need training too. So suddenly, in addition to the cost of the technology, there are potential costs for designing new care pathways, staff training, discharge, recruitment and patient training, making six interventions in total.
Technical experts therefore need to be aware of this complexity when designing and creating new digital health interventions, especially those designed for older people who typically have greater difficulty mastering the new. Most importantly they need to produce technology that is intuitive to use.
Another feature of digital health is that it often requires extended use by patients, such as taking blood pressures and regular weighing, so, in comparison with popping a pill every so often, it reminds patients that they are ill. Most people don’t like this, so another feature technical experts need to consider is whether to try to shorten that usage period, or make it more engaging – “sticky” in user interface language.
Digital health has its plus points too, notably that because it typically requires return of patient information, it is easy to spot if the technology is not being used, and therefore to take appropriate action. Only medicine using (pricey) pills with built-in radio transmitters can equal this ability, which is why medicine adherence averages 50% whereas digital health is close to 100%.
One issue to be wary of when technical experts are discussing potential implementations with customers is trials, or as they are sometimes referred to, pilots.
The problem for digital health is this bit about changing staff (and patient) behaviour. Trials, by definition, are finite. Suggest to staff (or patients) therefore that you will be running a trial and, if the behaviour change is not to their liking or, as in most cases simply represents a change that they in their daily routine they don’t want, and they will only pay lip service until it ends. However tell them that the world is changing and that staff are expected to accept that whereupon adherence to the new behaviour required is likely to be far stronger.