Provider Directories, Interoperability, and What Medicaid & MA Plans Can Learn from Real-World Connectivity: A Conversation with Defacto Health

By Mark Scrimshire, Chief Interoperability Officer, Onyx  

Accurate, accessible provider directory data sits at the foundation of almost every function in our healthcare system: member access, network adequacy oversight, referral management, prior authorization automation, and CMS-driven transparency initiatives. As CMS pushes toward nationwide standardization — including the forthcoming National Provider Directory — Medicaid and Medicare Advantage plans are facing mounting pressure to modernize how they publish and maintain their directories. 

At Onyx, we see firsthand how complex this challenge can be. Directory data often lives across multiple systems, updates flow inconsistently, and API implementations vary widely. That’s why I was particularly struck during a recent FHIR experts dinner in Washington, D.C., when Ron Urwongse, Co-Founder of Defacto Health, shared his experience connecting to provider directories across the country. Defacto ingests and normalizes provider data from as many plans as they can reach, giving them a unique, real-world vantage point into what’s working — and what isn’t. 

Ron’s perspective is especially timely for Medicaid and MA plans preparing for the next phase of interoperability. What follows is an excerpt from our conversation, where we discuss the value of provider directories, what Defacto sees on the ground, and how modern API onboarding can help plans stand up a standards-based directory in a matter of weeks. 

Q&A with Ron Urwongse, Defacto Health 

Q: Why are provider directories so central to interoperability right now? 

Ron: There are a multitude of reasons, but let’s boil it down to two leading ones: 

1. Directory data itself (information about providers, their relationships, and how to contact/exchange data with them) is important and needs to be exchanged in a standards-based fashion. That information, now, is being exchanged in highly manual ways (portal data entry, spreadsheets, e-mails, phone calls) and that introduces room for error, increases administrative burden, and delays to screen, credential, and onboard providers into payer networks. So getting that information more interoperable will help all parties: payers, providers, patients, and regulators. 

2. Then, which is why I think you’re asking the question, directories are important in support of non-directory transactions (clinical data exchange, patient access to their data, prior authorization, etc.). To be able to automate these transactions, it needs to be possible to know what endpoints belong to what providers, and in what contexts. This requires good endpoint information and good affiliation information. That exists in pockets right now, and there’s work towards building national infrastructure to support that, but we’re not quite there yet. 

Q: You connect with directories from dozens of health plans. What patterns are you seeing, especially in Medicaid environments? 

Ron:  It was a rough start when payers started publishing their APIs in 2021. Only a handful were working as expected in that time, and it’s been an epic journey to cycle through over a hundred payer APIs, determine how queryable they are, how conformant they are, report any issues, test the resolutions, and repeat that process until the APIs work. On the State Medicaid side, we are seeing that most of them are queryable, and they are being implemented in a standard, predictable way. This is likely due to common vendors managing the upstream data, and the downstream APIs. It is also because the plan-network relationships with State Medicaid agencies are less complicated to represent in the APIs versus their private payer counterparts. What we’ve observed is that the long pole in the tent is typically not the API itself, but the ETL from upstream data systems into the APIs. If you have a standard, repeatable process to get the data out of the upstream systems, you’ve mapped that data to FHIR resources and Plan Net relational models, then it’s more straightforward and scalable to get the data into a proper FHIR API. 

Q: Your team recently connected to several Medicaid directories that had transitioned to Onyx’s implementation from a previous vendor. What stood out during that process? 

Ron:  What stood out was the open communication. There are named individuals we can contact when we see issues with the APIs. We produced a spreadsheet for the Onyx team with all of the APIs that you’re supporting, where we are in our evaluation of those APIs, whether we’re regularly querying them or not, and any blocking issues. We revisit that on a monthly basis, and continuous progress is being made. There’s a migration from the previous vendor platform to Onyx, and both the previous vendor and Onyx are communicative on the ETA of sunset and the availability of the new API. When we’ve seen another API platform vendor exit the market (or stop supporting) payer APIs, it was very abrupt, and it wasn’t clear who the new payers ended up with. We often heard ‘you should contact the payer to see what their plans are’. In this situation, both the previous vendor and Onyx + Abacus have handled the transition process very professionally. 

Q: As CMS moves toward a National Provider Directory, what should plans be doing now to prepare? 

Ron:  

