Health1st AI Logo
For Payers & Health Plans

CMS-0057-F is a deadline, not a project.

Four FHIR APIs. One hard date: January 1, 2027. Health1st maps your legacy claims, X12, and clinical data to US Core FHIR with AI — so your compliance program ships in weeks, not quarters.

  • Patient Access · Provider Access · Payer-to-Payer · Prior Auth (PARDD)
  • Built on the mandated stack: FHIR R4.0.1 + US Core STU 3.1.1 + SMART + OIDC
  • AI-drafted mappings from X12 & claims, reviewed by your team
HL7 v2.5.1 · ADT^A01inbound
MSH|^~\&|EPIC|HOSP|H1ST|DST|202601..||ADT^A01|
PID|1||MRN12345^^^HOSP^MR||DOE^JOHN^A||
    19701225|M|||123 MAIN ST^^AUSTIN^TX
PV1|1|I|ICU^101^A|||...admit...
DG1|1|I10|E11.9^Type 2 diabetes mellitus
PIDPatient
PV1Encounter
DG1Condition
AIMapping
Agent
validate · normalize · map
FHIR R4 · Bundleoutbound
{ "resourceType": "Patient",
  "identifier": [{ "value": "MRN12345" }],
  "name": [{ "family": "Doe",
             "given": ["John","A"] }],
  "gender": "male",
  "birthDate": "1970-12-25" }

{ "resourceType": "Condition",
  "code": { "coding": [{
    "system": "…/icd-10-cm",
    "code": "E11.9" }] } }
US CoreR4.0.1validated
An inbound HL7 v2.5.1 ADT^A01 admission message is parsed segment by segment — PID maps to a FHIR Patient, PV1 to an Encounter, and the DG1 diagnosis segment (ICD-10 E11.9, Type 2 diabetes) to a FHIR Condition — by the AI Mapping Agent, validated against US Core and FHIR R4.0.1. The reverse direction (FHIR back to HL7 v2) is also supported.

In short

CMS-0057-F requires impacted payers — roughly 365 Medicare Advantage, Medicaid/CHIP, and FFE QHP organizations — to stand up four FHIR APIs (Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization/PARDD) by January 1, 2027, with operational provisions starting in 2026. As of October 2025, ~43% of payers had not yet begun. By March 2026 roughly 35% were still a quarter or less into the Patient Access API. Health1st gets you there by using AI to map your legacy claims, X12, and clinical data to US Core FHIR R4.0.1. That is the slowest part of the project, compressed from months into weeks.
Jan 1, 2027
API compliance deadline
operational provisions begin 2026
4
mandated FHIR APIs
Patient · Provider · P2P · PARDD
~365
impacted payer orgs
MA · Medicaid/CHIP · FFE QHP
~43%
of payers not started
WEDI survey, Oct 2025
The pressure you're under

Compliance-driven, deadline-compressed, and costly to get wrong

You know the mandate. The hard part is turning years of legacy data into conformant FHIR before the clock runs out — while procurement, security review, and an audit trail all sit on the critical path.

Four FHIR APIs, one hard deadline

CMS-0057-F requires Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization (PARDD) APIs live by January 1, 2027 — on a mandated stack you may not run today.

Legacy claims & X12 don't speak FHIR

Your data lives in X12 837/835/278, proprietary claims warehouses, and clinical feeds. Converting all of it to US Core FHIR R4 by hand is a multi-quarter mapping project.

Prior auth is a workflow, not a form

PARDD demands automated coverage discovery, documentation requirements, and a decision loop — with 7-day standard / 72-hour expedited timeframes and public PA metrics reporting.

Penalty and reputational exposure

Missing 2027 is not just a technical slip. It is audit exposure, attestation risk, and a public readiness gap your members, providers, and regulators can see.

The readiness path

From legacy estate to four conformant APIs

A repeatable path that puts AI on the mapping bottleneck and keeps your team in control of every clinical and claims field that ships.

  1. 1

    Inventory & gap assessment

    We map your current estate (X12 feeds, claims warehouse, clinical data, existing member APIs) against the CMS-0057-F stack (FHIR R4.0.1, US Core STU 3.1.1, SMART, Bulk Data, OIDC, USCDI) and flag every gap.

  2. 2

    AI-drafted mappings to US Core

    The Mapping Agent proposes field- and segment-level mappings from your internal models and X12 to US Core FHIR profiles, with plain-English rationale and confidence scores your team reviews.

  3. 3

    Stand up the four APIs

    Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization (PARDD) — served on SMART App Launch + OIDC, with Bulk Data (Flat FHIR) for population-scale exchange.

  4. 4

    Validate, attest & operate

    Conformance-test against US Core and the Da Vinci PARDD implementation guides, capture audit trails, and monitor continuously so you stay compliant in production, not only on go-live day.

What you get

Outcomes your board and your auditors both accept

A defensible compliance program that holds up long after go-live.

Four conformant APIs, on time

Patient Access, Provider Access, Payer-to-Payer, and PARDD live on the mandated stack before January 1, 2027 — validated against US Core and Da Vinci before you attest.

The mapping bottleneck, in weeks

AI drafts your X12-and-claims-to-US-Core mappings so the slowest, most expensive part of the program stops being measured in quarters.

Audit-ready from day one

Versioned, explainable mappings and immutable audit trails give compliance the evidence to defend every attestation — long after go-live.

The four mandated APIs

Everything CMS-0057-F requires, on the stack it requires

FHIR R4.0.1 · US Core STU 3.1.1 · SMART App Launch 1.0.0 · Bulk Data STU 1 · OpenID Connect 1.0 · USCDI.

Patient Access API (expanded)

Members retrieve claims, encounters, clinical data, and (new under CMS-0057-F) prior authorization status via third-party apps over SMART on FHIR.

Provider Access API

In-network providers pull patient claims and clinical data (USCDI) for treatment, with attribution and opt-out handling built into the exchange.

Payer-to-Payer API

When a member moves plans, their claims and clinical history follow — bulk FHIR exchange between prior and current payer, mapped and de-duplicated automatically.

Prior Authorization API (PARDD)

Coverage Requirements Discovery, Documentation Templates & Rules, and Prior Authorization Support — the Da Vinci PARDD stack that automates the auth decision loop.

Prior Authorization is the hardest of the four. See how Health1st automates the Da Vinci PARDD decision loop end-to-end.

Who this is for

Built for the people who own the mandate

CMS-0057-F lands on a specific set of desks. Health1st gives each of them what they need to say yes — and to defend the decision in an audit.

VP of Interoperability / Digital

A credible plan to reach four conformant APIs before 2027 without hiring an army of FHIR consultants.

Chief Compliance / Regulatory Officer

Auditability and conformance evidence (versioned mappings, audit trails, and honest security posture) to defend attestation.

Enterprise Architect / Head of Data

Deployment control (cloud or VPC), clean mapping of X12 and claims to US Core, and no lock-in to a pre-connected network.

Security & Compliance

Where our compliance actually stands

Protecting PHI is non-negotiable. Here's exactly where our certifications stand — no overclaiming.

HIPAAActive

Compliant · BAAs available

SOC 2 Type IIIn Progress

Audit in progress

HITRUST CSFOn Roadmap

On roadmap

HL7 · FHIRCore

Native, by design

AWS HIPAA-eligible infrastructure · Business Associate Agreements (BAAs) · Encryption in transit & at rest · See our security details →

Frequently asked questions

Get your four FHIR APIs live before January 2027.

Bring your own X12 and claims samples. We'll show a live mapping to US Core FHIR on your real message types.