The debacle of the Healthcare.gov Web site rollout will serve as a case study in curricula of business, political science, informatics, and other fields of study for years to come. It is unfortunate that the toxic politics of healthcare reform obscure other interesting lessons to be learned about large-scale IT initiatives applied to complex problems, such as trying to match individuals to health insurance plans available in their area and determining who is eligible for federal subsidies.
I count myself among those who have waited years for healthcare reform, seen an imperfect (but better than the status quo) plan signed into law, and then observed its rollout botched from both a technical as well as a communications standpoint. My views on the Affordable Care Act (ACA, aka Obamacare), not the focus of this post, are that it was the best that could be achieved politically at the time, and that it will hopefully be improved over time. The goal of providing healthcare to all Americans, including those who are not insurable by market-based mechanisms, is still a laudable goal. I am also dismayed by those who want to see the ACA fail at all costs, almost as if the fact that real people will be losing real healthcare coverage (or not having it in the first place) did not matter. I also agree with those who note we cannot attribute blame of everything bad happening about health insurance to the ACA, i.e., health insurance costs continue to rise for reasons unrelated the ACA and employers would likely continue scaling back health insurance benefits regardless of whether or not the ACA were repealed. Well, maybe I did want to get some commentary in about the ACA after all, but the bottom line is that the pre-ACA status quo was not sustainable.
Nonetheless, what can we learn from the Heathcare.gov rollout from an informatics standpoint? One problem is clear, which is the federal procurement process for IT, about which even President Obama joked. This is issue is addressed well in context in a blog posting by Dr. David Blumenthal, the former Director of the Office of the National Coordinator for Health IT (ONC) who was appointed shortly after the first election of President Obama. Dr. Blumenthal noted the major differences between a typical large-scale federal IT procurement and the selection of an electronic health record (EHR) system for the large and venerable Partners Health System, which is anchored by two of the large Harvard Medical School teaching hospitals.
For the federal IT procurement, the agency (in this case, ONC) provides the specification and then in essence turns the process over to a separate contracting office in the government. This is in contrast to the Partners EHR decision, which was reached by a process that involved leadership guided by diverse expertise within the organization. This sounds to me like an informatics approach, from gathering the needs of the organization and giving voice to different stakeholders within it, to then seeing the entire selection process through to making a decision. Whether or not we call it "informatics," implementing a large complex IT project "takes a village" within organizations.
Another insightful blog posting comes from Clay Shirky, a well-known Internet commentator. He noted how the Healthcare.gov planning and rollout process defied well-known best practices for undertaking large, complex IT projects. Political necessities cannot bypass the reality of the incremental requirements gathering, setting reasonable timelines, and testing. Part of the problem, of course, is that the ACA needed to roll from a political standpoint in October, 2013. Delaying longer would push implementation into the middle of the 2014 elections, which would make those elections potentially more unpredictable.
But political timelines aside, everyone with knowledge of complex IT projects knows that no amount of political or other wishful thinking can make a project happen faster than is possible. John Halamka, a well-known informatics blogger, rightly pointed out that few people remember a project launching somewhat late, whereas more people remember for a longer time when projects go poorly and caused disruption, as Healthcare.gov has. I myself have always believed that one of the major limitations of the HITECH program was its highly compressed timeline, mostly related to its being funded by a short-term federal economic stimulus. This was certainly true for many of the grant-funded activities under HITECH, such as the regional extension centers (RECs) and the workforce development program. The RECs, which were funded at about the same as the workforce development programs, needed trained personnel immediately. Yet the workforce development training programs needed some lead time to be developed, and even furthermore the curriculum for those programs should have had enough development time before those.
In conclusion, while not everyone uses the word "informatics" in their descriptions of what happened and what should have been properly done with Healthcare.gov, it is clear that the type of approach advocated by most who are trained in informatics would be more likely to achieve the outcome resembling the Partners EHR implementation than the Healthcare.gov debacle. This is not to say that projects led by informatics experts never fail. However, the involvement of stakeholders, glued together by informaticians who understand healthcare, IT, and their interactions, would likely have a probability of greater success. I acknowledge the previous sentence is not evidence-based, since one cannot carry out randomized controlled trials in these sorts of complex interventions. But there is plenty of accumulated knowledge and wisdom on the best practices that emanate when sound informatics principles are applied [1-4], and these should guide any type of complex health IT implementation.
I am sure there will be more lessons that emerge from the Healthcare.gov experience, and hopefully honest scholars will be able to peel back the toxic politics and truly allow learning to take place. I also hope we can achieve sensible answers in our quest to provide basic, high-quality, and affordable healthcare to everyone in the United States.
References
1. Barnett, GO (1979). The use of computers in clinical data management: the ten commandments. Society for Computer Medicine Newsletter. 4: 6-8.
2. Bates, DW, Kuperman, GJ, et al. (2003). Ten commandments for effective clinical decision support: making the practice of evidence-based medicine a reality. Journal of the American Medical Informatics Association. 10: 523-530.
3. McDonald, CJ, Overhage, JM, et al. (2004). Physicians, information technology, and health care systems: a journey, not a destination. Journal of the American Medical Informatics Association. 11: 121-124.
4. Sittig, DF and Singh, H (2012). Rights and responsibilities of users of electronic health records. Canadian Medical Association Journal. 184: 1479-1483.
No comments:
Post a Comment