Enterprise · US payer readiness
CMS API readiness needs release evidence — not another certification claim.
Records can measure the FHIR data and profile conformance around an API release, compare it with an accepted baseline, and preserve the validation basis for review.
Regulatory context verified against the CMS fact sheet · 21 August 2026
The dated regulatory context
Exact compliance dates vary by payer type; the official rule remains the source of truth.
| Operational provisions | Generally beginning 1 January 2026. |
|---|---|
| API development and enhancement | Compliance dates generally beginning 1 January 2027, with exact timing varying by payer type. |
| Required FHIR baseline | FHIR R4 4.0.1 plus the standards and implementation specifications assigned to each API in the final rule. |
| Records status | Independent validation and evidence layer; no CMS approval or certification is claimed. |
Source: CMS Interoperability and Prior Authorization Final Rule CMS-0057-F.
What Records can support
One bounded evidence lane around the API release.
Pin the exchange basis
FHIR release, implementation-guide packages, terminology, resource scope, thresholds, and target environment.
Separate release delta from existing debt
Read new, resolved, changed, and remaining findings against the accepted run.
Attach evidence to the review
Keep the result, pins, timestamps, findings, and integrity metadata available after the test session ends.
What remains outside Records
The product validates FHIR and preserves evidence. It does not replace the rest of an API conformance programme.
No CMS certification
Records does not approve a payer, certify an API, interpret legal applicability, or make the compliance decision.
No complete API contract test
Authentication, consent, attribution, workflow semantics, authorization behavior, and end-to-end API testing require the appropriate CMS, Inferno, Touchstone, partner, and programme tooling.