A New Pricing Model for Medicaid Management Information Systems (MMIS)

The Centers for Medicare & Medicaid Services’ (CMS) recent $5 billion-per-year commitment to modular Medicaid Management Information System (MMIS) technologies has signaled a long-overdue paradigm shift in the way we think about Medicaid information systems. This shift is already beginning to revolutionize and improve a health care system that over 73 million people depend on every day. Currently, MMIS services is at least a $7 billion-per-year industry. As the influence of modular, cloud-based, and SaaS (Software as a Service) technologies continue to exert themselves on MMIS, this industry will mature and move into the 21st century. One exciting aspect of this maturation will be a new pricing model for MMIS services.

Verbus Counts

Currently, here’s the way pricing an MMIS works. A state enters into a contract with a vendor, with the vendor agreeing to build a huge, customized solution for the state’s MMIS needs. These projects take years to complete, sometimes they don’t get completed at all, and they cost tens of millions  of dollars to implement and with millions in annual maintenance. Worse still, IT advances at such a fast rate that these systems quickly become clunky and unwieldy. States are left with two  options: either limp along with the broken system, affecting health and business, or, scrap the whole thing, entering into another lengthy and inefficient program.

Another major disadvantage to this pricing model is that the cost for MMIS solutions is set irrespective of how many Medicaid members there are. So, for example, in Texas, there are 4 million people on Medicaid, whereas in California, there are 8 million people. Yet, both states pay roughly the same amount for their MMIS solutions.

Frustrated by this inefficiency, CMS is also now strongly encouraging states to work together in developing MMIS solutions that have shareable features. What follows is a blueprint for how this cross-collaboration might look.

The gross inefficiency of the current model is even easier to see if you picture it in an everyday example. Imagine Texas and California as two independent groups of 40 and 80 people respectively, both of which need to travel from one city to another. Under the current pricing model, to get where they’re going, each group needs to buy itself an entire plane—they pay for the crew, the captain, and all amenities. Even the peanuts. And both groups have to buy a 747—they can’t buy a smaller, less expensive plane that better reflects how many people are in their party. When the flight is over, and they need to go to a different city, they have to scrap the old plane and buy an entirely new one. Obviously, this way of doing things would be ridiculous—and yet, it’s pretty much exactly what happens in the MMIS space when the state needs a new system.

Following this airplane example, it would obviously be much more efficient to have each state buy tickets for a flight rather than purchasing, staffing, and scrapping an entire plane every time it wanted to travel from point A to point B.  What we’re ultimately talking about then is transitioning MMIS to MMIS as a service, which means that it will be based on transactions related to how many members there are enrolled in Medicaid in a given state.

While this may sound newfangled, the older pricing model is already being successfully challenged in the wider tech industry. Examples such as Salesforce, Microsoft Office 365, and Dropbox prove that this new way of thinking about technology—as a service—is a viable and flexible alternative to the older monolithic model.

Let’s return for a moment to this concept of a pricing model based on the number of members enrolled in Medicaid. Consider a systems integrator module, which is a fairly universal component of any new modular MMIS—a systems integrator manages the communication and collaboration among all other modules that make up an MMIS. The software infrastructure for this module is complex—a veritable buffet of applications, which would be hosted on various private servers, all with independent costs of operation. If this were a buffet, this infrastructure would represent all the various menu items you could order. Under a new pricing model based on SaaS principles, the state wouldn’t need to worry about all the different moving parts of the software infrastructure. It would simply buy its buffet ticket and be served whatever it felt like eating for dinner.

And of course, pricing ought to reflect how many people the state is bringing to the table. At a buffet, on a plane, or in most service-industry transactions, you’re charged by the head—it’s simply a fairer and more mature way for an industry to conduct business. So, the fewer people your state has enrolled in Medicaid, the less you should pay for the components of your MMIS solution. And, the more members that are enrolled overall, the more these shared costs will go down:

What this table shows is that, although states with more members would be charged accordingly, costs of MMIS components under the new pricing model would plummet as more and more states enrolled in a given shared service. It’s a simple illustration of economies of scale.

In an earlier article, we likened MMIS to a hotel. Under the current model, each state is building for itself an entire hotel, and then bulldozing and building a new one whenever something goes wrong with the old one. But in a modular, SaaS-based model, each state is renting a floor in one hotel together. And because the states are sharing the building, they also share costs like utilities, which drives expenses down. Again, this is a simple example of economies of scale.

To make it more concrete, let’s refer to the chart above, a state like Texas with 4 million people on Medicaid would pay $0.26 per member per month for its systems integrator. California, with 8 million, would pay $0.17, and New York, a state with 6 million on Medicaid, would pay $0.20. But, if all the states go in together, they’d pay only about $0.07 per member per month.