Required FHIR APIs

The five FHIR Implementation Guides mandated by CMS-0057-F for healthcare payers

Overview

CMS-0057-F requires healthcare payers to implement and maintain five FHIR-based APIs by January 1, 2027. Each API is defined by a published HL7 FHIR Implementation Guide (IG) that specifies resource types, data elements, search parameters, authentication mechanisms, and conformance requirements.

Below is a detailed breakdown of each API, what Tessara monitors for conformance, and common drift patterns observed in production deployments.

1. Patient Access API

HL7 FHIR US Core CARIN Blue Button Critical

Purpose

Enables patients to retrieve their health information via third-party applications. This includes claims data, clinical data, and prior authorization decisions. The API must support OAuth 2.0 patient-mediated authorization.

Required Resource Types

  • Patient — Demographics, contact information, identifiers
  • ExplanationOfBenefit — Claims data (professional, institutional, pharmacy, oral)
  • Coverage — Insurance coverage details
  • Encounter, Procedure, MedicationRequest — Clinical data elements
  • Condition, Observation, DiagnosticReport — Health conditions and lab results

What Tessara Monitors

  • Mandatory elements: Verifies all mustSupport elements defined in US Core profiles are present in observed responses
  • Cardinality constraints: Detects when minimum occurrence requirements (e.g., min: 1) are violated
  • Terminology bindings: Identifies when coded values deviate from required or extensible ValueSets
  • OAuth 2.0 scope: Tracks changes to supported scopes and authorization mechanisms

Common Drift Patterns

  • Missing mustSupport elements after code deployment
  • Cardinality violations (e.g., Patient.identifier returned as empty array when min: 1 required)
  • Incorrect FHIR version self-reported in CapabilityStatement
  • Authorization scope reduction without corresponding IG specification update

2. Provider Directory API

DaVinci PDEX Plan Net High

Purpose

Exposes provider network information including practitioner credentials, specialties, locations, and in-network status. Enables patients and third-party apps to search for in-network providers.

Required Resource Types

  • Practitioner — Healthcare provider credentials and identifiers (NPI)
  • PractitionerRole — Provider specialty, location, network participation
  • Organization — Healthcare organizations, hospital systems, practice groups
  • Location — Physical practice locations, addresses, contact information
  • HealthcareService — Services offered at specific locations
  • InsurancePlan — Network definitions and coverage tiers

What Tessara Monitors

  • Search parameter conformance: Verifies required search parameters are supported (e.g., Practitioner?name=, PractitionerRole?location=)
  • Network status representation: Tracks how in-network vs out-of-network status is encoded
  • Reference integrity: Detects broken references between PractitionerRole and Practitioner / Location
  • Update frequency: Identifies when data freshness requirements are not met

Common Drift Patterns

  • Search parameter removal or modification
  • Missing required extensions for network affiliation
  • Inconsistent active status flags across linked resources
  • Breaking changes to reference structures

3. Drug Formulary API

DaVinci PDEX Formulary High

Purpose

Provides programmatic access to payer drug formulary data including covered medications, tier placement, utilization management requirements (prior authorization, step therapy, quantity limits), and cost-sharing information.

Required Resource Types

  • MedicationKnowledge — Drug information, NDC codes, RxNorm mappings
  • List — Formulary list structure (tiers, coverage status)
  • InsurancePlan — Plan-specific formulary references
  • Basic (or extensions) — Utilization management policies

What Tessara Monitors

  • Formulary tier structure: Verifies tier definitions remain stable
  • Drug code mappings: Detects when NDC or RxNorm codes are added/removed without specification changes
  • Utilization management flags: Tracks changes to prior authorization requirements and step therapy protocols
  • Cost-sharing representation: Monitors structural changes to copay/coinsurance encoding

Common Drift Patterns

  • Tier renaming or restructuring without IG update
  • Missing utilization management extensions after system updates
  • Incorrect or missing drug code systems
  • Broken references between MedicationKnowledge and InsurancePlan

4. Prior Authorization API

DaVinci Prior Authorization Critical

Purpose

Supports FHIR-based submission and status tracking of prior authorization requests. Enables providers to submit requests and receive authorization decisions programmatically, reducing administrative burden.

Required Resource Types

  • Claim — Prior authorization request submission
  • ClaimResponse — Authorization decision and status
  • Bundle — Supporting documentation attachments
  • Task — Workflow tracking and status updates

What Tessara Monitors

  • Workflow state transitions: Verifies Task.status values align with IG-defined workflow
  • Supporting documentation requirements: Tracks changes to attachment structures and required evidence
  • Decision encoding: Monitors how approval, denial, and pended decisions are represented
  • Polling vs subscription mechanisms: Detects changes to asynchronous notification patterns

Common Drift Patterns

  • Status code vocabulary changes breaking workflow integrations
  • Missing required extensions for decision rationale
  • Broken attachment reference handling
  • Inconsistent Claim.use value (must be preauthorization)

5. Payer-to-Payer Data Exchange

DaVinci PDEX Medium

Purpose

Enables data transfer when a member transitions from one payer to another. The new payer can request the member's historical health data from the prior payer to support continuity of care and care coordination.

Required Resource Types

  • Patient — Member demographics and identifiers
  • Coverage — Prior coverage period and details
  • ExplanationOfBenefit — Claims history
  • Encounter, Condition, Procedure, MedicationRequest — Clinical data
  • Provenance — Data lineage and source attribution

What Tessara Monitors

  • Consent handling: Verifies member consent mechanisms align with IG requirements
  • Data scope filtering: Tracks what data categories are included in bulk export responses
  • Provenance tracking: Monitors Provenance resource inclusion and attribution
  • Bulk FHIR export conformance: Detects deviations from HL7 Bulk Data Access IG

Common Drift Patterns

  • Missing Provenance resources after data pipeline changes
  • Consent representation changes affecting data release workflows
  • Broken bulk export endpoint behavior (e.g., incorrect NDJSON formatting)
  • Date range filtering inconsistencies in coverage period queries

How Tessara Detects Drift Across All APIs

Tessara monitors these five APIs using a unified 5-stage pipeline:

  1. Ingest: Load published IG specifications and build spec baseline (Merkle hash tree)
  2. Probe: Query target API CapabilityStatement and retrieve sample resource instances
  3. Compare: Structurally compare spec baseline to observed API responses using the 6-category drift taxonomy
  4. Verdict: Generate signed compliance verdict with regulatory provision mapping
  5. Evidence: Store hash-linked evidence chain in tamper-evident audit log

Learn more about how Tessara works →

Next Steps

View Enforcement Timeline

Key dates and milestones for CMS-0057-F compliance

Conformance Readiness Checklist

Step-by-step preparation guide

Get a Free Conformance Assessment

We'll analyze your FHIR API conformance