Many organizations assume they comply with Patient Access API rules once their API works during testing. Compliance issues often appear later during CMS reviews. For example, one Medicare Advantage plan built a FHIR API and tested every endpoint successfully. Six months later, a CMS contractor found three problems. Claims data appeared four days after adjudication instead of within one business day, the API did not return claims from the previous 90 days, and prior authorization reason codes appeared as free text instead of structured data. Endpoint testing missed these issues because it only checks whether the API responds, not whether the data is complete, correct, or current.  We provide a practical Patient Access API checklist based on CMS interoperability rules and the 2024 Prior Authorization Final Rule.

What the Rule Requires and What Organizations Are Required to Comply With

In May 2020, CMS issued the Interoperability and Patient Access Final Rule. The rule requires certain payers to build a Patient Access API using the FHIR R4 standard. Through this API, patients can connect approved third party apps and access their personal health data.

Organizations had to meet this requirement by July 1, 2021.

The rule applies to several payer types:

• Medicare Advantage organizations
• State Medicaid agencies
• Medicaid managed care plans
• CHIP agencies and managed care entities
• Qualified Health Plan issuers on the Federally Facilitated Exchange

Traditional fee for service Medicare follows a different pathway through the Blue Button 2.0 program. Employer sponsored self insured plans under ERISA do not fall directly under this Patient Access API rule, although the ONC Information Blocking Rule creates similar expectations for healthcare providers and health IT vendors.

Another point often overlooked is this. Meeting the original July 2021 deadline does not guarantee ongoing compliance.

CMS continues to update technical requirements. The agency has added new data elements that must appear in Patient Access APIs. It also introduced additional obligations through the 2024 Prior Authorization Final Rule.

Because of these updates, organizations that built their API in 2021 and never reviewed it again almost always miss something. Compliance is not a one time project. It requires continuous updates as CMS rules evolve.

Section 1: FHIR Technical Foundation

Start here before looking at anything else. If the technical foundation is off, nothing downstream works correctly no matter how good the data governance is.

Version and Profile Conformance

• The API must run on HL7 FHIR Release 4. Not STU3. Not DSTU2. R4. Some organizations that started early built on earlier versions and never fully migrated when the rule specified R4.
• Resources must conform to US Core Implementation Guide profiles, not just generic FHIR R4 schemas. US Core adds constraints and required fields on top of base FHIR. An API that is technically FHIR R4 but ignores US Core profiles will fail a conformance review.
• Claims and encounter data should follow the CARIN Alliance Blue Button Implementation Guide. This is the industry-developed implementation guide for payer claims data in FHIR format and CMS-aligned implementations are expected to follow it.
• Run your FHIR resources through an official validator, not just internal testing. The HL7 FHIR Validator and Touchstone testing platform catch conformance issues that custom test scripts miss.
• Check that every required data element within each resource is populated, not just that the resource type is present. An ExplanationOfBenefit resource that returns with the provider NPI field empty is a conformance failure even if the endpoint responds with a 200 status.

Data Freshness: The Most Commonly Failed Requirement

CMS requires that adjudicated claim data be available through the API no later than one business day after adjudication. This sounds easy. In practice it depends entirely on the data pipeline between the claims processing system and the FHIR data store that feeds the API. Those two systems are rarely the same system and the gap between them is where the one-day requirement breaks down.

• Map the complete data flow from claims adjudication to API availability. Include every ETL job, every database sync, every batch process in the chain. Total the lag time across all steps.
• If the combined pipeline lag exceeds one business day, that is a compliance gap regardless of whether the API endpoint itself is performing well.
• Check pharmacy claims separately from medical claims. Many organizations have different data pipelines for pharmacy and they run on different schedules.
• Test data freshness by adjudicating a test claim in a staging environment and measuring how long it takes to appear in the API. Do this test monthly, not just at implementation.

Availability and Historical Data

• The API must be available 24/7. Document your actual uptime and have a process for communicating planned maintenance windows to registered developers in advance.
• Historical claims data must go back at least one year. Many implementations only surface recent data. An audit that requests a patient’s claims from 14 months ago and gets nothing will find this gap immediately.
• Denied claims must appear in the API with their denial reason, not just paid claims. Partial payments must show the adjudicated amounts accurately.
• Verify that pharmacy, dental, and vision claims are included where applicable to the plan’s benefit structure. Some implementations only expose medical claims.

Section 2: Authentication, Authorization, and App Access

This section is where the patient-facing experience lives. If patients cannot actually connect a third-party app and retrieve their data, the API is technically functional but practically useless. CMS knows the difference.

OAuth 2.0 and SMART on FHIR

