Christopher McCann, snap40
MEDdesign

Blood, Sweat and Big Ideas: Why Is It So Hard to Innovate in Health Tech?

By Christopher McCann
1 Comment
Christopher McCann, snap40

A great idea is not the same as great execution.

Antibiotics, the MRI, genetics, monoclonal antibodies—these are but a few of the innovations that have changed our world. And yet in the United States, an estimated 400,000 people die every year from preventable medical events, costing the U.S. economy an estimated $1 trillion per year.

This is a multi-factorial problem with no simple or quick solution. It cannot just be solved by an iOS app or an electronic medical record (EMR). But technology has a significant role to play. It can allow automation of repetitive and well-defined tasks. It is a force multiplier, enabling one human to achieve more than they ever could on their own. Still, this can only happen with strong execution.

In most hospitals, 90% of patients still have their vital signs collected manually and repetitively by a nurse. In 2015, approximately 75% of hospitals adopted an EMR driven by the financial incentives of the HITECH Act. Yet an article in JAMA illustrates the potential for patient harm due to poor user experience in some EMRs. The Medscape National Physician Burnout and Depression Report 2018 showed that two main drivers of physician burnout were too many bureaucratic tasks and the increasing computerization of their practice, such as EMR integration.

Facebook, Google, Tinder, Amazon, Apple, Uber, WeChat—these consumer applications have revolutionized our daily lives in less than a decade. In our consumer lives, technology has made life easier. In professional healthcare practice, technology has made life harder.

For me, successfully innovating in healthcare is the marriage of three, sometimes competing, priorities. Here, we discuss these three priorities.

Building a Great Product Experience

A great idea is not the same as great execution. Remote patient monitoring (RPM) is a great idea, but until now it has been poorly executed.

Strong execution requires a clear focus on your users and a deep understanding of the problem. Let’s look at the iPhone as an example. The person paying is (usually) the same as the person using the product. Optimizing the product for the user, therefore optimizes for the buyer simultaneously.

This is often not the case within healthcare. RPM, for example, has multiple users: Patients and healthcare professionals who have varying degrees of training and seniority. But these are not the buyers. Purchasing within healthcare is still highly centralized, and there are often multiple departments involved, each with potentially differing priorities. Oftentimes, these priorities don’t align with those of the person using the product. This creates a perverse incentive for companies to optimize the product for the buyer, rather than the user.

This leads to poor user experiences and, ultimately, patient harm as demonstrated in the EMR study in JAMA. I would posit that poor usability in some EMRs is because they are optimized for billing, rather than patient care. They have been targeted at senior leaders, not users. Those of us developing healthcare technology should always, before anything else, optimize for the user and how a product can be more valuable to them.

It is clear that software engineers, designers, product managers and companies building healthcare technology have a direct impact on patient care and the lives of industry professionals. User experience should never be seen as a secondary priority. It must be part of the cultural fabric of the company.

Success of your product may well rest on user experience. For example, Pevnick et al concluded that users were reticent to share their personal data with their healthcare provider due to a 0.5% conversion rate when invited to upload their fitness data to the EMR. I would suggest this poor rate may be a function of poor user experience more than solely antipathy among patients to share data.

Outside of healthcare, we have seen the significant success of companies like Slack and Apple who consumerize enterprise technology. Slack took an alternative approach to selling into enterprises. Instead of targeting CIOs, the traditional buyer of Slack-like products, they focused on making an amazing product experience and then targeting the users directly. The users adopted Slack “by stealth.” Before leadership could even consider Slack, the organization had already adopted it. I see this same trend emerging in healthcare, heralded by organizations like Apple moving into medical devices.

Building a great product experience in healthcare requires a combination of a priori reasoning and opinion as well as in-depth domain context. Achieving this domain context requires embedding designers and engineers directly on the front-line, observing physicians and nurses to fully understand how to make their lives easier.

Making their lives easier will directly lead to saved lives.

Building a Product that Works Operationally

To create a successful healthcare technology product, one must also ensure it works operationally. While studies by Nakamura et al. and Pandor et al. have shown the potential economic and clinical benefits of RPM, others, such as by Noah et al. have shown that there is insufficient evidence. From experience, one explicit challenge in the RPM space is the chasm between building a product and operationally deploying a product.

Just as important as user experience is how a product will actually function in practice. A product does not start and end with its user interface.To be successful within healthcare, it must operationally function day to day. This is, in some cases, an even more complex challenge.

For example, in the RPM space, how does a patient receive a kit at home? How do they set it up? How is the kit collected? Do providers want to manage this or should the vendor? How will professionals engage with the monitoring information? How will they act on that information?

