• All Posts
  • Why so many innovation projects in healthcare fail ? Part-1 of 4

Sinflex brings you original research articles, our views on latest development in healthcare innovation and technology and updates on our projects, events and trainings.

Why so many innovation projects in healthcare fail ? Part-1 of 4

  • Mahesh Iyer
  • 31-May-2018

What does innovation mean for healthcare organizations?  For many years, it has been predominantly in the science and engineering space: how do you develop new drugs, new treatment procedures, newer devices, more efficient manufacturing. Most people agree that healthcare has been a laggard in terms of adopting new technologies.  There are many reasons given for this: healthcare is a very regulated industry, we are dealing with people's lives and therefore have very little margin for error, and so on. However, of late, there has been an upsurge in healthcare companies wanting to incorporate the latest technologies. This has led to a spurt of innovation projects mushrooming across the board, that hope to leverage the emerging technologies. While the promise is tantalizing, there have been very few innovation projects that actually have made it to full scale implementation. Why is it that so many of these projects fail?

In this 4-part series, we will look at some of the lacunae in the way innovation projects are handled at healthcare organizations.  We will look at it through the lens of our trademarked D.A.R.T. model, which stands for Design, Assess, Race and Transform. We start with Design, and its use in identifying the right problem to solve.

Problem identification

Much has been written about Design Thinking, and its use in problem identification and solutioning.  And many organizations make a concerted effort to apply at least some of the principles. As mentioned in the PwC innovation benchmark report "Reinventing Innovation" from 2017, design thinking ranks second (behind open innovation) in terms of the strategies that leaders would like to use to drive innovation.  However, there are several gaps. Let's start with how a problem statement is identified. It typically happens one of 2 ways: (1) An end-user gets thoroughly frustrated with a particular process and starts thinking of how it could be changed, or (2) senior management issues a directive to use a particular technology, and everybody start  looking for a suitable place where it could be implemented.

The second is obviously fraught with problems.  We only need to look at the Java and .XML examples from recent history (how most companies felt Java and .XML would be the "standards" to beat all standards) to see how forcing the latest "cool" technologies to solve problems that do not need them can be counter-productive.  But this is more prevalent than one would imagine. The PwC innovation report referenced earlier talks about how many companies are using technology as the driver, rather than an enabler for innovation.

The first approach to problem identification seems to be the "right" way to do it, given that it has bubbled up from the bottom.  However, this is also not without its limitations. Most of the time such problems tend to have a very "narrow" focus, and consequently, solutioning of such problems tend to be more "band-aid"  fixes.  The proximity of the user to the problem can be a liability in such cases; one needs to have the ability to step back and look at the problem from afar to be able to look at more wholesome and lasting solutions.  Another common mistake happens at the other end of the spectrum, where senior management identifies a very broad goal, like increasing revenue, or decreasing cost, as a driver for innovation, and then expecting that the consultants would figure out the solution.  These tend to suffer from the problem statements being too "vague".

The first approach to problem identification focuses more on the "WHAT" while the second approach focuses more on the "HOW"; the "WHY" is largely ignored in both approaches. In addition, both the approaches either start with a view of a potential narrow solution, or make the solutions space too wide.  This results in rendering many of the ideation techniques such as framing-reframing, brainstorming and exploring alternate points of view ineffective.

Illustrative Example

Let's look at the implementation of electronic health records (EHR) as an example of what aspects worked, and what did not.  The advantage of EHR are obvious, and the need also fairly so. Improved data accessibility, and the ability to connect with patients beyond the clinic visit were probably the 2 motivating factors to consider EHR, and the availability of NLP and OCR techniques made it feasible to implement the solutions.

However, we do not have dig too deep to understand all the different ways in which the current solutions have not realized their full potential.  The disparate EHR systems do not talk to each other, the cost of setting up and maintaining these systems are very high, and most physicians dislike it for increasing, rather than decreasing their workload.  Data privacy also remains a threat.

Recent survey respondents have overwhelmingly opined on the need of a "careful consideration of all points" before implementing an EHR system; underscoring the importance of investing time in "designing" the problem statement.

In conclusion

Design thinking is essentially an iterative process that requires openness to many different points of view.  While it is heartening to note more organization acknowledging the importance of design thinking in innovation, there are still many gaps in its full application.  In the next part, we will look at the next steps after a problem statement has been identified.


    No comments avialable

Leave a Comment

Please wait