New Data Mart Helps Health Plan Meet Regulatory Provider Network Reporting

Problem to Solve

Market forces are requiring health plans to be increasingly current and transparent about their provider networks. Historically, provider directories for plan members have been outdated and riddled with inaccuracies, such as whether a provider is accepting new patients.

Additionally, with the expansion of government-run programs such as Medi-Cal, regulators are increasingly scrutinizing provider data to be sure it is timely, accurate and meets the needs of plan members. Regulators have also mandated an expanded set of data elements, increased the reporting frequencies, and implemented a structured electronic data interchange (EDI) submission process.

A health plan needed to develop a provider data mart to centralize and house provider data from multiple internal and external sources. It also needed to report its provider network data each month to Medi-Cal, using a national EDI standard. The health plan engaged Freed Associates (Freed) to oversee this initiative.

Strategy and Goals

Because the health plan’s deadline to comply with Medi-Cal’s provider network reporting requirements was more immediate than its need to overhaul its provider databases, processes, and reporting systems, the health plan decided to develop a temporary solution using existing tools and re-use them later on a more comprehensive solution. This allowed the Freed project team to focus on meeting a specific regulatory need while staying connected to the health plan’s long-term provider data needs.

Until this initiative, the health plan’s provider network reporting to Medi-Cal had been incomplete and relied on proprietary Excel templates, making it difficult to manage. The health plan and Freed identified the following steps to address the health plan’s Medi-Cal compliance requirements:

• Identify and fill project human resource gaps – This would ultimately include a project manager, solution consultant, business analysts, and developers

• Rely on a software development life cycle framework – Identify the steps to be performed at each stage of the software development process, with increased attention on requirements-gathering and documentation based on lessons learned from similar, past projects

• Create an online team collaboration site – This was necessary to store and maintain all of the required project documentation

Methodically, the health plan’s project team worked through the following stages to complete its task of regulatory compliance:

1. Understand the requirements – Up-front, the team needed to know the basics of Medi-Cal’s reporting requirements, such as: “What is a provider?” and “What types of providers are considered a part of the network, especially from a regulatory perspective?” At first glance, this task seemed simple: just include physicians, nurse practitioners, physician assistants, hospitals, and outpatient clinics as “providers.” However, should pharmacists, nurses, therapists, technicians, dieticians, and social workers also be considered part of the “provider network,” and if so, what data is available about them? Additionally, what about the entire continuum of care such as hospice, home health, long term care, and specialty centers for services such as surgery, dialysis, and therapy?

The team quickly realized the criticality of establishing in- and out-of-scope provider types, as well as clarifying ambiguous Medi-Cal data element requirements. For example, what defines a “telehealth provider”?

2. Collaborate with other stakeholders – Because all participating health plans need to meet the same Medi-Cal reporting requirements, the project team participated in a compliance collaboration group established with other health plans. The group met weekly and proved invaluable in helping members understand and validate Medi-Cal’s regulatory requirements, challenge unreasonable requirements (such as collecting individual providers’ Social Security numbers), share best-practice information and learn unique approaches for obtaining difficult-to-gather data elements. Medi-Cal came to better understand the health plans’ reporting capabilities and limitations, while the health plans learned how and why Medi-Cal would use the provider data. As both sides worked together, Medi-Cal’s reporting requirements evolved to more effectively address everyone’s interests.

3. Identify data gaps and sources – The health plan’s project team developed a complete data element inventory which captured such items as: best-available data source; frequency of data updates; required data mapping; team member data questions; and other special considerations. This inventory allowed the team to track gaps and focus on sourcing missing data.

4. Develop business logic to validate key data – From past provider network reporting efforts, the health plan understood that some provider data was prone to errors and would require extra validation because Medi-Cal’s standard allowed for zero errors. For instance, the numbers in providers’ National Provider Identifier (NPI) data were often transposed, had missing digits, or contained extra digits. Consequently, the team added a business logic component to its software to identify incorrect NPIs based on a comparison with the national NPI registry.

Results

The health plan developed, tested, and implemented a provider data mart solution to Medi-Cal’s requirements, using provider data from multiple internal and external source systems. The solution included error reporting to resolve issues among any providers with missing or invalid required data elements. Consequently, the health plan successfully met Medi-Cal’s timeline and standards for provider network reporting.

With the health plan’s compliance solution established and two separate provider network submissions accepted by Medi-Cal, the project team produced operational procedures and process flows to maintain the data mart and produce the required monthly report on an ongoing basis. The solution’s flexible framework allows the heath plan to incorporate additional provider types and/or data elements to meet any future expanded provider network reporting.

Conclusion

As regulators and consumers focus on provider networks and demand quality provider data, health plans that improve their legacy provider databases stand to gain on multiple fronts. As evidenced by this project, establishing a team that understands the regulatory requirements being requested and has the ability to effectively partner with all key stakeholders, including the data-seeking regulators, is the key to success.