What Can We Expect on the Healthcare IT Landscape in the Next Four Years? Observations and Speculations

What Can We Expect on the Healthcare IT Landscape in the Next Four Years?
Observations and Speculations

“All happy families are alike.  Each unhappy family is unhappy in its own way.”  So begins Tolstoy’s epic tragic novel Anna Karenina.   In the world of literature, the word “tragedy” is often defined as “a good beginning that, because of a number of complex interactions, spirals downhill and ends badly.”  Let’s face it:  complex software projects often end up playing out this “tragedy trajectory.”  Like Tolstoy’s unhappy families, IT projects have a myriad of ways in which they can fail.  The failure is either one of outright failure – lofty goals and noble intensions ending with missed deadlines, bloated budgets, and unhappy stakeholders – or alternatively of a more subtle flavor with the project producing “successes” that bare little resemblance to the visions and expectations that the various project stakeholders thought would be produced when the project began.  The tragedy trajectory is a path well-known to virtually anyone who has worked in a large software development project.

In the world of healthcare IT, one could reasonably argue that no project is as complex as the goal of developing an integrated infrastructure to comprehensively support US healthcare.  Behind the phrase “integrated infrastructure” lays an IT landscape that is expected to support a diverse collection of requirements collected from the various involved stakeholders.  However, once one tries to get a bit more concrete and move beyond the high-level – and largely shared – goals of the project, goals usually stated with verbiage such as “an infrastructure and associated systems that enable the delivery of the right care by the right person to the right person at the right time for the lowest cost and the highest quality” – things get more complicated.  Each group of stakeholders – clinicians, patients and their families, administrators, payors, and regulators (to name only the most obvious) – has their own perspectives and expectations of what an integrated US healthcare IT “system” should look like…and more importantly, what it would (and should) do, and these perspectives are often challenging if not impossible to integrate into a single “US healthcare IT infrastructure.”

One could argue that to describe this formidable challenge as “a multi-factorial project” is itself a mistake because the endeavor is simply too large and too complex to be viewed as a single project.  It could therefore be argued that instead, one should take the organizational view that the project is really a number of interconnected projects.  However, such a partitioning in-and-of-itself makes the entire effort that much more complex because of the known difficulties in cross-project coordination and integration.  In the end, irrespective of how you package up the goals, tasks, and deliverables of the effort to define, design, develop, deploy, support, and evolve an integrated US IT infrastructure, most people who have experience with healthcare IT (or other projects of similar scope) would agree that the following hurdles that must be addressed and somehow successfully managed in order for the project to succeed:

• Harmonization of multiple (often conflicting) agendas;
• Integration of a diverse array of technologies, many of which are of the firmly-entrenched-legacy flavor and others of which are still emerging;
• Navigation of a volatile and shifting political landscape that, in the end, does not always have the power (or intent) to “dictate” or otherwise manage the overall project and its deliverables at the level that may be required;
• Successful relations with a financial landscape in which funding for the multiple tasks necessary to achieve the desired integrated landscape is fragmented across the realities of a competitive, market-driven vendor landscape rather than funded by a single (e.g. federal-level) source that can use its control of funds to control direction and delivery; and
• Ongoing inclusion of the ever-expanding field of medical knowledge that a truly useful and integrated healthcare IT infrastructure must be aware to be relevant and useful to its stakeholders.

As one looks through the above list, it is essential to remember that although IT projects often play out the tragedy trajectory, they – unlike Tolstoy’s unhappy families – tend to fail for a fairly well understood (if not well managed) set of common causes.  In particular, when IT projects fail – with “failure” being defined as inability to deliver expected requirements within two-times the expected budget and/or schedule – they often do so because of the impact of risks to the project, i.e. specific factors that were not – for whatever reason – successfully managed by the project.  Risks are “events in the future that have not yet happened but may occur.  If a risk does occur, it can impact the success of the project, usually negatively.”  Risks can be classified as being one of four types:

• Requirements – unknown, shifting, or contradictory requirements that result in a project never being able to declare that it has successfully satisfied its requirements and therefore can be declared as “finished.”
• Technology – immature or unstable technologies that are fundamental to the project’s success fail to meet required expectations, and/or the emergence of new technologies that fundamentally change the planned technology landscape in which the original project was conceived.
• Resources – inability to marshal sufficient resources – personnel, financial, etc. – as required to meet the project’s needs for completion.
• Political/Social – non-technical issues that threaten a project’s success and/or original trajectory.

Why talk about risk in a discussion whose focus is speculation on the trajectory of US healthcare IT over the next four to five years?  The answer is because risk analysis provides a convenient framework for sorting and looking more closely at some of the various ‘What if?’ speculations that one might put on the table in answer to the “What is going to happen?” query.  In fact, one can argue that the actual instantiation of a given ‘What if?’ speculation constitutes the identification of a given risk – or, alternatively, a possible benefit – to the large, long-term project that is the integration of US healthcare IT.  If the “What if?” turns out to be true, i.e. to occur, and if it can be smoothly integrated and leveraged within the overall project(s), it will in retrospect not be seen as a “risk.”  However, if it occurs and in some way impedes the project’s trajectory from a time, budget, or functionality perspective, it is a risk that has become manifest, and the focus by definition must change from risk identification and mitigation/avoidance strategies to contingency plans, the proverbial “What do we do now that this risk has occurred?”

Risk also provides an interesting perspective from which to ask what we can expect to happen over the next four-to-five years in the world of US healthcare IT.  Will the unknowns that develop around the nascent and only recently planted seeds of Meaningful Use – with its Vendor Certification and Provider Incentives – be effectively operationalized and therefore provide some of the basics for the overall success of the national IT integration effort?  Will the emergence of future trends or technologies enable the project’s success based on its current goals and possibly even enable the project to define and realize new, still unstated goals?  Alternatively, will the project flounder in a morass of contradicting agendas, heterogeneous technologies, insufficient funding, and political dissent only to be considered by many who will, in 2016,  dispassionately review it and announce that it has failed?  If only we had a crystal ball…

“Each unhappy family is unhappy in its own way.”  Like Tolstoy’s unhappy families, each IT project failure is a unique set of intersecting factors in time and space.  However, although the specific reasons for failure may be both myriad and project-specific, the underlying causes often share an all-too-common theme:  failure to proactively identify – and therefore effectively manage – the project’s risk profile.  The reasons that a particular project’s risks are not managed are usually not, per se, the critical factor.  Rather, it is the absence of ongoing risk identification over the project’s entire life cycle that causes the project to fail.  If a project team doesn’t identify risk as an integrated and periodic part of project execution, risks won’t – and therefore can’t – be managed/mitigated in any predictable manner.  The simple risk taxonomy given above is a useful way to think about risk.  Other approaches work equally well.  The important fact is to be thinking about risk from day one.  It’s like the Billboard Top 100 list…you put something on the list and then periodically review the list over the lifecycle of the project to look for trends.  In following installments of this blog, I’ll put on the table my suggestions as to the various specific risks that the US IT healthcare integration project may face in the next four years.  I’d like to hear yours as well.

Categories: Health