How to Check Your CMS-0057-F APIs: Seven Questions to Ask Your Team

Your team, or your vendor, says the CMS-0057-F APIs are ready. The demo works: a test app signs in and pulls a member's claims. On January 1, 2027, the Provider Access, Payer-to-Payer and Prior Authorization APIs become mandatory, and prior authorization data joins the Patient Access API. The question in front of you is whether ready means compliant.

A demo shows that an endpoint answers. It does not show how late the data arrives, whether a provider sees only their own patients, or whether a developer can read the documentation without an account. The rule spells out all three. Each duty serves someone outside your plan, and they are the first to notice when it is missed.

So here are seven questions to put to your team. The first four follow the data out of each API to whoever asked for it: a member's app, a provider who wants patient data, a provider who wants a prior authorization, another health plan. The last three cover what all four APIs share: documentation an app developer can read, the reports and notices that CMS and the public see, and the testing behind all of it.

Each question comes with what the rule says and the evidence your team should be able to show you. None of it needs you to read code. And this is not a one-time check, so ask before the 2027 deadlines and keep asking after.

If you run a Medicaid managed care plan, the same duties reach you through your contract with the State, and each question notes where they differ. The dates work differently. Yours follow your rating period, the 12 months the State sets your capitation rates for. Each State sets when its rating period begins, so a 2027 duty may start for you on April 1, July 1 or September 1, 2027.

The links in this post go to the Medicare Advantage sections of the rule. The Medicaid ones are in 42 CFR part 438. For the rule as a whole, start with our CMS-0057-F overview.

The seven questions at a glance:

For a Medicaid managed care plan, a 2026 or 2027 date means the first rating period that starts on or after it.

1. A member's app

Ask your team. When a member's app asks for their data, is all of it there, and on time?

What the rule says. The Patient Access API has to give a member's app the following data that you maintain, for dates of service from January 1, 2016:

• Claims you have adjudicated, including payment decisions that can be, were or are being appealed, with provider remittances and the member's cost sharing. Due one business day after the claim is processed.
• Encounter data from providers you pay by capitation. Due one business day after you receive it.
• Clinical data: every data class in the US Core Data for Interoperability (USCDI), the federal list of standard health data such as diagnoses, lab results, medications and allergies. Due one business day after you receive it.
• If you offer Part D, Part D drug claims with remittances and cost sharing, due one business day after the claim is adjudicated, and your formulary, with its tiers and utilization management rules.
• From January 1, 2027, each prior authorization for items and services, drugs excluded. The app sees its status, the date it was approved or denied, when it ends, what was approved, a specific reason for a denial, and the structured documentation the provider sent. Due one business day after the request and after each status change, and kept for at least a year after the last change.

A Medicaid managed care plan leaves covered outpatient drugs out, and includes all its encounter data plus the claims and encounter data of its subcontractors.

What the answer should show. Three results, taken from the load logs and the API rather than from the design document.

• Timeliness. Your team should know what share of last week's claims appeared within one business day of the date the claims system marked them processed. The target is all of them, with a cause for each late one. They should have the same figure for encounters, clinical data, Part D claims and prior authorizations, each counted from the date the rule sets for it. A load that runs every night can pass. A load that runs once a week cannot.
• History. Take a sample of long-time members and count their claims and encounters for each year since 2016, once in the API and once in your own records. That means every system that holds the member's data, including a claims system you have since replaced, if you still keep its data. For a Medicaid plan, it also means the data from subcontractors and capitated providers. A platform loaded only from its launch date fails this, and so does one with a missing year.
• Denials. Two numbers for last month that should be equal. The first is how many prior authorization requests for items and services you denied, not counting drugs, across every system that decides them. That includes any vendor that decides them for you, since the plan stays responsible for its vendors. The second is how many of those denials reach the API with a specific reason. A gap between the two means denials that never reach the API, or reach it without a reason. Since January 1, 2026, every denial you send a provider must already give a specific reason, however you send it. So the reason exists somewhere, and the question is whether the feed carries it to the API. The rule sets no list of reason codes, so also ask to see five denials as a member's app shows them. Each should say why, for example which criteria the request did not meet.

Until 2027, run the prior authorization checks in pre-production, on real requests and denials from the production feed. Test data comes with a reason filled in, so it will not show a gap.

2. A provider asking for patient data

Ask your team. When an in-network provider asks for a patient's data, do they get only their own patients, and only those who have not opted out?

