Skip to content Skip to sidebar Skip to footer

The Fourth Lens: Making Design Thinking Work for Digital Health

The digital health industry is growing rapidly: Predictions claim that the global digital health market will exceed 504.4 billion (USD) by 2025. It is also maturing as a discipline. Innovation teams are increasingly taking on bigger, more complex challenges and going beyond improving the patient experience around communication, prevention, and disease management. Digital interventions are now involved with diagnostics and treatment, which means they are entering into critical and highly regulated territory. With that comes rigorous demands for scientific evidence on safety and effectiveness. This creates the challenge of integrating two different worlds: agile product innovation and evidence based medicine.

In most industries, “customer focused innovation” aims to deliver products and services that delight customers. It addresses palpable “pains” and creates benefits that compel customers to buy into a new solution. Let’s start with the product and design perspective. A common approach to digital product innovation these days, following IDEO’s famous “Three Lenses of Human Centered Design,” is to identify the sweet spot at the intersection of desirability, feasibility, and viability and to deliver a successful product or service innovation:

  • What is desirable from a user perspective?
  • What is feasible (regarding technology, resources and assets, legal frameworks, etc.)?
  • What is viable from a business perspective?

Venn diagram with desirable, feasible, and viable overlapping to show the "sweet spot of innovation."

Figure 1. The sweet spot of innovation as we know it.

However, when you are developing tools that impact the health of users, it is not enough to have an intuitively charming value proposition. You also need to put a strong focus on reducing any risk your solution might introduce. You have to prove that your digital intervention is effective in bringing about the intended positive outcomes, many of which will not be immediately noticeable by your users.

The medical community, over time, has developed robust scientific frameworks to critically test new diagnostics and treatments. Anecdotal evidence is insufficient; you have to prove it with clinical trials, ex-ante risk assessments, and levels of evidence; and you have to comply with medical device regulations to be able to put your solution to market.

Move Fast and Break Things: Not an Option in Health Care

A lot of tech innovators moving into digital health do not realize that the digital health space is stringently regulated. Many are unaware that software in a health context will likely qualify as Software as a Medical Device (SaMD), subject to heavy regulation. Those who are aware of ISO 13485, IEC 62304, and the FDA often complain about what they see as overzealous bureaucracy that goes against agile principles (e.g., “working software over comprehensive documentation) that they hold dear. They are used to “moving fast and breaking things,” as software can be changed and iterated quickly. With continuous delivery, modern software development enables multiple, incremental releases in a single day, or even every 11.6 seconds.

It is not so simple in health care. You are required to perform risk assessments, well in advance of the launch, which often requires both deep clinical domain expertise and knowledge of Human-Computer Interaction (HCI). While offering a great user experience and usability may provide a competitive advantage in other industries, it is critical in health care, as it directly affects the risk level posed to the user.

Another fundamental issue is that many digital health start-ups fail to provide adequate data to support the claims they are making in terms of effectiveness of their solution, thus making it impossible to come up with a sustainable business model in health.

So, looking at the innovation diagram shown in Figure 2 for digital health, we realize that the three lenses are not enough.

Venn diagram with viable, feasible, and desirable connected and "effective?", "evidence?", and "safe?" as outlying elements.

Figure 2. Digital product innovation meets medical device regulations.

With the new European Medical Device Regulation, coming into force in 2020, digital health innovators will be subjected to even more rigorous regulation, so innovators should make up for these shortfalls as soon as possible.

The Medtech Tradition: Safe but Slow, and Not Customer-Centric

At the other extreme are traditional manufacturers of medical devices and software who have been building viable products that are regulatory compliant and have scientific evidence of their medical benefit, in terms of efficacy and safety. However, they are often undesirable to users. Have you ever peeked at your doctor’s EHR or practice management software? Joy of use was surely not invented there.

Often, these companies fail to approach product development with a human-centered mindset, ignoring patients’ emotional, behavioral, and wider social context that can in turn contribute to low adoption or adherence rates.

Venn diagram connecting feasible, viable, and effective, with an outlying element of "desirable?"

Figure 3. Medical devices and software today—evidence based, three different lenses.

Moreover, regulatory processes, which were originally established to assess and certify traditional medtech and pharma products with their extremely long R&D cycles, have not been adequately adapted to accommodate the faster moving and highly iterative nature of agile software development. Only recently have regulators come up with specific guidelines (e.g., TIR-45 by the AAMI). For patients, slowness of the medtech innovation cycles and lack of agile development practices can mean they will not benefit from improved therapeutic options in a timely manner. For start-ups in a fast-paced VC ecosystem, this means they might not survive long enough to see the outcome of a clinical trial.

Aligning Agile Product Innovation and Evidence-Based Medicine

Many digital health endeavors struggle with this ongoing challenge to reconcile two very different cultures—agile engineering and evidence-based health care—because at face value, the clinical stringency of one seems to be in stark contrast to the speed and agility of the other.

People coming from traditional medtech backgrounds are often concerned that agility begets reckless practices, exposing patients to undue risk. Health care practitioners who ultimately bear the responsibility for the tools and therapies they apply are naturally hesitant to rely on unregulated tools or untested prototypes.

Disciples of maximal agility, on the other hand, consider traditional health care practices to be too slow and inefficient. Indeed, documentation requirements create around 20% overhead to even the most agile teams (this number comes from personal experience and expert interviews).

