Tom Wriggins, Principal Solutions Architect, SAS Global Security Intelligence Practice 
Victor Sterling, Principal Industry Consultant at SAS
In 2010, the Affordable Care Act ushered in a new era for Medicaid Modularity, an approach anchored by breaking down large, monolith systems into smaller, more nimble and self-contained modules that can de-risk healthcare delivery and unlock innovation. More broadly, Medicaid Modularity is about improving states’ Medicaid Management Information Systems (MMIS).
In 2016, the Centers for Medicare and Medicaid Services (CMS) followed by issuing guidance on how states should move forward with modularity of their MMIS with a goal of providing enhanced flexibility to change systems. This was achieved through the implementation of smaller, more agile software and services that no longer required full system implementations of financial agents, such as banks. By doing so, states could shift away from large, expensive, lengthy and high-risk projects, in favor of lower-risk modularity that features interchangeable CMS-certified components and certification achieved ahead of full MMIS system replacement.
For states at various stages of the MMIS procurement process, it is important to understand what is involved in the adoption and deployment of MMIS modules from a cost and resources perspective, as well as best practices to ensure long-term success.
Current State of the Market
In 2016, CMS expanded the scope of Federal Financial Participation beyond the traditional single MMIS in an effort to encourage a multi-system modular approach for MMIS. It required every state to have three or more modules, but given varying factors like population size and Federal Medical Assistance (FMAP) rate, the number of modules and their functions may be different for each state. Furthermore, language was included that not only supported a claims processing engine but also reporting and administrative tools to promote more efficient state Medicaid programs.
While some states are embracing change, others have been slower to modernize. However, as contracts expire, even hesitant states are looking hard at new technologies for modularity. Prior to 2016, large vendors controlled the market and monopolized state MMISs. If states were happy with their Program Integrity (PI) systems, but not satisfied with the payment systems, states had no choice but to stay with the vendor. The new modularity standard allows states to keep large vendors to leverage the benefits but gain the flexibility to carve off different pieces of the business, partner with new vendors and improve other systems.
4 Lessons Learned in Rolling Out MMIS Modularity
Some states think if you’ve seen one MMIS, you’ve seen them all. However, given the uniqueness of each state and its requirements, the path to Medicaid modularity is far more nuanced. That said, based on my own direct experience with MMIS modularity implementations, there are a handful of takeaways to help guide states through the process:
1. Timing is Crucial in Implementation – As states begin to consider new approaches for their Medicaid modularity, it is important to gain a firm handle on the level and type of resources needed for the implementation of modular systems, including the time and staff required. During the more intense implementation phase, state experts may need to spend several hours a day with vendors or in meetings reviewing implementation materials and going through the testing process. Given their day jobs and other tasks, state personnel will benefit from reducing this time investment with vendors, while moving more responsibility to them. However, having the right people and enough time for implementation and testing is crucial. Be sure there is a designated subject matter expert on the stateside to walk through every aspect of implementation with vendors.
2. Data Gathering Modules Should Come First – While each MMIS will have different modules, based on data gathered from RFPs, states are investing in an enterprise service bus (ESB) or data warehouse (DSS) because they’re versatile and incorporate data feeds from other modules with legacy vendors. States will be able to get around long-term issues by implementing DSS first because data mapping from an old to a new vendor is less problematic when setting up a new hub and conducting tests with the DSS. In terms of which modules come first, states should consider when data models change, as there’s a lot of rework that happens. The source system, the data repository, should come first and everything that reports the data should come after that. The underlying goal is to have the original data source be stable so everything else can flow reliably after that.
3. There’s Such Thing as Too Much Security – The Federal Risk and Authorization Management Program (FedRAMP) has placed security front-and-center when it comes to how federal agencies adopt and use cloud services. While focused at the federal level, there have been implications for state agencies that aren’t fully versed on where and when security protocols must be put in place. Certifications and analysis of security requirements cost money. The more you can understand practical cost feasible and effective security measures that can be put into place – when required – the better chance you have of avoiding being burdened by unnecessary costs and delays
4. Know Your Budget – Many vendors look at state allocation to see the budget before agreeing to the opportunity. Some states are not doing this research and end up putting forth a budget that’s much lower than what the requirements demand. On top of man-hours, states need to take into account the possibility of failed implementations, which can cost up to four times the budget. Not all state budgets are the same, however, and states should be encouraged to track and communicate with other states with similar demographics. For example, states with more rural populations will likely benefit from similar-looking modules, which means these states can glean valuable information from one another.
Importance of Data Analytics
The modularity push changed the criteria for MMISs. For example, PI systems previously profiled providers enrolled in the system, compared them against their peer group and identified providers who were statistically anomalous when it came to provider claims, patients, or other outliers. But the increasing levels of sophistication by bad actors now requires predictive analytics and machine learning to be able to look beyond traditional patterns and anomalies.
For example, psychiatrists may in some cases perform complementary care functions, such as ordering an echocardiogram or heart medicine. An OB/GYN may try and bill patients for mental health group therapy classes which reimburses at a higher rate. In each case and so many others, fraud activities can be missed unless data analytics looks across providers and analyzes similar data sets, not just by specialty.
Advanced analytics are empowering states to have dashboards of their data, ask questions around what their data actually means and turn that data into actionable insights. CMS and other bodies are interested in what will happen moving forward, how advanced analytics can be used to predict future states and outcomes and how proposed policy changes will affect levels of care and future budgets.
Expiring state contracts are leading to an evaluation of MMISs and which modules are the best fit for current and future needs. Data is core to this process and to ensuring the implementation of the right modules for their MMISs. Having systems that can handle large data sets, AI and machine learning, as well as be scalable and nimble, will be key in future procurements.
About Victor Sterling
Victor Sterling is a Principal Industry Consultant at SAS. Prior to SAS, he was the Chief Information Officer of Arkansas Medicaid. SAS is the leader in business analytics software and services, and the largest independent vendor in the business intelligence market. Through innovative solutions, SAS helps customers at more than 70,000 sites improve performance and deliver value by making better decisions faster.
About Tom Wriggins
With over 30 years of healthcare experience, Tom Wriggins brings practitioner-level expertise to his role as a Principal Solutions Architect with SAS. Tom combines extensive clinical experience with data and analytics knowledge to help government health care entities crack down on fraud and improper payments. He has led multidisciplinary teams that have delivered large and complex data solutions for government health agencies, as well as created fraud and abuse investigative training programs.