These are questions that should be answered during product development—they are intrinsic to success.

What makes this particularly complex in healthcare is the fluidity of workflows. They differ from provider to provider, disease to disease and physician to physician. There can be many hundreds of edge cases. These are challenges that startups would typically avoid during the minimum viable product (MVP) stage of development, but that may be impossible in healthcare.

For innovation to truly bring change, healthcare providers must embrace more immature products and collaborate with vendors to build out and refine the offerings. A true value of working with startups is their ability to quickly respond to the needs and challenges of customers. Furthermore, startups will always be more willing to work longer and harder to ensure customers love their product. For example, healthcare providers allowing designers and engineers to be embedded with physicians and nurses in clinical practice can greatly help in mapping out workflows and result in a better product.

The operational complexity of healthcare acts to dissuade startups and founders from entering the healthcare space. But deeply understanding that complexity is where the opportunity to build large companies and amazing products that change our world rests.

Building Evidence

There are two types of evidence—regulatory and marketing—presenting particular challenges to startups entering the healthcare space.

Government should always act to protect its citizens, and regulation of medical devices and health tech is crucial. At the most vulnerable moments of our life, when we are ill, we must trust that the devices and technology used in the delivery of our care works. This is just as true for the physicians delivering that care.

During the Theranos scandal, the company voided two years of blood test results, some estimates putting the number at more than 1 million. This was not a victimless crime—patients may have incurred significant personal healthcare costs as a result of false positive results. Patients may have been inappropriately treated, leading to harm. Theranos adopted the tech startup culture of move fast and break things, with tragic consequences for patients who trusted them.

Regulation exists, and should exist, to ensure that only safe and validated medical products are available. However, regulation can also strangle innovation. This presents two challenges to fledgling companies.

The first is achieving regulatory approval. Depending on the product, regulatory clearance may require as much effort, or even more, than development. It is essential to determine the regulatory pathway for your product at the conceptual stage. I would also encourage you to engage regulators at that point. The FDA, through the Pre-Submission Program, provides feedback to companies at early stages. Ensuring everyone is on the same page can dramatically reduce product development and clearance time, as well as regulatory risk.

The second is maintaining regulatory approval. Regulators do not like change. This can present a challenge when crafting a fantastic experience, including significant amounts of iteration and work with users.

Facebook runs many hundreds of experiments on their UX on a daily basis, releasing changes to a subset of users to test. This is extremely challenging to pull off in healthcare. It’s my hope through initiatives like the FDA Digital Health Software Pre-Certification Program, and the entry of companies like Apple to our space, we will see increased flexibility from regulators enabling more rapid, while still controlled, iteration that cultivates better products.

After regulatory clearance, you must consider marketing evidence. In a nascent market, such as RPM, there is still limited evidence of benefit. For example, Noah et al. state in their meta-analysis that further evidence is required before large-scale implementation. It’s critical to consider building evidence early in product development.

The gold-standard, a randomized controlled clinical trial, may be cost and time prohibitive for a startup. However, consideration should be given to a focused randomized control trial (RCT) with a suitable endpoint that supports the value proposition. The methodology and endpoint should be very carefully selected as a poorly designed RCT can lead to a negative result, even if the product performs well.

This can ruin a startup.

There are also other mechanisms to build evidence, such as case studies and smaller scale clinical studies. Furthermore, it is my view that healthcare providers and physicians should take a more cooperative position. For example, can they work with startups to develop evidence, paying them a discounted price or contractually committing to pay if success is achieved?

Many providers have launched innovation programs but I perceive many are misaligned. Startups need one thing—revenue. If you think there is value in a product, paying that startup, even a small amount, has dramatic value to that company. It can literally be the difference between success and failure.

Innovation within healthcare is a societal imperative. We must encourage more tech founders to start health tech startups. Healthcare providers should embrace and nurture these companies. Time is of the essence. In the five minutes it has taken you to read this, another four people have died of problems we can solve.

About The Author

Christopher McCann, snap40

Comments

  1. William Hyman

    A related issue is in the basic meaning of innovation. Does it just mean new and different, or should it have to mean valuable? And valuable how? Making products that have provable value is the real challenge. One might begin with asking these questions. What exactly is the problem you are trying to solve? Is this really a problem? How will what you are proposing solve the problem, exactly? How will you measure if it did?

    On a different note, the revenue problem is why the big guys will always retain their advantage, along with their regulatory know how.

Leave a Reply

Your email address will not be published. Required fields are marked *

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

If you agree to these terms, please click here.