What the rule says. From January 1, 2027, the Provider Access API gives in-network providers the same data as Patient Access, back to January 1, 2016, without provider remittances and member cost sharing. The data is due no later than one business day after the provider's request. Before you share, you confirm who the provider is and check that the member is attributed to them, using your own process for linking members to in-network providers. Members can opt out and change their mind at any time, and the way to opt out has to be available before you first share data.

What the answer should show.

• Attribution. A test with three requests. An in-network provider asking about a member attributed to them gets the data. The same provider asking about a member who is not attributed to them gets nothing. A provider outside your network gets nothing.
• Opt-out. A member who opted out is left out of the response. Once that member opts back in, their data comes back.
• Timeliness. How long each request takes until the data is ready. It should be one business day or less. For a request covering a whole group of patients, stop the clock at the full response, not the first record.
• History. The same year-by-year check as in question 1.

3. A provider asking for prior authorization

Ask your team. Does the Prior Authorization API give a provider the same answer as our reviewers, for every code, including the codes a vendor reviews for us?

What the rule says. From January 1, 2027, the Prior Authorization API has to carry your list of items and services that need prior authorization. It also has to tell the provider what documentation each one requires, and say whether you approve (and until when), deny or need more information. A denial has to give a specific reason.

What the answer should show.

• Code list. Every code on your prior authorization list goes through the API, including the codes a vendor reviews for you. Drugs are out of scope. Where a code has conditions, such as the setting or the number of units, test one case that meets the condition and one that does not. A sample of codes that are off the list comes back as not needing prior authorization. The API and your reviewers work from one current list.
• Documentation. For a sample of codes, the API asks for the same documentation your reviewers do.
• Decisions. For a few test requests, the API returns the outcome a reviewer reached: approved with the date or event when it ends, denied with a specific reason, or a request for more information.

4. Another health plan

Ask your team. When a member joins from another plan, will we ask for their history on time? When another plan asks us, will we answer on time?

What the rule says. From January 1, 2027, both directions run through the Payer-to-Payer API, and both depend on the member's opt-in.

• Asking. You offer the opt-in and start finding each member's previous and concurrent plans. For current members, both start by January 1, 2027. For new members, both start within one week after coverage starts, or after CMS accepts the enrollment if that is later. Once you hold the opt-in and enough information about the other plan, the request goes out within one week. For a plan the member is in at the same time, you repeat the request at least every quarter.
• Answering. When another plan asks and attests that the member is enrolled with them and has opted in, you make the data available within one business day.
• Data. Patient Access data from the last five years, without provider remittances, member cost sharing and denied prior authorizations. It adds the unstructured documentation that providers sent with prior authorizations.

If you run a Medicaid managed care plan, the rule makes the opt-in and the search for previous and concurrent plans the State's job, and the State then shares the opt-in with you. The rule does not say how, and not every State has a process in place yet. Sending the requests, repeating them and answering other plans stay with you either way.

What the answer should show.

• Opt-in offer. The share of current members offered the opt-in by January 1, 2027, and the share of new members offered it within a week. Count the offers, not the answers, because the deadline is for asking. For a Medicaid plan, ask instead what your State has set up for the offer and how its opt-ins will reach you. If the answer is nothing yet, ask who collects the opt-in in the meantime and where it is kept. No request goes out without one.
• Timeliness. How long it takes from holding the opt-in and the other plan's details to sending the request. It should be a week or less. For members with a concurrent plan, the last repeat request should be less than a quarter old.
• Test exchange. In pre-production, in both directions, with another health plan's test system or a simulated one. Your request states that the member is enrolled with you and has opted in. Your answer to theirs is ready within one business day. For a test member with more than five years of history, it returns exactly the data described above.

5. An app developer

Ask your team. Can someone with no account read the documentation for all four APIs?

What the rule says. Each API needs public documentation: how to call it, what it accepts, what it returns, and how an app registers. The rule forbids "a requirement to register or create an account to receive the documentation". Nor can you charge a fee, send it only by email, or make developers read promotional material or agree to receive messages first.

The rule also limits when you can turn an app away. If you ever deny or end an app's access to any of the four APIs, you need objective, verifiable criteria applied the same way to every app. The decision has to rest on a finding that the app puts member health data on your systems at unacceptable risk.