Is it really a dichotomy? Why shouldn’t both approaches co-exist, or even augment one another? What if evidence-based practices could deliver value more continuously, and focus more on the people that will actually use their products and services? And what if agile practices and software development were more transparent and evidence-based, instead of relying on the self-biased nature of “great ideas” still prevalent in the tech industry?

Adding a Fourth Lens: Effectiveness

In order to operationalize a two-tiered approach that combines the speed of human-centered innovation with safety and evidence, we suggest an enhanced model of the existing design thinking paradigm with a fourth lens specific to healthcare—effectiveness. Beyond making sure your product is desirable, feasible, and viable, you need to prove that it creates the proposed outcomes. This will help your business be successful in the long run because nobody in the healthcare sector will pay for a solution that cannot present reproducible evidence for its effectiveness.

Venn diagram with the main components of viable, desirable, feasible, and effective with lists of questions/traits to discover to help provide the evidence for each component.

Figure 4. All four lenses should work in an evidence-based framework, with some key topics and questions to explore.

Apply an Evidence-Based Product Development Process

You should work through all four lenses, making your way from initial assumptions to facts. Activities and decisions in all four segments should be guided by evidence, with special scrutiny and documentation when it comes to evaluating patient safety, effectiveness, and economic impact of your solution.

Making evidence-based product decisions will create more transparency for your team, help you comply with quality management and usability engineering requirements, and ultimately yield better products. Apply user research and methods like Assumptions Mapping, Hypothesis Driven Development, and others to adopt an evidence-based product development workflow that will help your team focus more on outcomes, not shipping features. Especially if you are collaborating with healthcare professionals (and you should), they will appreciate that you are employing evidence-based learning and decision making, which will help you build trust and speak a common language.

What Is Your “Intended Use”?

To start, you must develop a clear intended use, a central requirement in medical device regulations. It will determine whether your software is a medical device in the first place and which device classification it will need to comply with. Essentially, you should (at any point in your development process) be able to clearly answer the following questions:

  • Who are you developing your solution for? Be specific and think about who will benefit most, who might be excluded, and who might be put at risk—then make a conscious decision (this will directly affect your value proposition, risk assessment, and ethical considerations).
  • What problem are you solving? (Clarity on the first question will help you find a relevant value proposition.)
  • What measurable outcome are you trying to achieve? With the goal of tangible results, your development process will be more focused.

This will provide you with guidance and a clear vision for valuable outcomes that you are working towards. You can start with a high-level idea that you can narrow down as you progress. In any case, try to build continuous evaluation into your processes following the Lean Startup mantra of build, measure, learn. In fact, the points listed above should be clear for any product development team, in any industry, to build a successful product.

Build Risk-Assessment into Your Process

The clearer you have your intended use, the easier it will be to know what risks your users might incur from using your digital health technology. Something considered low-risk can be developed and tested quicker. Items with a high potential impact, however, require thorough scientific testing and ongoing post-market surveillance. Of course, “there’s an ISO norm for that,” namely ISO 14971, but it is not tailored to digital technologies. US regulators have begun to think about how to categorize risk assessments of Software as a Medical Device.

Basically, your risk assessment must begin before you develop any feature and it must be ongoing as you develop the tool. Always keeping the question “what could go wrong?” in the back of your mind is nothing but basic design ethics. These kinds of considerations have been increasingly demanded for the tech industry in general, as a “Hippocratic oath for developers,” and they are fully aligned with the Modern Agile principle of “make safety a prerequisite!”

Circle diagram with "Modern Agile" in the middle and "Make Safety a Prerequisite," "Experiment and Learn Rapidly, "Deliver Value Continuously," and "Make People Awesome."

Figure 5. Agile and Medtech are not too different after all. (Source: http://modernagile.org)

How to Evaluate Digital Health Technology?

So, when do we have enough evidence? A clinical trial can easily cost seven to eight figures and take months or years to complete, with uncertain outcomes. Should digital interventions be treated any differently when it comes to evaluation? There is still a lot of uncertainty for health innovators regarding evaluation and evidence frameworks for digital health interventions, as regulators, legislators, and payers have responded with varying speeds in different regions.

So how can you make sure you are neither failing requirements nor drowning in bureaucracy? There are already guidelines out there. The NHS, with partners, has developed an Evidence Standards Framework for Digital Health Technologies that can provide great starting points (even outside the UK). The FDA has initiated a Digital Health Innovation Action Plan and will be testing a Software Precertification Pilot Program to help bring digital health technologies to market faster.

The WHO offers a practical guide for Monitoring and Evaluating Digital Health Interventions that helps you plan how to assess your solution and report the findings effectively. As mentioned in connection with the intended use, know what kinds of data endpoints you need and think about ways of collecting that data reliably as soon as possible—if you do not want to waste time and effort.

There will hopefully soon be more internationally harmonized guidelines for the evaluation of digital health interventions to help innovators, providers, and payers deliver improved healthcare experiences to patients faster and more continuously.

Takeaways

  • When innovating in healthcare, do not forget the fourth lens—without proving your solution is effective, you will not have a business model!
  • Do not neglect the human experience of your digital health technology—make it desirable, accessible, and usable for real people—or they might as well not use it.
  • All your product development should be evidence based: it is a regulatory requirement for safety and effectiveness, it will improve collaboration with healthcare professionals, and it will help you make better product decisions too.

We are, however, still exploring this space ourselves. Please let us know whether you think the four lenses model helps you in your work. Do you use other approaches? We would like to hear your thoughts!