The Tessara Payer FHIR Drift Taxonomy

Definition. An element that the FHIR Implementation Guide marks as required (cardinality 1..1 or 1..*) is missing from a server response. This is a breaking change for any downstream consumer that relies on the element being present.

Example. A Patient Access API stops returning Coverage.subscriberId in responses, breaking downstream member-attribution workflows that depend on it for claims-history retrieval.

Detection signal. Tessara compares the response payload’s structural contract to the pinned IG profile and flags any missing required element with the IG path and profile URL.

Definition. An element exists, but its declared FHIR type or cardinality bound has changed relative to the profile. Examples: a 1..1 element becomes 0..1; a string becomes CodeableConcept; a single value becomes a list.

Example. ExplanationOfBenefit.diagnosis changes from cardinality 0..* to 1..* on a Carin Blue Button profile, breaking consumers that submitted EOBs without diagnosis blocks during onboarding.

Detection signal. Tessara compares profile-declared types and cardinalities against the response’s actual structure and emits a per-path diff against the previous verified baseline.

Definition. A response includes an element or extension that is not declared in the profile, or declares an extension URL that does not resolve. Non-breaking for permissive consumers; breaking for strict-validation clients.

Example. A Provider Directory API begins returning a Practitioner.extension with a vendor-specific URL not registered in the US Core profile, causing strict-validating downstream tools to reject the resource.

Detection signal. Tessara enumerates extensions per response and flags any not present in the pinned profile’s extension list, including unresolvable extension URLs.

Definition. The endpoint’s declared SMART-on-FHIR scopes, OAuth2 flow, or token claim requirements diverge from the specification. Includes silent loosening (over-grant) and silent tightening (under-grant).

Example. A Patient Access endpoint that previously required patient/Coverage.read begins accepting user/*.read without enforcing the patient-context launch parameter, exposing other members’ data to a launched app.

Detection signal. Tessara performs probe requests with controlled token shapes (missing scopes, wrong audience, expired tokens) and compares the response code matrix to the IG’s declared auth contract.

Definition. The endpoint’s URL, HTTP verb, search parameters, pagination contract, or error-response shape changes in a way that breaks documented client behavior, even when the payload schema is unchanged.

Example. A Provider Access API changes its _count default from 50 to 10 without bumping the CapabilityStatement, causing pagination loops in clients that infer "last page" from response count.

Detection signal. Tessara runs a probe matrix (search-param combinations, pagination, _include/_revinclude) and flags response-shape, status-code, or behavior changes against the previous verified probe.

Definition. The endpoint’s declared CapabilityStatement, profile canonicals, or FHIR version in responses no longer matches the version the API was certified against. Includes silent IG upgrades that change required-binding strength.

Example. A payer’s Patient Access API upgrades from US Core 3.1.1 to US Core 6.1.0 without notice, changing required vs. extensible binding on Race and Ethnicity elements and breaking downstream coding pipelines.

Detection signal. Tessara pins the CapabilityStatement and profile canonicals at certification baseline and flags any drift in fhirVersion, profile canonical URLs, or referenced ValueSet/CodeSystem versions.