6 considerations for provider management modernization

Providers are the cornerstone of any Medicaid program. So it’s important to protect this critical partnership when modernizing a provider management module.

Today, updating provider management services is accomplished through the use of modularity in system management and procurement. And while modularity offers states many benefits, it also presents a fundamental shift.

Key considerations to lay the groundwork for provider management modernization

In the past, states had to manage a single vendor for all aspects of a Medicaid Management Information System (MMIS). Now they must oversee multiple vendors to fulfill various Medicaid program functions. As modules are added to the MMIS, contract coordination and efforts across multiple vendors become more demanding. It’s important that the effort is planned carefully, with an understanding that the process is complicated. How long will the provider implementation take? That depends on the complexity of the state’s provider enrollment and configuration rules.

The following key points are based on many years of experience streamlining provider enrollment and administration across a variety of industries, including Medicare, commercial and Medicaid. These points are shared here in a spirit of collaboration, with a goal of helping states successfully manage change by leveraging some of our lessons learned.

1. Identify the project lead (it may not be the most obvious person)

When embarking on a provider management modernization effort, it’s important to identify a committed subject-matter expert (SME) who will drive the initiative for the life of the project. And while it may seem obvious to have a director serve in this role because of their vast knowledge of the Medicaid program, we encourage you to think beyond this person. Why? Because an executive sponsor is involved in many initiatives across the Medicaid program, so devoting their undivided attention to this singular project may be unrealistic.

• Identify a SME(s) who can be fully dedicated to the project and whose position can be backfilled to mitigate their being pulled away to address other business operations.
• Consider offsetting the additional cost burden of backfilling a dedicated SME(s) by taking full advantage of the enhanced federal financial participation (FFP) rate for state design, development and implementation (DDI) expenditures.

2. Gather your data

It’s not uncommon for a state to have legacy contracts with multiple vendors who manage data and administer the Medicaid system. Months before your project begins, think about initiating a data evaluation and cleanup process to reveal which vendors manage which data, where the required data is stored, and how you will gather information and data from them. This will help identify any gaps in the existing data set so the vendor overseeing your provider management module has the necessary data and business process definitions at project launch.

For example, an evaluation could reveal answers to questions like these:

• Is your system using pure National Provider Identifier (NPI) or a crosswalk?
• Does your system have unique provider data fields?
• Has your system reused data fields where there could be 2 different kinds of data in the same field?

This insight can put you on a solid path for the data conversion effort and allow you to avoid timeline delays that often are months long.

3. Be clear about how your data is formatted

When developing your request for proposal (RFP), be specific about how the data will be presented to the vendors. The best way to do this is to include a sample format within the RFP. This critical information allows vendors to evaluate the data fields and identify what (if anything) is missing so they can accurately estimate their level of effort and include that in their proposal response. If you’re not sure what format your data is in, detail that fact in the RFP and the vendors will build their schedule and cost model accordingly to minimize surprises.

4. Facilitate knowledge transfer

Transitioning to a new vendor is a delicate process and should be approached as a team effort to avoid delays and costly change orders from both legacy and incoming vendors.

Often, there is no incentive for the legacy vendor to collaborate with the incoming vendor. If contractual guidelines around knowledge transfer do exist, it’s possible the language may not be enforceable in the current environment. When you renew contracts, it’s recommended that you include more direct provisions that hold the legacy vendor accountable, require them to be responsive and compensate them for any new activities.

Have the legacy vendor at the table to validate that the agreed-upon approach for introducing a new module will not result in unexpected problems for other parts of the legacy system. Task the legacy vendor with reviewing the conversion plan as well as completing full integration testing. Testing all aspects of provider information in the MMIS may take longer than expected and may require multiple cycles before it aligns with user acceptance testing (UAT), so be sure to allow enough time. (Amendments to the current contract may be necessary to ensure the legacy vendor is paid for these activities.)

A system integrator (SI) vendor should also be at the table to help define a complete solution. The SI may be responsible for the service bus, controlling the communication across modules and should be able to provide valuable insights into how the modules should communicate and what data is needed.

5. Provide enough time to develop project artifacts

Projects of this nature often start with aggressive timelines and then, for a variety of reasons, fail to meet their projected timelines. To get them right, project initiation documents such as the project management plan, communication plan and system design documents can take a series of meetings and frequent communication between the state and the vendor. Set the team up for success by building in a flexible review cycle that gives both the state and vendor ample time to review and revise documents according to the complexity of each document (for example, 3–10 days each per review cycle). Time and thoughtfulness on the front end will help avoid issues on the back end so you can hit timeline targets.

6. Leave room for technology advances

Technology advances quickly, easily outpacing the speed with which requirements are developed and deployed. Unfortunately, by the time vendors bid on your RFP, some of the requirements may be better served by newer solutions while others may be obsolete. Stay current by including a section in your RFP that allows vendors to highlight technological advances or process advances that could be employed outside of the traditional requirements set. This allows you to achieve modernization without disruption and also helps ensure that your requirements will be met now and in the future.