What went wrong for Medi-Cal and how to avoid “copying” the calamity.
Nearly 10 years and $9 million later, Medi-Cal (California’s Medicaid) pulled the plug on their Medicaid Management Information System (MMIS) modernization project with the Xerox Corporation. The project to replace the aging system originally went to bid in 2007, and was beset by challenges throughout its entirety, ultimately resulting in waste and the delay of care. The relationship between Medi-Cal and Xerox may never have bore fruit, but there is value nevertheless in understanding why—particularly for organizations undergoing a similar process.
At the core of the problem in California was the attempted reconciliation of a hard-coded, custom project software solution and an evolving regulatory environment. Healthcare regulation is in an ongoing state of change. The period in which the project took place, for instance, saw major changes including Meaningful Use, ICD-10, the Affordable Care Act, and countless other region-specific measures, all of which required compliance at the risk of losing federal, state, and county support.
Traditional software is designed to satisfy a finite set of product requirements, and typically cannot operate outside of its intended functionality. As such, a traditional software solution (even one built perfectly in accordance with an accepted RFP) is only compliant until the next round of regulatory updates, during which it would need to change. However, changing software takes time and requires a team of engineers to revise the underlying code, so it’s not uncommon for organizations to address functionality gaps with workarounds, bolt-on modules, or organization-specific customization work—a strategy that doesn’t lend itself well to health care. The combination of changing requirements, incumbent technologies, and limited foresight was enough for Medi-Cal to realize it needed to reevaluate its strategy.
The conclusion to this debacle prompts the discussion of what California Medicaid really needed for this to work. Better yet, what would any large-scale organization operating under shifting regulatory requirements need from a software solution? Adequately maintaining compliance can only be done with a system that can readily embrace change. Workflows and logic must be configurable to satisfy evolving requirements, and that means the solution’s data model must be dynamic. Configurable platform technology gives organizations the tools to design their own workflows in accordance with their unique requirements, and it does so without the same reliance on highly technical forms of support that legacy solutions require.
The entire episode in California should be viewed as a litmus test of legacy software’s ability to perform in an environment of fluid regulation. While it is true the traditional software approach has demonstrated some success with similar projects in other states, the track record has been far from perfect. Organizations wanting assurance that something like the Medi-Cal-Xerox disaster won’t also happen to them in the future need to reconsider the status-quo approach. Configurable platform technology provides the future-proofing features needed to avoid any unwanted repeats.
