Eyes Wide Shut – Inflicting Agile On The Waterfall World of Healthcare

Posted on October 8, 2013 I Written By

Mandi Bishop is a healthcare IT consultant and a hardcore data geek with a Master's in English and a passion for big data analytics, who fell in love with her PCjr at 9 when she learned to program in BASIC. Individual accountability zealot, patient engagement advocate, innovation lover and ceaseless dreamer. Relentless in pursuit of answers to the question: "How do we GET there from here?" More byte-sized commentary on Twitter: @MandiBPro.

In a recent hangout with John Lynn discussing Healthcare Big Data and Meaningful Use Challenges, he asked me why incorporating more agile development practices into healthcare software and business practice is so hard. In my fumbling attempt to articulate a pithy answer, and I bumbled into an insight: health IT mandates are inflicting agile methodology onto the waterfall world of healthcare, and demanding adoption at an unprecedented pace. It’s creating an uncomfortable, and in many ways untenable, situation for the healthcare system as a whole.

For quick reference, here’s a diagram explaining the difference between the traditional waterfall approach to software development, and the newer agile methodology.

waterfall_v_agile

What immediately jumped out at me about this visualization of waterfall versus agile: doesn’t this inverse-triangle comparison look a bit like a diagram of the “flipped clinic”? “Flip the clinic”, as defined by the Robert J. Woods Foundation project, has become a rallying cry to reinvent the patient-provider interaction, empowering patients and providers to increase the value of each encounter through technology-enabled improved engagement opportunities.

flip_clinic

This “flipping” approach is considered a disruptive concept, with great power to accelerate insights and empower patients. However, currently, it is far from mainstream, and likely to take a decade or more to enjoy widespread adoption.

Health IT mandates are, effectively, demanding that healthcare “flip the systems”: move from a conservative, quality-deliverable “plan-driven” model to an aggressive, loosely-defined-deliverable “vale-driven” model – on an ambitiously aggressive schedule, on a massive scale.

As an industry, healthcare follows a very slow progression through the Waterfall development cycle. A commonly-cited statistic states that it takes 17 years for a single clinical discovery to become commonly applied practice. In the beginning, there is an idea with fixed requirements: a specific clinical trial is designed, with narrowly-defined scope to control variables and insure the highest quality results. The results of the trial are analyzed, published, considered for expansion. Patents are pursued. FDA approval is obtained. Over a decade later, the discovery makes its way into accepted treatment protocols, and eventually becomes part of the attending’s lecture to residents on rounds.

Contrast that slow progress through development and adoption with what’s happening under ACA, specifically with Meaningful Use objectives.

cms_mu_timeline

Now, if it takes 17 years for a clinical discovery to make it to mainstream practice, and that specific type of clinical function is what the healthcare industry is designed to DO, does anyone else see anything wrong with the schedule presented here? Notice there are only 11 years on that timeline, from inception of the certification program to the last year to receive an incentive payment? Only 5 years between program inception and penalties for non-conformance?

Another key differentiator between Agile and Waterfall: the criticality of quality. Quality is defined as “conformance to requirements”. Because Waterfall methodology places emphasis on explicitly-defined requirements, it also demands high-quality deliverables; there is traceability between each requirement and the specific feature/function that is designed to meet that need. Agile methodology places emphasis on flexible deliverables, as requirements are not clearly defined prior to starting work; the scope of the feature/functions that will be delivered varies, according to the results of the development effort and the time left to execute.

In one of my first posts on EMRandHIPAA.com, “Yes, Healthcare IT Adoption is Expensive AND Painful”, I ranted:

Haven’t we all heard the adage, “You can only have things done two of three ways: fast, cheap, or well”? Considering that the “thing” we’re trying to do is revolutionize the healthcare industry, the effects of which may be felt in each and every one of our lives at some point, don’t you want to include “well” as the bare minimum of what is required? After all, this is YOUR electronic health record, YOUR data, YOUR treatment plan and effectiveness measurements. So, what’s the other way we want this “thing” done: fast or cheap?

Now that I’ve spent more time working in the trenches with clinicians, detailing the operational challenges they’re facing with the rate of change the health IT mandates are demanding they absorb, I’ve come to the conclusion that I was wrong.

Health IT adoption must ONLY be done well. No other constraint matters.

Quality is of the utmost importance. Arbitrary deadlines are only increasing the cost required to implement half-baked product and process solutions that meet only the bare minimum “letter of the law” stipulations of the mandates.

The current focus on adopting health IT fast is only incenting corner-cutting measures from both IT vendors and healthcare providers. As a patient, I’m not ready to sign off on User Acceptance Testing of the nationwide implementation of Meaningful Use.