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

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.

About the author

Mandi Bishop

Mandi Bishop

Mandi Bishop is a hardcore health data geek with a Master's in English and a passion for big data analytics, which she brings to her role as Dell Health’s Analytics Solutions Lead. She 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.

5 Comments

  • “You can only have things done two of three ways: fast, cheap, or well”?

    To endorse and emphasize your central point…

    The problems of Meaningful Use are entirely predictable through the lens of the infamous Iron Triangle anti-pattern of software development. Attempting to bring too many features to market too soon usually results in unstable, less usable, and hard to maintain software.

    From my Fixing Our Health IT Mess: Are Business Models or Technology Models to Blame?

    http://chuckwebster.com/2013/01/healthcare-bpm/fixing-our-health-it-mess-are-business-models-or-technology-models-to-blame

    Great series, Mandi!

    –Chuck

  • Hi Mandi: The ONLY way to do health IT well is to make sure that technology stops causing 40-50 million patients/year to: 1) avoid or delay treatment for cancer, depression, and sexually-transmitted diseases; 2) hide health information. HIT SYSTEMS THAT CAUSE SO MANY BAD OUTCOMES MUST BE FIXED.

    HIT causes bad outcomes because patients know that their sensitive health data flows far, far out of the healthcare system and is used to make discriminatory decisions about them. Decisions like: you and your disease are too costly for your employer, or your disease frightens your employer, or your disease affects your reputation.

    Millions of patients know that sensitive personal health information is widely sold and available, so they try to ‘protect’ themselves by keeping themselves and their data OUT of electronic systems. See http://www.theDataMap.org to begin to see how MANY 100’S-1000S of hidden secondary and tertiary users of health data exist.

    The lack of patient control over PHI is a critical disaster, a tragic ethical and legal failure of national scope for US technology and US healthcare systems that must be addressed. See citations for statistics at: http://patientprivacyrights.org/wp-content/uploads/2010/08/The-Case-for-Informed-Consent.pdf

    Deborah C.Peel, MD

  • Just an aside…
    When I was doing software development, the methodology used was rarely thought about. We just did it and modified later as needed.

    I did notice an occasional change in emphasis over the years. We used to just start the coding early, make corrections as needed, and fully document when the project was completed. More lately, the emphasis has switched to process — talk it to death, and if there’s time left over, do some coding. The latter approach stifled innovation and usually resulted in missed deadlines.

  • @ Dr. Peel: interesting point about keeping info out of “the system”.

    @Mandi:
    I never thought squares and triangles could confuse me so. I’m not really sure about waterfall and agile, but I do know this:

    Most EHRs where developed, THEN the MU requirements came out…SO they had to piecemeal those requirements into their already built systems – not optimal.

    Most EHRs developed their workflows in a “perfect world” environment and I believe had the expectation that small practices would realize how much more efficient these workflow were and would change how their office functions…well this doesn’t happen, customization of the EHR does.

    Most EHRs couldn’t give a hoot about interoperability…why make it easy for you to switch EHRs?

    Anyone notice how little dentists complain about their EHRs…and how many of them are on an EHR while not being “forced”?

  • Your article quite brilliantly explained the difference between Agile and traditional system development. Furthermore, it clarifies the implications of each methodology. You also deal with three big issues: big data, medical information systems and of course; the methodology to synthesize data for discovery.
    While having the term ‘big data’ resurfaced, it has been around quite a long time. The most important big data users were the financial industry (other than the DOD), retail stores and the State Department just to name a few. While CIA, FBI and home land security uses these data to synthesize bio metrics and other behavioral data, it’s the financial & retail industry quite blissfully mine the data to sell us stuff and commercialize it very well. Many moons ago, Barnett Bank developed a program called BPP, Barnett Preferred Program. It was many ways first crowd sourcing in designing first commercialized consumer profiling. To your point, when we integrated and mine all the data, it was a systematic approach. Why is this? Well, the idea of applying any sort of mathematical models to glean knowledge out of raw data requires some kind of system or processes or guidelines. Mathematics has not been agile since the Pythagorean Theorem. If an application requires any kind of mathematics for discovery, agile won’t work.
    Medical information systems or medical informatics became very popular in the 90’s and early 2000. While many retail and financial systems are governed by a single item (or sum of many single items), medical information system, as you eluded, requires computerization of clinical guidelines, medical diagnosis, clinical workflow and most importantly, case-based medical informatics. While JAMA may articles based on laboratory results, the case based results are different. Thus, case base reasoning or as Silverman coined the term “analogical reasoning’ also requires a systematic approach rather than agile approach. Agile method won’t apply to analogical reasoning (mathematical modeling) since cases are governed by the linkages of other cases.
    In terms of development methodologies, so many of them came and gone including Joint Application Development, Rapid Application Development, KADS, OOAD and more. However, there is always one remained consistent with some variations is SDLC. At the end of the day, as you mentioned, a quality software product comprised of explicit description of functions (does what it supposed to do), friendly to users, error free, flexible and adaptable. When it comes to discovery, agile may not be an appropriate tool. Agile causes scope creep, prone to error and quality is poor (since scope changes overtime). However, agile has its place for prototyping and go to market products, i.e., Facebook, Twitter, startups. We also use Scrum. However, once the products are in production, requirements are heaver in details, workflow needs to be changed, etc., and then we always go back to modified SDLC which is our method. Enjoyed your article.

Click here to post a comment
   

Categories