Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
FHIR is a healthcare data-exchange standard—not a software product—and CMS-0057-F applies it to specific APIs and payer categories, not to every U.S. health plan. The rule’s API materials list FHIR Release 4.0.1, while HL7 identifies FHIR R5 (5.0.0) as its current published specification; those are different statements, and the newer general release does not automatically replace a version named in a rule.
What FHIR is—and what it is not
FHIR stands for Fast Healthcare Interoperability Resources. HL7 describes it as a standard for exchanging healthcare information electronically. It defines reusable data structures called resources, along with shared ways to represent information and exchange metadata. Systems can use those structures to communicate without FHIR being a particular electronic health record (EHR), app, or database.
FHIR can be used on its own or alongside existing standards. The base specification supplies building blocks; profiles and implementation guides narrow or organize those building blocks for particular use cases. That distinction matters in practice: saying that an interface “uses FHIR” does not, by itself, identify the exact data, workflow, or technical requirements it follows.
Which FHIR version applies to CMS-0057-F?
HL7 identifies FHIR R5 (version 5.0.0) as its current published specification. CMS’s standards listing for the APIs covered by the rule names FHIR Release 4.0.1. The general latest release and the version named in a rule are therefore not interchangeable: implementers should check the rule’s current standards listing and applicable legal requirements rather than assume that adopting R5 alone satisfies a CMS obligation.
#1 Best Overall
CMS’s standards page, last modified August 31, 2026, also notes that certain adopted standards and implementation guides derived from them expired on January 1, 2026. It says impacted payers may use updated versions under stated conditions, including ONC approval for the ONC Health IT Certification Program and no disruption to end-user access to required API data. The page’s version listing is an implementation reference, not a substitute for determining which legal requirements apply to a particular payer and API.
What CMS-0057-F covers
CMS published the Interoperability and Prior Authorization final rule, CMS-0057-F, on January 17, 2024. It builds on the 2020 CMS Interoperability and Patient Access final rule and covers specified payer categories:
- Medicare Advantage organizations.
- Specified Medicaid and Children’s Health Insurance Program (CHIP) programs and managed care entities.
- Qualified Health Plan (QHP) issuers on Federally Facilitated Exchanges (FFEs).
This is not a rule for every insurer or employer health plan. CMS says the only commercial payers affected are QHPs offered on FFEs; other commercial issuers and group health plans, including employer-based plans, are outside this rule’s scope. An affected payer may extend policies voluntarily, subject to other applicable law.
How the four APIs differ
The rule’s APIs serve different recipients and workflows. They do not all carry the same data, and affected payers are required to share only data they maintain.
| API | Primary recipient and purpose | Data or workflow described by CMS | Important scope or permission detail |
|---|---|---|---|
| Patient Access API | The patient; expands the existing API. | Adds specified prior-authorization information for medical items and services. | Drug prior authorizations are excluded from the rule’s requirements. |
| Provider Access API | In-network providers with a treatment relationship with the patient. | Shares specified claims and encounter information, USCDI data, and certain prior-authorization information. | CMS describes a patient opt-out approach for this provider data exchange. |
| Payer-to-Payer API | Another payer, when a patient changes payers or has concurrent payers. | Exchanges specified information between payers. | CMS describes an opt-in permission process. Denied prior authorizations are excluded from this exchange. |
| Prior Authorization API | Providers submitting prior-authorization requests. | Allows providers to check whether authorization is required, see covered items and documentation requirements, and exchange requests and payer decisions. | CMS’s described responses include approval, denial with a specific reason, or a request for more information. The drug exclusion applies to the rule’s prior-authorization requirements. |
The exact data set depends on the API. CMS’s comparison distinguishes claims and encounter data, USCDI, denied prior authorizations, submitted documentation, and permission processes; a payer should not treat one API’s data rules as applying identically to the others. CMS also identifies exclusions for provider remittances and enrollee cost-sharing in specified exchanges.
What a prior-authorization response must communicate
CMS says the Prior Authorization APIs must communicate whether a payer approves a request, including the date or circumstance under which authorization ends; denies it, including a specific reason; or requests more information. The API is intended to support both the request and the resulting decision workflow, rather than simply report whether an authorization exists.
Drug prior authorizations and other exclusions
The rule’s prior-authorization requirements generally exclude drugs. CMS explains that drug standards, processes, and decision timeframes differ from those for medical items and services. Drugs covered under a medical benefit may be included voluntarily in some API implementations, but that possibility should not be read as a universal requirement under this rule.
Free tools Windows power users keep installed
One-click scans. No signup required.
Other boundaries also matter: payer-to-payer exchange excludes denied prior authorizations, while the Provider Access API is described for in-network providers with a treatment relationship. Use the requirements for the specific payer category and API rather than assuming that every authorization, data type, or recipient is covered.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When the requirements take effect
CMS’s fact sheet gives broad implementation guideposts, not one deadline for every organization. Operational provisions generally begin January 1, 2026, while API development and enhancement requirements generally begin January 1, 2027. Exact compliance dates vary by payer type and provision, so an organization needs to check the rule’s specific requirement before setting a delivery date.
For impacted payers other than QHP issuers on FFEs, the fact sheet describes prior-authorization decision timeframes of 72 hours for expedited requests and seven calendar days for standard requests. These are regulatory timeframes for the covered categories—not measured outcomes or evidence of a particular reduction in processing time.
How to tell whether your organization should investigate
- Identify the payer’s legal category. Determine whether the organization is a Medicare Advantage organization, a covered Medicaid or CHIP program or managed care entity, or an FFE QHP issuer. Being a health plan or commercial insurer alone does not establish that CMS-0057-F applies.
- Match the work to an API. Identify whether the obligation concerns patient access, provider access, payer-to-payer exchange, or prior authorization. Their recipients, data, permissions, and exclusions differ.
- Check the applicable version and guide. Review CMS’s current API standards listing for the relevant FHIR version and the listed implementation guides, including applicable US Core, SMART, and Da Vinci materials. The listing may also link to other guides such as Bulk Data or CARIN where relevant.
- Confirm the exact legal date and data obligation. Check the provision for the payer type and whether the payer maintains the data at issue. General dates and summaries do not resolve every organization’s requirements.
FHIR is the technical foundation, implementation guides shape how it is used for specific exchanges, and CMS-0057-F sets obligations for covered payers, APIs, data, and dates. Keeping those three layers separate is the practical starting point for assessing compliance.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
