AINPI·ainpi.dev
NDH·2026-06-25
Release update · 2026-06-25

The endpoint record is the address.And nothing else.

Endpoint address present
100%
Metadata extensions used
0%
Spec fields with no FHIR home
5 of 9

H44 published: of the 9 endpoint-metadata fields the HTE submission spec collects, 5 have no home in the NDH FHIR Endpoint profile (STU1), and the extensions that could carry the others are 0% populated across all 114,071 FHIR-REST endpoints.

Read the full report →
methodology v0.7.2-draftNDH 2026-06-25

2026-06-25 update: what is actually in an NDH endpoint record? (H44)

The CMS provider-directory community is working through how endpoint data should be submitted and structured. Fred Trotter's HTE data-release spec asks submitters for nine endpoint-metadata fields. That raised a question worth measuring before the design hardens: of those nine fields, how many does the current NDH FHIR Endpoint model even have a place to store, and how many are populated today?

H44 answers it in two layers.

Layer 1: where do the nine fields live in the FHIR model?

Mapping each submission-spec field against the published NDH Endpoint profile (STU1 v1.0.0):

Submission-spec fieldHome in STU1
fhir_endpoint_urlEndpoint.address (core element)
fhir_endpoint_typeconnectionType + the endpoint use-case extension
fhir_endpoint_smart_capabilities_urlpartial. The dynamic-registration extension declares SMART/UDAP support, not the .well-known URL
fhir_general_sandbox_urlpartial. The environment-type extension is a code (production/test), not a URL
fhir_endpoint_developer_documentation_urlnone
fhir_endpoint_developer_signup_urlnone
fhir_endpoint_swagger_urlnone
fhir_endpoint_openapi_urlnone
fhir_specific_sandbox_endpoint_urlnone

Five of the nine have no element or extension in STU1. Collecting them through the CSV submission spec produces data with nowhere to land in the FHIR representation until a future version of the IG adds extensions. That is a deliberate decision worth making on purpose, not by default.

Layer 2: how populated are the fields that do have a home?

Across the 114,071 FHIR-REST Endpoint records in the 2026-05-08 release (connectionType.code = hl7-fhir-rest; Direct Trust messaging addresses, 91.6% of the Endpoint table, are out of scope because they are not queryable APIs):

  • Endpoint.address: 100%. Every FHIR-REST endpoint has a URL.
  • payloadType: 100%. Every record declares its content type.
  • endpoint use-case extension: 0%.
  • SMART/UDAP dynamic-registration extension: 0%.
  • environment-type extension: 0%.
  • FHIR-version extension, secure-exchange-artifacts, trust-framework, usage-restriction: 0% each.

The endpoint records carry the two required core fields and nothing else. Every optional NDH extension that could describe an endpoint is unused.

What this means for the endpoint discussion

Two practical takeaways for anyone deciding how endpoint data should be modeled and submitted:

  1. The submission spec is filling a real void, not duplicating existing data. There is no endpoint metadata to migrate or remap; today the NDH knows an endpoint's address and payload type, and that is the whole record.

  2. SMART capability is mostly discoverable without a declared field. A separate AINPI crawl (H1-H5) found that 81.6% of distinct FHIR-REST hosts already serve a valid SMART .well-known document. So the smart_capabilities_url field matters most for the minority of hosts a crawler cannot reach on its own, rather than for the majority that already advertise it.

Method and limits

Extension presence is detected by scanning each serialized Endpoint resource for the extension's canonical URL. That is an upper bound on real usage. It catches the extension wherever it nests, so a 0% result means the extension genuinely does not appear, not that it was undercounted. The 81.6% SMART figure is measured over distinct FHIR-REST hosts (2,974), not over all 114,071 endpoint records; read it as host-level discoverability.

Finding page: https://ainpi.dev/findings/endpoint-metadata-coverage Compute script: analysis/h44_endpoint_metadata.py

— Eugene Vestel, FHIR IQ