The CMS National Provider Directory: A New Era of Interoperability

It’s not often in healthcare IT that we can get near-total consensus on the need to implement something with national implications, but a cursory glance at the buzz around the proposed National Provider Directory from CMS will reveal just that. Talk to anyone involved in the interoperability space and they will tell you that the need for a National Directory is critical to accomplishing many of the goals of the Advancing Interoperability final rule (CMS-0057-F). The need for a Domain Naming System (DNS - the technology that underpins the resolving of web addresses to their servers’ IP addresses)-style endpoint directory, as well as a centralized source-of-truth for provider data has continued to gain traction in recent years, as we look towards a future where provider data isn’t so cumbersome to exchange, and where provider organizations’ FHIR endpoints are discoverable without needing to pick up a phone or crawl the web hoping to stumble upon some API documentation.


CMS has ramped up the hype machine for this initiative in recent months - letting the industry know in plain language that a National Provider Directory is coming. Since the middle of 2024, CMS has been working with the Oklahoma Insurance Director on a narrow-scope pilot, creating a directory of providers in the state of Oklahoma who are credentialed to provide services to members of any Qualified Health Plans (QHPs) on federally-funded Oklahoma exchanges. Through this pilot, both CMS and the interoperability community hopes to learn more about the feasibility of such a directory at national scale, and to inform future implementers on best practices learned through the Oklahoma initiative.


Since its inception in 2012, FHIR has been playing an ever-increasing role in the standardization of healthcare data exchange. In fact, the FHIR standard has become almost ubiquitous when it comes to the push for true interoperability within healthcare data and health IT in general. When we think of networked exchange of data, it’s easy to think of examples such as email or the world wide web - both underpinned by standards that make it easy to use and easy to implement into software applications. This is in large part due to technologies such as DNS - the Domain Naming System. Each web server is indexed using the Internet Protocol (IP) address - a string of numbers separated by period symbols in its 4th version, the most widely used standard for addressing web servers. Now, you and I have no easy way to find a web server’s IP address without first knowing where to look and how to find it. This is where DNS comes into play, it will resolve a web address url to that server’s IP address - for example when you type ‘www.google.com’ into your browser, the DNS will resolve that to Google’s IP address for you automatically. Wouldn’t it be wonderful if such a thing existed for FHIR servers instead of just web servers? What if we could point our FHIR API at a provider organization’s name or some unique identifier and have that automatically resolve to their FHIR API endpoint for us? Well, the National Provider Directory could do something similar, and no less impactful.


Just as with DNS, the National Provider Directory would need to have its listings persisted in some standardized format that consuming applications can understand and rely upon. FHIR is the natural choice here - a standard that is intended to promote interoperability at scale, and a standard that is already being used for Provider Directories as part of the CMS Interoperability and Patient Access final rule (CMS-9115-F). This rule mandated that health insurance payers with government lines of business (Medicare, Medicaid, etc.) must make their provider directories available via FHIR APIs. This has seen reasonable success in allowing patients who are members of these payers to use 3rd party applications to access their covered providers and make informed decisions about their care. We can move beyond that use case and improve workflows for patients, payers, and providers alike. With a single national repository for provider data, including endpoint data, we can envision a future where various data exchanges are supported through the ease of locating FHIR endpoints to support clinical quality measurement, public health surveillance and case reporting, payer/provider data exchange, provider-to-provider data exchange, and so much more.


The work that the FHIR At Scale Taskforce (FAST) has been doing on a FHIR Implementation Guide for the National Directory should provide valuable guidance for both CMS when building their directory, and for implementers wishing to create applications that expose part or all of the national provider directory. FAST is busy working on version 2.0 of their IG, but it’s important to note that this guide doesn’t stop at providers in a FHIR-based directory, it can include other healthcare organizations such as insurance payers, vendors, and other healthcare services. If the National Provider Directory proves to be a success, then CMS should look to expand it to include these other organizations in an effort to expand the scale of this interoperability keystone, enabling greater efficiency in endpoint location and powering mandatory APIs like the Payer to Payer API, the Prior Authorization API, and the Provider Access API. Additional use cases such as Risk Adjustment, Quality Measurement, and Public Health reporting would greatly benefit from the existence of a well-maintained, up-to-date directory of Providers, Payers, Vendors and Services in healthcare.


The Trusted Exchange Framework and Common Agreement (TEFCA) can play a crucial role in the success of the national provider directory, by implementing it as part of their Facilitated FHIR Standard Operating Procedure (SOP), and including it as part of their FHIR roadmap towards an end-to-end FHIR solution for the secure exchange of healthcare data. TEFCA already required QHINs to maintain a FHIR endpoint directory as part of their technical framework, however these directories are not necessarily standardized, nor are they published anywhere outside of each QHIN (Qualified Health Information Network. It’s easy to see potential synergy with promoting interoperable exchange via TEFCA through implementation of a national provider directory. If TEFCA can leverage this same technology, it can seamlessly connect providers with each other, with payer organizations, and other reporting agencies or registries in order to facilitate the exchange of FHIR data. 


Bellese is actively involved in furthering the FHIR standard through our participation in the FHIR at Scale Taskforce (FAST). We are committed to the realization of the CMS National Provider Directory, understanding its transformative potential for improving healthcare interoperability, data access, and overall patient care. We look forward to working with FAST and industry leaders to help create this pivotal system.


Written by

Benji GrahamFHIR Evangelist