What the answer should show. You can check the documentation yourself. The rule requires it posted on your website or reachable through a public link, so start where a developer would: your plan's home page, opened in a private browser window. Find the page for developers from there and follow the links for each API. If you cannot find it from the home page, a developer cannot either. You should be able to read all of it, including how an app registers, without signing up, filling in an email form, paying or ticking a box. Registering an app can still require an account. Reading how to do it cannot. Documentation that sits in a vendor's portal behind its login fails. For cutting off an app, ask for the written criteria and who applies them.

6. CMS and the public

Ask your team. Which reports, member notices and pages does the rule require, who owns each one, and where can I see it?

What the rule says. Some of the rule is not endpoints at all, but reports and plain-language pages:

• Usage numbers for the Patient Access API, reported to CMS by March 31 each year, first due March 31, 2026.
• Prior authorization statistics, posted on your website by March 31 each year, first due March 31, 2026.
• A page that helps members choose an app safely and tells them where to file a complaint. It has applied to Patient Access since January 1, 2021.
• For Provider Access, plain-language information for members about the exchange and how to opt out. It goes out before you first share data and then every year, and stays on your public website. New members get it within a week after coverage starts, or after CMS accepts the enrollment if that is later. For a Medicaid plan, it is within a week after enrollment. Providers get plain-language instructions on your website too, including how to use your attribution process.
• For Payer-to-Payer, plain-language information for members when you ask for the opt-in, every year, and on your public website. A Medicaid plan gives it every year and on its website. The notice that goes with the opt-in request is the State's job.

What the answer should show. A list of every report, notice and page, each with a named owner. For the two reports, the March 2026 submission to CMS and the page with the statistics. For each page, a link you can open. For the member notices, the last mailing or message and the date it went out.

7. Your own team

Ask your team. Will we know when one of these checks starts failing, and do we run the versions of the standards the rule allows?

What the rule says. Each of the four APIs needs "routine testing and monitoring" to make sure it works.

The CMS rule also names the standards each API follows. For each one, it points to a version on a list kept by the Office of the National Coordinator for Health IT (ONC):

• All four APIs use FHIR R4, the base standard, and US Core, the US profiles built on it.
• All except Payer-to-Payer use SMART App Launch, how an app signs in and is authorized.
• Provider Access and Payer-to-Payer use Bulk Data, for a whole group of patients in one request.
• Patient Access uses OpenID Connect, for confirming who the user is.

For two of them, the CMS rule points to old versions: US Core 3.1.1 and SMART App Launch 1.0.0. The CMS rule lets you use a newer version if ONC has approved it for its certification program and no other law forbids it. The switch must not disrupt users' access to the data.

Today the rule does not require the Da Vinci or CARIN implementation guides, the detailed FHIR specifications for payer data. A CMS rule proposed in April 2026 would require CARIN Blue Button, Da Vinci Payer Data Exchange and the Da Vinci prior authorization guides from October 1, 2027. It is not final.

The same proposal "strongly encourages" payers to use test tools such as Inferno, ONC's open-source test tool, for the testing the rule already requires. Inferno has test kits for US Core, SMART App Launch, Bulk Data and the CARIN and Da Vinci guides. A passing run shows that an API's answers follow the standard. It does not show that claims arrive on time, that a provider sees only their own patients, or that a vendor's denials carry a reason. So it answers part of this question, not questions 1 to 6.

What the answer should show.

• Monitoring. The checks from questions 1 to 4 running on a schedule, with the latest results and the person who is alerted when one fails. A single test before go-live is not monitoring.
• Versions. A line for each API and standard, with the version. Each version is either the one the CMS rule points to, or a newer one ONC has approved for its certification program. For a newer one, the team can say why the switch did not cut off anyone's access to the data. The list also says whether each API follows the CARIN and Da Vinci guides, so you know how much work is left if the proposal becomes final.
• Conformance. For each API, the latest Inferno report against the versions on that list and the guides the API follows, with the date it ran.

If a line still says US Core 3.1.1 or SMART App Launch 1.0.0, the team should have a plan to move. ONC's adoption of both expired on January 1, 2026, and since then health IT can no longer be certified to them. A final rule from ONC removes both from its list on December 28, 2026. The April 2026 CMS proposal would stop payers from using an expired version, which would leave US Core 6.1.0, built for version 3 of USCDI, and SMART App Launch 2.0.0. Until that is final, the newer versions are allowed for payers, not required.

How Health Samurai helps

With Payerbox, Health Samurai's platform for CMS-0057-F, you get more than a product: a team that helps you answer these seven questions. Book a one-hour readiness review and we will go through all seven with your team.