National Healthcare Directory Query
1.0.0-ballot - ballot United States of America flag

National Healthcare Directory Query, published by HL7 International - Patient Administration Work Group. This is not an authorized publication; it is the continuous build for version 1.0.0-ballot). This version is based on the current content of https://github.com/HL7/fhir-directory-query/ and changes regularly. See the Directory of published versions

Home

Official URL: http://hl7.org/fhir/us/directory-query/ImplementationGuide/hl7.fhir.us.directory-query Version: 1.0.0-ballot
Active as of 2022-12-08 Computable Name: NationalHealthcareDirectoryQuery

Introduction

Alert: FAST is in the process of combining the three National Directory IGs into a single IG (National Directory for Healthcare Providers and Services – NDH) based on feedback from the community. The combined IG is located at: http://build.fhir.org/ig/HL7/fhir-us-ndh/branches/master/index.html. While useful information may be found in this IG, please use the combined IG as the basis for the National Directory / NDH IG standard.

The National Healthcare Directory Implementation Guide is based on FHIR Version 4.0. It was developed in cooperation with the Office of the National Coordinator for Health Information Technology (ONC) and Federal Health Architecture (FHA) with guidance from HL7 International, the Patient Administration Workgroup, and the HL7 US Realm Steering Committee.

It describes the architectural considerations for attesting to, validating, and exchanging data from a central source of validated provider data, as well as a RESTful FHIR API for accessing data from a VHDir.

Although we developed this guide from the conceptual starting point of a national source of validated provider data, we recognize that implementers may have different business needs, contexts, or use cases. Therefore, we have strived to make this guide as broadly applicable as possible. Every implementation may not use all of the content in this guide. It serves as a “floor” for the exchange of validated provider data, while describing additional data elements and capabilities that support more robust implementations.

Likewise, we provide general guidance about the technical architecture and capabilities of a central source of validated provider data, but are not prescriptive about what an implementation must include.

National Directory Profiles

The list of National Directory Profiles is shown below. Each profile defines the minimum mandatory elements, extensions and terminology requirements that MUST be present. For each profile, requirements and guidance are given in a simple narrative summary. A formal hierarchical table that presents a logical view of the content in both a differential and snapshot view is also provided along with references to appropriate terminologies and examples. In addition each profile has a “Quick Start” section which is intended as an implementer friendly overview of the required search and read operations.

  • National Directory Endpoint Qry Care Team
  • National Directory Endpoint Qry Exchange Endpoint
  • National Directory Endpoint Qry Exchange HealthcareService
  • National Directory Endpoint Qry Exchange InsurancePlan
  • National Directory Endpoint Qry Exchange Location
  • National Directory Endpoint Qry Exchange Network
  • National Directory Endpoint Qry Exchange Organization
  • National Directory Endpoint Qry Exchange OrganizationAffiliation
  • National Directory Endpoint Qry Exchange Practitioner
  • National Directory Endpoint Qry Exchange PractitionerRole
  • National Directory Endpoint Qry Exchange Restriction
  • National Directory Endpoint Qry Exchange Verification

    • National Directory Conformance Requirements

    The Capability Statements Section outlines conformance requirements for National Directory Servers and Client applications, identifying the specific profiles, RESTful operations and search parameters that need to be supported.

    Note: The individual National Directory profiles identify the structural constraints, terminology bindings and invariants, however, implementers must refer to the conformance requirements for details on the RESTful operations, specific profiles and the search parameters applicable to each of the National Directory actors.

    Primary Authors: Dan Chaput, Alex Kontur, Brian Postlethwaite, Bob Dieterle, Sean Mahoney