Public surface / Payer Provider Directory APIs

UnitedHealthcare Provider Directory API

This endpoint answers publicly but declares little about itself.

Current grade C

Reachability100

Capability transparency100

Interop readiness0

Observed surface

Base URL: https://flex.optum.com/fhirpublic/R4
Category: Payer Provider Directory APIs
Availability: answered 46 of the last 46 daily checks (100%)
Last answered: 2026-10-03 (answered on this run)
Vantage agreement: reachable from all 3 vantages, which are 3 hosts on one network (github-actions): one network's view sampled 3 times, not 3 independent networks

What each vantage saw

reached from 3 of 3 reporting vantages, on 1 network
Vantage	Result	What it saw	Condition
`github-actions/macos-latest`	reached	answered in 97 ms	HTTP 200
`github-actions/ubuntu-latest`	reached	answered in 291 ms	HTTP 200
`github-actions/windows-latest`	reached	answered in 188 ms	HTTP 200

Vantages on one network are one network’s view sampled several times. A rule applied to that network’s address space reaches every one of them at once and reads exactly like agreement.

Interpretation

A grade describes two public discovery documents at one point in time. It does not inspect patient data, authenticated behavior, or clinical quality.

Read the scoring method →

This endpoint's full report: what was observed, what was not, and what would change it →

What its CapabilityStatement declares, resource by resource →

Findings

Reachability100

Pass: /metadata answers with HTTP 2xx over HTTPS: reachable from all 3 vantages, which are 3 hosts on one network (github-actions): one network's view sampled 3 times, not 3 independent networksR1 Spec ↗
Pass: /metadata responded in 188 ms (median across 3 reachable vantages on one network)R2 Spec ↗

Capability transparency100

Pass: fhirVersion declared: '4.0.1' (expected 4.x)T1 Spec ↗
Pass: software name and version declaredT2 Spec ↗
Pass: 9 resource types declaredT3 Spec ↗
Pass: 9/9 declared resources document their interactionsT4 Spec ↗

Interop readiness0

Needs attention: 9 profile canonical(s) declared in rest.resource.profile, none of them US Core, CARIN, or Da Vinci; also checked rest.resource.supportedProfile, instantiates, imports, meta.profileI1 Spec ↗
Note: SMART discovery not applicable: a Provider Directory API is public by designI2 Spec ↗
Note: OAuth security not applicable: a Provider Directory API is public by designI3 Spec ↗

Declared capability changes

2026-08-25: software_version: '4.4.2.4' -> '4.5.0.9'
2026-09-23: software_version: '4.5.0.9' -> '4.6.1.7'

Declared app-to-server access

What the endpoint's own documents declare about app-to-server access, observed on this run. Nothing here was requested or exercised, and none of it is graded. An absent field is reported as absent, not as a refusal: a document that does not mention a field has not said anything about it.

What the SMART discovery document and the CapabilityStatement declare about SMART Backend Services and Bulk Data
Question	Answer	What the document says	Where it is declared
Declares private_key_jwt client authentication at the token endpoint	not declared: the field is absent	the SMART document is an empty JSON object, so it declares no field	SMART discovery: token_endpoint_auth_methods_supported
Declares the client_credentials grant, which SMART Backend Services uses	not declared: the field is absent	the SMART document is an empty JSON object, so it declares no field	SMART discovery: grant_types_supported
Declares the client-confidential-asymmetric capability	not declared: the field is absent	the SMART document is an empty JSON object, so it declares no field	SMART discovery: capabilities
Declares system-level scopes	not declared: the field is absent	the SMART document is an empty JSON object, so it declares no field	SMART discovery: scopes_supported
Declares an export operation	not listed	0 operations are declared and none is named export	CapabilityStatement: rest.operation and rest.resource.operation
Instantiates the Bulk Data Access implementation guide	not listed	0 canonicals are instantiated and none is Bulk Data's	CapabilityStatement: instantiates

Registry provenance

How this entry was verified

live CapabilityStatement fetch (fhirVersion 4.0.1, 9 resource types); implementation.url matches the requested base exactly. The document names the platform operator, not the brand: publisher 'Optum', software 'optum-flex-server-default' 4.4.2.4. Attribution to UnitedHealthcare rests on UnitedHealthcare publishing this server's capability-statement URL on its own site, under the heading 'Authorization NOT Required Endpoints', at https://www.uhc.com/legal/interoperability-apis/patient-access-api. The two strings that page labels 'Base request URL' answer 403 (https://flex.optum.com/fhirpublic) and 502 (https://flex.optum.com/fhirpublic2025); the metadata URL printed beside them is the one that works, and this entry is its base (recorded 2026-08-19). No later re-check is recorded, so the date above is the last time anyone checked this entry against the live endpoint.

Share this endpoint's grade

Link the badge back to this evidence page so readers can inspect the current findings.

<a href="https://fhir.chelseakr.com/endpoint/unitedhealthcare-provider-directory/">
<img src="https://fhir.chelseakr.com/badge/unitedhealthcare-provider-directory.svg"
alt="FHIR Scorecard: grade C"></a>

This is an observational snapshot of a public, unauthenticated surface. It is not an audit, a ranking of care quality, or a statement about anyone's regulatory compliance. See how we grade.

Every observation on record for this endpoint, with the dates it answered and the dates it did not.