1. They should make sure that their APIs work. The National Directory, and this is clear in some of the draft MA Plan Finder requirements, will necessarily ingest data from payers’ Provider Directory APIs. The National Directory wants to represent the plan + network information in its own data set, and it needs payer APIs to work. A good start would be to ensure that payers are able to support the MPF requirements. 

2. They should make sure their upstream data repositories can easily map to FHIR data models and that they are able to appropriately master their data. The first part is important because that is often the bottleneck or blocking issue when payers are unable to produce proper Provider Directory APIs. The second part is important, because eventually, the national directory will have provider-attested data that could serve some sort of ‘safe harbor’ role in industry (where if payers use that data, and align with that data, they can avoid penalties around directory errors).  

3. They need to know where they stand from a directory accuracy standpoint. The era of ‘everybody’s bad, so the regulators can’t enforce anything’ is over. We see actions from states, from employer groups, and from consumer groups. Yes, every payer had directory issues, but some are improving faster than others. There’s quite a range of directory accuracy metrics across payers, and it’s important for payers to know where they stand relative to their competitors, and relative to CMS itself. 

Q: From your vantage point, what does “excellent implementation” look like? 

Ron:  We’ve covered a lot of that in the previous questions, but I can bring it all together, and we can work our way backwards from the APIs themselves. 

1. Conformant APIs that CMS is able to use to query, to populate MA Plan Finder and eventually the National Directory 

2. Upstream data repositories that can map to FHIR data models 

3. A mature data mastering process. A single source of truth for the entire enterprise. The ability to align the data set with an industry source of truth like NPD. 

4. A view towards a world where payers start to differentiate among each other on the quality of their data. We should think about this in two ways: 

1. Their directory data, to more accurately represent their network and their providers to their beneficiaries, groups, and regulators 

2. Using directory and endpoint data to get more complete and accurate access to clinical data to support quality measures, risk adjustment, value-based care. This will also help payers become more competitive. 

3. We will see a world in which data completeness and quality become table stakes. The health insurer of the future will have solved this problem. Payer orgs that do not solve this problem will be left behind. 

Q: What advice would you give Medicaid and MA plans modernizing their directories? 

Ron:  Beyond what I mentioned in terms of excellent implementation, there are two other things I’d suggest payers look like relative to their directories: 

1. Be strategic on data quality improvement. Many payers (especially at the state level) can boil down around 50% of their directory errors to 10-15 large health systems in their market. You can have conversations and strategize with those health systems to get good data. You can have an unemotional, empirical discussion on the relative quality of their data, and ask them how they can get you good data, and what it will take to fully realize that. Don’t just depend on a data cleansing vendor to solve the problem. As an industry, we want to solve these problems at the source – and that is within the 4 walls of a provider org. 

2. Start to look at appointment scheduling. If a patient can make an appointment with a doctor at an address, that address is more likely to be correct. Not only that, but if you sort your directories based on appointment availability, your members won’t have to hunt and peck and call 20 different providers to get a timely, nearby appointment. Take a look at the work that Defacto is doing with Optum, Zocdoc, b.well and others at the January Connectathon. There’s real interest from payers on sourcing appointment data and using it to supplement/correct directories. And there’s real interest from provider orgs and EHRs to make this data available. 

What This Means for Payers 

Provider directories are no longer static webpages or spreadsheets maintained in isolation. They are dynamic, high-value assets that must be machine-readable, standards-based, and continuously updated. Plans that move early will see benefits beyond compliance: 

• Faster prior authorization automation 

• Cleaner provider matching 

• More accurate network adequacy assessments 

• Improved member experience 

• Greater readiness for CMS’s next round of interoperability requirements 

At Onyx, we’ve refined our onboarding process, so plans can stand up a Plan-Net–compliant directory in as little as a few weeks, even in complex Medicaid environments. When partners like Defacto can easily consume that data, the entire ecosystem benefits. 

Where Plans Go From Here 

My conversation with Ron reinforced a simple truth: the industry already knows what “good” looks like. The technology is proven. The standards exist. The pressure — and opportunity — is here. 

Medicaid and MA plans that take the next step now will be well-positioned not just for CMS compliance, but for a future where directory data flows cleanly across the care continuum. 

If you’d like to learn more about how Onyx helps plans stand up standards-based provider directories quickly and reliably, we’re here to help.  

Request a Demo