• Authorization must use OAuth 2.0 with the SMART on FHIR profile. Proprietary authentication flows do not satisfy this requirement even if they are technically secure.
• Test the authorization flow from the patient’s perspective using an actual third-party test app, not just internal tooling. The patient experience matters to CMS reviewers.
• Confirm that patients can authorize access through their existing member portal login without needing to create separate credentials for API access.
• Verify that the authorized scopes are specific to what the patient consented to. An app that requested read access to claims should not be able to pull clinical documents the patient did not authorize.
• Patients must be able to see which apps currently have access to their data and revoke any of them independently. Test that revocation actually stops data sharing in real time, not just flags it in a database.

Third-Party App Registration: Where Anti-Competitive Behavior Hides

CMS was deliberate about this in the rule language. Payers cannot use the app registration process as a competitive gatekeeping tool. Registration must be open to any legitimate developer. Delays, excessive requirements, or denials without specific documented security reasons are compliance violations.

• A public developer portal must exist with the API’s capability statement, base URL, OAuth endpoints, FHIR profile documentation, sample requests and responses, and error code definitions.
• A sandbox environment must be available for developers to test before connecting to production.
• Measure how long app registration takes from submission to approval. If the answer is weeks, that is worth examining against CMS’s anti-blocking expectations.
• Review any registration denials from the past 12 months. Were they based on documented security concerns or something else? Document the rationale for every denial.

Section 3: Data Content Requirements

The API returning a valid response is not the same as the API returning complete and accurate data. These are two different things and CMS cares about both.

Claims Data: What Has to Be There

Pull a random sample of 20 recently adjudicated claims across different claim types. Find them in the API. For each one, check whether the following elements are present and accurate:

• Patient identifier matching the enrolled member
• Payer name and plan identifier
• Rendering provider NPI and name
• Facility NPI and name where applicable
• Dates of service at the claim and line level
• ICD-10 diagnosis codes at the claim level
• CPT or HCPCS procedure codes at the line level
• Billed amount, allowed amount, plan paid amount, and patient responsibility
• Adjudication status with denial reason codes where applicable

If any of those elements is missing or wrong on more than a couple of claims, that is a systematic data mapping issue, not a random error. Trace it back to the source.

Clinical Data: The Gap Nobody Talks About

The Patient Access API is supposed to expose not just claims data but clinical data the payer has received from providers. Lab results submitted with claims. Clinical notes received through care gap programs. Encounter summaries from health information exchanges the payer participates in. This requirement is the one most organizations have done the least work on.

• Identify every data source where the payer receives clinical information from providers or health information exchanges.
• Check whether each of those data sources feeds into the FHIR API data store. Most of the time, only claims data does.
• If clinical documents are received but not available through the API, that is a gap. Document Reference resources should point to retrievable documents, not just reference document metadata.
• Verify Condition, Observation, Procedure, and Medication Request resources are populated with actual clinical data the payer has received, not just empty resource shells.

Formulary Data

• The formulary API must return the current, plan-specific formulary for the authenticated patient’s enrolled plan. Not a generic plan formulary. The specific one for the specific patient.
• Drug tier, quantity limits, step therapy requirements, and prior authorization flags must all be present.
• RxNorm codes must be used for drug identification. Internal drug codes that third-party apps cannot interpret defeat the purpose of the API.
• Check whether mid-year formulary changes are reflected. Formulary data that was loaded at plan year start and never updated is a compliance problem by spring.
• Test by comparing the API formulary response against the current formulary PDF on the member portal. Every drug and restriction in the PDF should be findable in the API.

Section 4: Patient Notifications and Transparency

CMS did not just require a technical API. It required that patients know it exists and understand what happens to their data when they use it. The notification and transparency requirements are where compliance teams outside of IT often drop the ball.

Member Notification

• Has the organization sent a notice to all enrolled members explaining the Patient Access API, what data is available, how to authorize a third-party app, and how to revoke access? If not, that is a compliance gap that has nothing to do with the technology.
• Is the Patient Access API clearly described in the member portal? Not buried in a help article. Visible to members who log in.
• Do new member welcome materials explain the API? Members who enrolled after initial implementation deserve the same notification.
• Is the description written in plain language? A paragraph full of FHIR acronyms does not meet the spirit of the patient access requirement.

The HIPAA Gap Disclosure

This one matters more than most organizations realize. When a patient connects their health data to a third-party app through the Patient Access API, that data leaves the HIPAA-protected environment. If the app is not a HIPAA covered entity or business associate, the app’s own privacy policy governs what it does with the patient’s data. CMS requires that patients be clearly informed of this before they authorize access.

• Is the HIPAA gap disclosure visible during the authorization flow, before the patient completes authorization? Not in a terms-of-service document. Visible and readable.
• Does it specifically state that the third-party app is not bound by HIPAA once data is shared?
• Does it give the patient enough information to make an informed decision about which apps they trust with their health data?
• Test this by going through the authorization flow as a patient would. Count how many clicks it takes to find any mention of privacy risk. If it is more than two, the disclosure is buried.

