CMS-0057-F requires affected payers to add or expand FHIR APIs for patient, provider and payer data exchange, with API compliance dates generally beginning in 2027. The rule creates separate decisions about who may obtain a member's data, which data may travel, and when a prior authorization response may be viewed or changed. A security review that treats all of these interfaces as one generic FHIR endpoint misses the business rules that matter most to a payer.
Quick answer. CMS-0057-F does not itself mandate a penetration test. For an impacted payer commissioning one, the useful scope is a set of authenticated, policy-driven tests for Provider Access attribution and patient opt-out, Payer-to-Payer opt-in and requesting-payer attestation, Prior Authorization request and response workflows, and the Patient Access API's new prior authorization data. Stingrai's web and API penetration testing can test those boundaries with synthetic members, distinct provider and payer identities, redacted evidence and a retest record.
This guide is for security and interoperability owners at Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on the Federally Facilitated Exchanges. These are the impacted payer categories named by CMS. It gives a buyer enough detail to solicit comparable proposals without turning a rule about interoperability into an invented testing mandate.
What CMS-0057-F changes and what it leaves to the buyer
The final rule's operative text is the starting point. For Medicare Advantage, 42 CFR 422.121 addresses Provider Access and Payer-to-Payer; 42 CFR 422.122 addresses the Prior Authorization API. The rule also expands information in the existing Patient Access API. Other impacted payer categories have parallel provisions and different compliance-date formulations. CMS says the API requirements generally begin January 1, 2027, while certain operational obligations began in 2026. The engagement brief should identify the buyer's payer type and applicable date instead of copying a single date across every line of business.
Interface | Rule-driven purpose | Boundary a security buyer should commission |
|---|---|---|
Provider Access API | Make defined member data available to an eligible provider with a treatment relationship, subject to attribution, provider authentication, patient opt-out and other applicable law | Can a provider obtain only the members and records that the payer's attribution and permission policy allows? |
Payer-to-Payer API | Exchange defined data with a previous or concurrent payer after patient opt-in and requesting-payer attestation | Can the receiving payer rely on a correctly bound identity, enrollment claim and permission without crossing into another member or payer relationship? |
Prior Authorization API | Expose covered items and services requiring authorization, documentation requirements, and a request/response path | Can only an authorized workflow actor create, view, update or retrieve the appropriate request and decision? |
Patient Access API expansion | Add specified non-drug prior authorization information to the patient-facing API | Does the patient's own authorization context restrict access to that patient's authorization information? |
The table is a test-planning translation of the CMS fact sheet and the rule. It is not a list of security tests ordered by CMS. The rule describes API capabilities and exchange conditions; the buyer chooses penetration testing to verify the implemented boundaries before release and after material changes.
One scope distinction matters immediately: CMS states that the current rule's prior authorization API provisions concern medical items and services excluding drugs. An April 2026 CMS proposal addresses drug prior authorization, but a proposed change must not be described as part of the final 2024 obligation. A payer may still test drug-related interfaces it operates; the statement of work should identify them as a separate business scope.
Define the contract boundary before anyone tests
An API name is not an asset inventory. The payer may run an API gateway, FHIR server, authorization service, member portal, provider onboarding system, attribution engine, prior authorization platform and external integration layer through different teams or vendors. A quote based only on a FHIR base URL cannot tell whether all access decisions are within reach. Ask the application owner to name the deployed endpoints and which component makes each decision.
Start with a topology that marks the payer-controlled systems, the vendor-operated systems for which the payer can authorize testing, and partner systems outside the engagement. Name the production-like test environment, release or build, FHIR endpoints, app clients, token issuers, data stores, queues, batch export paths and web portals that touch the same data. The response from a Prior Authorization API may appear in a provider portal or be passed to another service; that downstream path matters if it is part of the buyer's system. An endpoint-only test stops too early.
Define the data boundary separately from the infrastructure boundary. The test team needs a controlled set of synthetic members with distinct plan enrollment, previous and concurrent payer relationships, provider attribution, opt-out or opt-in state, and prior authorization records. Production patient data should not be copied into a test just to make it realistic. If the only available environment is production, the rules of engagement must provide approved nonclinical records, test accounts, rate limits, safe state-changing operations and a method to remove test artifacts.
For the statement of work, specify what the tester may do when an authorization response changes state, generates a provider notification or enters a claims workflow. A safe plan tests authorization and integrity without creating a real care or payment consequence. The payer should also identify any external FHIR endpoint, clearinghouse, EHR or prior authorization network that will not be probed. The report should preserve that exclusion so a reader does not mistake an untested partner for a passed control.
Provider Access: test attribution and opt-out together
For Medicare Advantage, 42 CFR 422.121(a)(2) requires the payer to authenticate the requesting in-network provider, attribute the enrollee to that provider, confirm the enrollee has not opted out, and respect other applicable law before making the covered data available. The same section requires an attribution process and a way for a member or personal representative to change the opt-out choice. These are distinct gates. Successful provider login does not prove a treatment relationship; a treatment relationship does not override an opt-out.
Build test fixtures that differ in one condition at a time. Use an in-network provider with an attributed member as a positive control. Then use an authenticated provider without attribution to that member, an out-of-network provider where the payer's policy excludes them, and a member who has opted out. The expected result may be a denial or a filtered result, depending on the implementation. Capture the intended policy before judging the output. If a tester sees an empty FHIR Bundle, they should be able to say which gate produced it rather than reporting a generic failure.
Attribution has a lifecycle. A member can change providers, an appointment can be cancelled, coverage can end, or a provider's network status can change. The test should check whether cached membership lists, search results, direct reads and asynchronous exports use a current attribution decision. It should also test a switch from sharing to opt-out and back, including a request already in flight. This is a buyer's risk-based test design, not a CMS-prescribed latency threshold.
CMS's Provider Access FAQ says the rule does not prescribe a single attribution process and requires an opt-out across all providers under this API policy. More granular provider-specific choices are encouraged but not required. The SOW should therefore ask the payer to document its actual attribution method and any extra permission controls it offers. A tester cannot infer those policies from an implementation guide alone.
For data content, have the payer enumerate the resource types and date ranges it intends to expose. The CMS fact sheet identifies claims and encounter data, USCDI data, and specified prior authorization information, while excluding provider remittances, enrollee cost-sharing information and drug prior authorizations from the stated Provider Access data requirement. The security question is whether a valid provider can reach fields, attachments or linked records beyond that authorized set, not whether every possible FHIR resource exists.
Payer-to-Payer: an opt-in is not a provider opt-out
The Payer-to-Payer provision for Medicare Advantage uses affirmative patient opt-in. The requesting payer includes an attestation that the member is enrolled with it and opted into the exchange; the responding payer authenticates the requesting payer's identity and checks that other law does not prohibit disclosure. CMS's FAQ explains that the responding payer generally relies on the requesting payer's attestation when the request otherwise meets the rule. That makes identity binding and attestation handling central test objects.
Use at least two synthetic payer organizations and members with distinguishable identifiers. Include a valid previous-payer transfer, a concurrent-payer relationship, a member who has not opted in, a withdrawn opt-in, and a request whose member identity is valid at one payer but maps to another member at the responder. Verify the requester's identity and stated enrollment are bound to the same transaction and member. Where the product uses a batch or bulk flow, check that one permitted member does not authorize an entire group by accident. These are safe negative tests of the implementation, not instructions for abusing a public endpoint.
The rule's data boundary deserves its own test. For MA, 42 CFR 422.121(b)(4)(ii) sets the required date-of-service window at five years before the request, and the requested data set excludes denied prior authorizations, provider remittances and enrollee cost-sharing information. That wording defines what must be exchanged under this provision; it should not be converted into an unsupported claim that all older records are legally forbidden to share. Ask the payer to declare its authorized policy for any voluntary additional exchange, then test that policy.
The receiving side is also in scope. CMS says that data received through Payer-to-Payer must be incorporated into the patient's record and, as appropriate, made available through Patient Access, Provider Access and Payer-to-Payer APIs. A procurement brief should therefore cover whether imported data receives the right member identity, provenance, access policy and exclusion handling when it travels onward. A secure first hop is insufficient if a later provider or patient query exposes a different member's imported record.
Prior Authorization: follow the whole decision workflow
42 CFR 422.122(b) requires the MA Prior Authorization API to identify covered items and services that require authorization and the required documentation; it must support a request and response. An outcome must communicate approval and the date or circumstance when authorization ends, denial with a specific reason, or a request for more information. A test that only checks an API's authentication header does not establish whether each response belongs to the proper member, provider, plan and case.
Ask the payer to provide a small synthetic workflow set: an item that needs authorization, one that does not, a request with missing documentation, an approved case, a denied case, and a request for more information. Assign distinct provider organizations and members. The test should compare who can discover requirements, submit a request, attach documents, see status and read a decision. It should verify that a provider with a valid account cannot view or alter another provider's case merely by knowing a case identifier. OWASP's API1 and API3 provide the technical language for object and property authorization, but the expected answer comes from the payer's own workflow and policy.
The negative cases matter as much as the happy path. Specify a mismatched member and plan, a provider whose access has been revoked, a request submitted twice, and an attachment associated with the wrong case. Define what should be rejected, what may be returned with reduced detail and what must be logged. Keep any test that could trigger clinical review, member messaging or payment changes within an approved synthetic environment. The engagement should not invent a clinical decision; it should verify whether the system protects the decision and documentation that the payer's authorized users create.
CMS lists Da Vinci Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support among its recommended implementation guides. CMS's standards FAQ explicitly says those recommended IGs are not required at this time. If the payer has chosen them, include their deployed versions and integrations in the test inventory. Do not make a quoted security assessment depend on an IG the buyer does not use.
Patient Access: the expanded data path needs its own regression test
CMS-0057-F adds specified non-drug prior authorization information to the existing Patient Access API on the compliance schedule for each payer category, generally beginning in 2027. That expansion gives a familiar patient app or authorization server a new data path. The payer should confirm whether the prior authorization records are returned as FHIR resources, linked documents, search results, downloads or a combination. The test then compares patient A and patient B across direct access, search and app display.
Use distinct patients with different authorization histories and an app grant restricted to each. Look for mismatches introduced when a prior authorization case changes status or when a representative accesses a patient's account under the payer's policy. The existing FHIR API scoping guide explains SMART patient, user and backend contexts in depth; this CMS-0057-F engagement should reuse that protocol groundwork while testing the new prior authorization data and payer-specific permissions. The new workflow does not make a broad patient/ or user/ scope proof of access to every case.
An evidence matrix the vendor can quote against
Turn the rule's separate exchange conditions into an evidence matrix before asking for prices. Each row needs a positive case to show the function works, a negative case to show the boundary holds, and a traceable artifact. Without a positive control, a failed connection can look like a successful denial. Without a negative case, a working connection can look secure while returning another member's data.
Figure 1: The four API surfaces, each with a distinct permission decision and the evidence to retain. Source: CMS, CMS-0057-F final rule fact sheet.
Test lane | Positive control | Negative control | Evidence to retain |
|---|---|---|---|
Provider Access | Authenticated eligible provider, attributed member, no opt-out | Same provider without attribution; member opts out; provider loses eligibility | Provider identity, attribution and permission snapshot, requested resource, redacted response |
Payer-to-Payer | Authenticated requesting payer, enrolled member, opt-in attestation | Missing or withdrawn opt-in; mismatched member; unauthorized payer identity | Payer identity, attestation binding, member match, response set and provenance |
Prior Authorization | Authorized provider requests or reads its own synthetic case | Other provider or plan tries to see or change that case | Case state, actor role, allowed and denied operation, redacted decision or attachment |
Patient Access | Patient app reads its own new authorization record | Other patient's token or context attempts the same read | Patient context, grant, resource ownership and result |
Add columns to the payer's working copy for environment, owning team, API version, test account, resource type, expected outcome, actual outcome, finding ID, remediation owner and retest status. The proposal should state which rows are included and how many distinct roles, payer partners and workflow variants the fee covers. The table above is intentionally a minimum: a large payer with multiple plans, gateways and authorization engines needs more than one row per lane.
Put usable acceptance criteria in the statement of work
The following wording can be adapted for an RFP or security testing SOW. It is a buying specification, not a claim that CMS requires this testing:
Assess the payer-controlled FHIR and related web/API components that implement the CMS-0057-F Provider Access, Payer-to-Payer, Prior Authorization and expanded Patient Access workflows. Test authenticated authorization across distinct synthetic members, providers, payer organizations, plans and application clients. Verify positive and negative cases for provider attribution and patient opt-out, payer opt-in and requesting-payer attestation, member matching, defined data-set exclusions, prior authorization case ownership, and the onward access policy for imported records. Deliver an asset and role inventory, a lane-by-resource coverage matrix, redacted evidence for validated findings, prioritized remediation guidance, documented exclusions and a post-fix retest record. Perform all state-changing tests only within the approved rules of engagement.
Attach the payer's architecture and policy schedule to that clause. A proposal should identify the specific services and endpoints, not promise to test “all APIs” when the payer has not defined them. Require the vendor to name the input it needs: synthetic member roster, provider and payer identities, test client registrations, access grants, attribution events, opt-in or opt-out records, prior authorization cases, and expected outputs. The buyer should retain ownership of those expected outputs, because the tester cannot decide whether a provider truly has a treatment relationship or whether a particular case should be approved.
Define the testing method in business terms. Authenticated testing should cover each authorized role and the denials around it. Where source access is approved, source-assisted review can trace how a decision travels from token validation through member matching to data retrieval. A pure unauthenticated scan may still find exposed endpoints, but it cannot complete this contract's central work: testing who can reach whose records after login. Include a limited check of gateway configuration, transport, client identity and logging, then spend the engagement's depth on object, function and workflow authorization.
Deliverables should be inspectable. The report should list each tested build, endpoint, role, fixture and policy assumption; show which cases passed or failed; describe any untested integration; and contain redacted request and response evidence for each confirmed finding. A severity label without the expected decision and observed data movement is hard for engineering to fix. Ask for a management summary that identifies cross-member and cross-payer impact plainly, plus a technical appendix that can be shared with the API team. Retesting should name the fixed build and replay the original failing condition alongside an adjacent regression case.
Plan the work across payer teams and vendors
The security lead should bring interoperability, privacy, provider relations and prior authorization operations into the kickoff. They own different truths. Interoperability can provide the API inventory and version map; provider relations can explain the attribution source; privacy can confirm permission semantics and applicable exclusions; utilization management can define who may see or change a prior authorization case. The penetration testers turn those truths into controlled security checks.
If a vendor runs the FHIR server or a prior authorization hub, obtain the contractual testing right and maintenance window before the exercise. If a provider's EHR or another payer is not under the buyer's control, use a mock or agreed sandbox and document the limit. Do not present results from a mock responder as proof of the external partner's security. In a multi-application enterprise program, group tests by common gateway and authorization services, then sample each distinct policy implementation. That can reveal whether one shared control protects all lines of business or whether each product has its own logic.
Use a rollout sequence that leaves time for remediation. First freeze the inventory and expected-access matrix. Next execute the controlled test and return findings while the integration team can still change code. Then retest the corrected build and save the matrix with the release. If the payer deploys new app clients, attribution mechanisms or prior authorization workflows often, consider a continuous testing program alongside one-time or annual deep assessments. The program should be tied to releases and business-rule changes, not a claim that a compliance calendar alone catches authorization regressions.
Questions to ask a payer API testing vendor
Will you test the rule's Provider Access opt-out and Payer-to-Payer opt-in as different policies, with separate synthetic fixtures?
How will you verify provider identity, attribution and treatment-relationship changes without relying only on a valid token?
Can you show evidence that a requesting payer's attestation is bound to the authenticated payer and the intended member?
Which prior authorization case states, attachments, roles and partner systems will the quote include?
How will you check imported Payer-to-Payer data when it later appears through Provider or Patient Access?
What tests can run safely in a production-like environment, and what happens when a workflow could trigger clinical or financial effects?
Will your report separate a correctly denied request from an untested or unavailable route, and will you retest corrected findings?
A credible answer is a proposed matrix with named role and data prerequisites. “We test OWASP Top 10” is useful as background, but it does not say whether the vendor can assess provider attribution, opt-out propagation, cross-payer member matching or prior authorization case ownership. The buyer should compare proposals against the same fixtures and deliverables.
Where Stingrai fits
Stingrai is a CREST-accredited penetration testing services company headquartered in Toronto. Its web and API penetration testing covers authenticated roles, broken object and function authorization, business logic and the application paths around an API. A payer engagement can be scoped as a one-time or annual human-led test, with the payer's real authorization policy and synthetic data supplied at kickoff. For programs that release frequently, a continuous option can be scoped alongside the annual baseline. Stingrai's testing supports healthcare compliance programs and produces evidence for audits.
The buyer should send the API inventory, ownership map, payer categories, synthetic-fixture plan and desired release window when seeking a quote. Those inputs determine the number of apps, roles, partner paths and test cases more reliably than a count of endpoints alone. Get a Quote is the route for an enterprise payer scope that spans more than one web application and associated APIs.
Frequently Asked Questions
Does CMS-0057-F require a penetration test?
No. The final rule's API provisions specify exchange capabilities, permissions and workflow conditions for impacted payers, but do not prescribe a penetration test. A payer can commission one to verify its implementation and retain evidence of the tested boundaries.
Which payer organizations need to prepare for the CMS-0057-F APIs?
CMS names Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on the Federally Facilitated Exchanges. The applicable API compliance date and regulatory provision depend on the payer category.
What is the most important Provider Access API test?
Test provider identity, member attribution and the member's opt-out together. A positive fixture should show access for an eligible treating provider; negative fixtures should show that a provider without attribution or a member who opted out does not receive that member's protected data.
How is Payer-to-Payer permission different from Provider Access permission?
Payer-to-Payer exchange requires affirmative patient opt-in and a requesting-payer attestation of enrollment and permission. Provider Access uses a patient opt-out with payer-maintained attribution to an eligible treating provider. The two policies need separate test accounts and expected outcomes.
What should a Prior Authorization API penetration test cover?
It should cover the deployed covered-item and documentation discovery path, request submission, case ownership, attachments, status and response access, and the roles that can act on each case. The test should use synthetic approval, denial and more-information cases within safe workflow limits.
Are Da Vinci CRD, DTR and PAS required by CMS-0057-F?
No. CMS lists them as recommended implementation guides, not currently required guides. Test the versions and flows the payer actually deploys, while checking applicable required standards separately.
What evidence should the payer request from the test?
Request an inventory of tested assets and roles, policy assumptions, synthetic fixtures, a lane-by-resource matrix, redacted evidence for validated findings, explicit exclusions, remediation ownership and retest results. The evidence should show both allowed and denied access decisions.
Related reading
References
Talk to Stingrai
Bring your payer API map, authorization policy and synthetic test fixtures to Get a Quote, or book a free discovery call to define the test boundaries and evidence you need.
