Endpoint metadata coverage vs the HTE submission spec
The HTE data-release spec (ftrotter-gov/HTE_data_release_specifications) asks submitters for nine endpoint-metadata fields. H44 maps each against the NDH FHIR Endpoint profile (STU1 v1.0.0): two have a structured home (`fhir_endpoint_url` → `Endpoint.address`; `fhir_endpoint_type` → `connectionType` + the use-case extension), two map partially (SMART capabilities → the dynamic-registration extension; general sandbox → the environment-type code), and five have no representation in STU1 at all — developer-documentation, developer-signup, swagger, OpenAPI, and per-instance sandbox URLs. Adopting the spec for those five needs STU2 extensions or out-of-band storage, not data entry. The fill rate of the fields that do have a home is measured against the FHIR-REST Endpoint records.
Headline
The HTE submission spec collects 9 endpoint-metadata fields. Mapped against the NDH FHIR Endpoint profile (STU1 v1.0.0): 2 have a structured home, 2 map partially, and 5 have no representation in STU1 at all (developer documentation, developer signup, swagger, OpenAPI, and per-instance sandbox URLs). Adopting the spec for those five needs STU2 extensions or out-of-band storage, not data entry. Across 114,071 FHIR-REST Endpoint records in the 2026-05-08 NDH release, the fields that DO have a home are sparsely populated: endpoint use-case 0.0%, SMART/UDAP dynamic-registration 0.0%, environment-type 0.0%.
4 / 9 = 44.44%
unit: count
What this means
CMS publishing the data
Five submission-spec fields (developer docs, signup, swagger, OpenAPI, per-instance sandbox URL) have no element or extension in the STU1 Endpoint profile. Collecting them via the CSV spec creates data with nowhere to land in the FHIR representation until STU2 — worth deciding deliberately, not by default.
FHIR implementers
Endpoint metadata is sparse in the current NDH. Do not assume the use-case, dynamic-registration, or environment-type extensions are present; check per record. SMART capability is largely auto-discoverable by crawl (81.6% of distinct hosts per H1–H5), so the declared field matters most for the crawl-invisible minority.
Payer data teams
If you build against the new submission-spec fields, the developer-docs / swagger / sandbox URLs will arrive out-of-band (not in the FHIR Endpoint resource) until the IG adds extensions. Plan a side-channel rather than expecting them in the bulk export.
Methodology readers
Extension presence is a JSON-wide canonical-URL scan — an upper bound on real usage, reported as a presence scan, not a strict cardinality count.
Null hypothesis
Every field the HTE submission spec collects already has a home in the NDH STU1 Endpoint profile, and the FHIR-REST Endpoint records populate those fields at a high rate.
Denominator
FHIR-REST Endpoint records in the pinned NDH bulk export (`connectionType.code = 'hl7-fhir-rest'`, 114,071 at 2026-05-08 per H28). Direct Trust HISP addresses (the other 91.6% of the Endpoint table) are excluded — they are clinical-messaging addresses, not queryable FHIR APIs.
Data source
Structural layer: the published NDH STU1 Endpoint profile (hl7.org/fhir/us/ndh/STU1). Empirical layer: one capped BigQuery scan of `cms_npd.endpoint`, presence-scanning the serialized resource for each NDH extension's canonical URL. Compute script: `analysis/h44_endpoint_metadata.py` (capped via `bq_job_config()`). Cross-references H1–H5 (SMART `.well-known` discoverability) and H28 (FHIR-REST vs HISP split).
Notes
Two layers. STRUCTURAL: each of the nine submission-spec fields is mapped to its home in the published NDH STU1 Endpoint profile (hl7.org/fhir/us/ndh/STU1). 'mapped' = a core element or extension carries the exact value; 'partial' = a related element exists but does not capture what the spec asks for (e.g. environment-type is a code, not a sandbox URL; dynamicRegistration declares SMART/UDAP support, not the .well-known URL); 'none' = no element or extension in STU1. EMPIRICAL: presence of each mappable NDH extension is detected by scanning the serialized Endpoint resource for the extension's canonical URL, which is an UPPER BOUND on real usage (it catches the extension wherever it nests) — reported as a presence scan, not a strict cardinality count. Denominator is FHIR-REST endpoints (connectionType.code = 'hl7-fhir-rest'); Direct Trust HISP addresses (91.6% of the Endpoint table per H28) are excluded because they are not queryable FHIR APIs. Cross-reference: H1-H5 found that 81.6% of distinct FHIR-REST hosts already publish a valid SMART .well-known by crawl, so the SMART capability is largely auto-discoverable even though the NDH record rarely declares it — the submission-spec field is most valuable for the minority of hosts that are not crawl-discoverable. Supporting context (not spec fields): FHIR version declared on 0.0%, payloadType present on 100.0%.
Get the next finding in your inbox. One email per release, no filler.