Section 5: Prior Authorization API Requirements

The 2024 CMS Prior Authorization Final Rule added new API obligations on top of the Patient Access API foundation. Most impacted payers have compliance dates beginning January 2026, but building on existing FHIR infrastructure takes time and organizations that are not already working on this are behind.

What the Prior Auth API Has to Do

• Providers must be able to submit prior authorization requests electronically using the Da Vinci Coverage Requirements Discovery and Prior Authorization Support implementation guides. Not through a web portal. Through a structured FHIR API that their EHR systems can connect to.
• The API must return prior authorization decisions in structured FHIR format: approved, denied, pending, with the specific reason for each status.
• Denial reasons must be machine-readable, meaning coded, not just a free-text note. A provider’s EHR system cannot process a plain-text denial reason. Structured codes are required.
• Decision timeframes apply independently of the API: 72 hours for urgent requests, 7 calendar days for standard requests. The API has to be capable of returning decisions within those windows.

Prior Auth Data in the Patient Access API

• Prior authorization decisions must also be visible to patients through the Patient Access API. Patients have the right to see their prior auth approvals and denials.
• Denial reasons visible to patients must be present in the FHIR data, not just in a separate payer portal.
• The one-business-day freshness requirement applies to prior auth data the same as claims data.
• Test this end-to-end: submit a test prior auth request, receive a decision, then check whether the decision appears in the Patient Access API within one business day.

Section 6: Payer-to-Payer Data Exchange

This requirement is the most frequently missed piece of the entire rule. Payers are required to exchange patient data with other payers when a member requests it or moves to a new plan. It uses the same FHIR infrastructure as the Patient Access API but is triggered by a different workflow and serves a different purpose.

• A payer-to-payer exchange endpoint must exist. This is separate from the patient-facing Patient Access API even though it uses the same FHIR foundation.
• When a member requests that their data be sent to a new health plan, the old plan must be able to transmit the required data set within the required timeframe.
• The receiving plan must be able to accept incoming FHIR data from other payers. Building an outbound capability without building the inbound receiving capability is only half the requirement.
• Test this workflow at least quarterly. Transmit test data to a known receiving endpoint and confirm it arrives correctly.
• Maintain logs of every payer-to-payer data exchange: when it was triggered, what data was sent, to which receiving organization.

Section 7: Security, Logging, and Ongoing Compliance

Security Requirements

• TLS 1.2 or higher is required for all API data transmission. Anything lower is both a CMS compliance failure and a HIPAA security risk.
• OAuth tokens must have defined expiration windows. Tokens that never expire are a security vulnerability.
• Penetration testing of API endpoints should happen at least annually. Patient health data APIs are high-value targets.
• Monitor API access for unusual patterns: high request volumes from a single app, access at unusual hours, attempts to pull data for patients the app has not been authorized to access.

Audit Logging

• Every API access event must be logged: which app, which patient data, what time, from what IP.
• Logs must be retained for at least six years consistent with HIPAA requirements. Logs must be reviewable. A log that is available but can’t be used to track meaningful events isn’t serving its compliance function.
• A compliant system would be able to capture when a patient withdraws access to an application and document this withdrawal event; it would then have to block future attempts by the same application for the same patient to access data through the API (and record these denial events).

Keeping Compliance Up-to-Date

Compliance typically falls into the category of things we tend to skip after the implementation phase. The Technical Requirements for CMS were updated, there was additional FAQ guidance released, and now the 2024 Prior Authorization rule will add to the overall structure originally outlined. Therefore, if an organization successfully completed a compliance review in 2022 and hasn’t reviewed their implementation since, they likely missed something.

• Name one person who is ultimately accountable for managing compliance with the Patient Access API. It should be an individual who is the sole owner of monitoring CMS guidance updates.
• Sign-up for CMS’s Interoperability listserv and regularly check CMS’s Interoperability and Patient Access resource page to identify new rule updates.
• Conduct a compliance review two times each year: Once in January to identify updates made to the calendar year; and once in July to identify updates made during the second half of the year.
• Document all compliance reviews, all identified gaps, and all corrective actions implemented. In the event CMS requests proof of ongoing compliance management, this documented history will serve as your documentation.

When CMS releases new guidance related to compliance, appoint one person to review the new guidance and determine if the new guidance necessitates any modifications to the current implementation. Do not automatically assume that any new guidance applies to all compliant organizations.

Final Thoughts

CMS Patient Access API Compliance is a journey, not a destination. Since the regulation has been in place since 2021, it will be updated again, and those organizations that continue to maintain compliance with the Patient Access API instead of treating this as a one-time IT Project will remain compliant with regulatory enforcement. Building out the technology to meet the requirements of the regulations is the hardest part. Maintaining the systems, data, and monitoring required to meet the regulations does not take nearly as much time or effort. What is needed is continuous focus on the process and the person accountable for maintaining these processes.