This page is part of the National Directory of Healthcare Providers and Services (NDH) Implementation Guide (v1.0.0-ballot: STU1 Ballot 1) based on FHIR R4. . For a full list of available versions, see the Directory of published versions
Today, a variety of health and social care organizations maintain directories, encompassing providers, payers, health information exchange organizations (HIEs/HIOs), health information service providers (HISPs), social services organizations, government agencies, and credentialing organizations. Despite their crucial role, activities associated with health and social care directories are often dispersed, uncoordinated, and lack interoperability. Consequently, the industry invests considerable time and resources to register and validate demographic information for individual and organizational providers for various purposes, including information exchange, referrals, licensure, credentialing, certification, and payment.
The underlying concept of this guide is to illustrate the information flow from the NDH data source to distributed workflow directories. We visualize the NDH operating as a “source of truth” for an extensive range of provider data, designed to support local business requirements and use cases. A local environment could conveniently access all or a selected portion of the data it requires from the NDH, assuring the information’s accuracy. If needed, a local environment could supplement NDH data with additional data sourced or maintained locally. For instance, a local environment managing provider credentialing might depend on the NDH for demographic information about a provider (e.g., name, address, educational history, license information, etc.), but might also request supplementary information from the provider, such as work history, liability insurance coverage, or military experience. Similarly, we envisage the NDH sharing information with other systems, individual end users, or the public.
This guide does not enforce any mandates on distributed workflow directories in terms of their overarching design, technical framework, or competencies. Rather, it presents a suite of standard Restful FHIR APIs that these directories may opt to use for revealing the information they’ve gathered from the NDH for their distinct use cases. The adoption of these standard Restful FHIR APIs is entirely optional and it’s up to each distributed workflow directory’s discretion to incorporate them as needed. The Distributed Workflow Directory Restful FHIR APIs is shown in the as red call out in the diagram below.