What Auditors Actually Want from Your Patient Access API (And What They Don’t)

Most engineering teams have never sat through a CMS audit. The mental model they bring to the conversation is borrowed from SOC 2, HITRUST, or PCI-DSS — extensive control-by-control walkthroughs, multi-week document requests, evidence binders measured in inches. That mental model is not wrong, but it is not specifically right for a CMS-0057-F or CMS-9115-F FHIR API audit either.

This post is what we have learned from reading published Inferno reports, OCR enforcement actions under information-blocking, CMS interoperability program audits of QHP issuers, and conversations with compliance officers who have been through the process. The Patient Access API is the focal example because it is the most-audited FHIR surface — it is the consumer-facing one, it has been live since CMS-9115-F enforcement in 2021, and it is the one expanded under CMS-0057-F to include prior-authorization data.

The framing: CMS-0057-F and its predecessor CMS-9115-F together require 5 FHIR APIs — four under CMS-0057-F plus CMS-9115-F’s Provider Directory. The Patient Access API exists in both rules; CMS-0057-F is the one that adds the new prior-authorization scope.

Before the audit: what triggers it

A CMS audit of a Patient Access API does not arrive at random. The triggers, in roughly descending order of frequency:

Complaint-driven investigation. Under CMS-9115-F enforcement, third-party app developer and patient complaints have been the loudest signal. A breaking schema change that prevents a SMART-on-FHIR app from ingesting Patient Access data tends to generate a CMS-portal complaint within days. Post-CMS-0057-F, expect the same pattern with prior-authorization data: a member’s app that cannot retrieve PA status will become a complaint.

Annual program review. QHP issuers on the Federally-facilitated Exchanges undergo annual program reviews that include API operational status. Medicare Advantage organizations have parallel review cycles tied to their plan-year recertification.

Periodic technical scans. CMS and ONC have, under predecessor rules, flagged structural non-conformance — missing mustSupport elements, cardinality violations, broken profile references — through technical scans of public endpoints. The scans are not exhaustive, but they catch the obvious failures.

Cross-rule investigation. An information-blocking complaint under the 21st Century Cures Act investigations can pull in API conformance evidence as a side question, especially if the complaint alleges that the technical surface “isn’t really compliant.”

The auditor’s first request will not be technical. It will be administrative: who is accountable, what is the rule scope you understand yourself to be subject to, and where is your interoperability program documented.

During the audit: what they actually ask

The technical questions, when they arrive, are narrower than most engineering teams expect. The auditor is not looking for a system architecture diagram. They are looking for evidence of three specific properties.

Property 1 — Operational status at specific timestamps

The first technical question is some variant of: “Was the Patient Access API operational and conformant on [specific date]?”

The dates are not arbitrary. They are tied to the trigger event — the date a complaint was filed, the date a scan was run, the start and end of a program-review window. The auditor is establishing a timeline, not interrogating a current snapshot.

The artifact that answers this question is not a current screenshot of your monitoring dashboard. It is a record from that historical moment, signed and replayable. See why application logs aren’t compliance evidence for why most logging stacks fail at this question.

Property 2 — Structural conformance to the published Implementation Guide

The second technical question is some variant of: “On that date, did the API’s structure match the IG version you certified against?”

This is where the six-category drift taxonomy becomes the auditor’s frame. They are looking for Mandatory Element Removal, Type/Cardinality Change, and Spec Version Mismatch — the three categories that map most directly to a finding under CMS rule text. Auth Deviation comes up in conjunction with information-blocking investigations. Structural Extension and Endpoint Behavioral Change rarely surface unless the complaint specifically alleged them.

The artifact that answers this question is a comparison report between the IG baseline and the observed CapabilityStatement, ideally signed and ideally produced at or near the date in question.

Property 3 — Continuity of evidence

The third technical question is the one most teams are unprepared for: “Can you show me that the evidence you just handed me is part of a continuous record, not a one-off generated for this audit?”

This is property 3 from our evidence post: continuity. A signed report dated the day of the audit is suspicious. A signed report dated the day in question, hash-linked to the prior signed report from the day before, hash-linked to the one before that, is not.

The auditor is not trying to trip you up. They are trying to do their job: distinguish between “this organization has been continuously compliant” and “this organization assembled an artifact in response to my request.”

The structural shape of evidence that survives this question is not new. Hash-linked signed claims are the standard pattern in financial audit, software supply chain (Sigstore, in-toto), certificate transparency, and clinical-trial integrity. Adopting it for FHIR conformance is mechanical once you have decided to.

What they don’t want

A surprising fraction of what engineering teams produce in response to an audit request is unwanted noise. The auditor will accept it because they are polite, but it does not move the conversation forward.

They do not want patient data. A CMS auditor for an interoperability program audit is not running a HIPAA breach investigation. PHI in the evidence binder is at best irrelevant and at worst creates new problems — the auditor now has PHI they did not need, with the chain-of-custody questions that follow. Conformance evidence is structural; payloads do not belong in it. (At Tessara: no patient data ever touches the pipeline. We probe public /metadata and declared profile snapshots only.)

They do not want application logs. Application logs are the wrong shape of artifact for the question being asked. They are mutable, vendor-coupled, and not signed. An auditor who wanted logs would have asked for logs.

They do not want vendor marketing material. “Our continuous monitoring platform claims X” is not evidence of X. The signed verdict from the platform is. The platform’s brochure is not.

They do not want internal Slack threads. “Engineering noticed the issue on the 14th and rolled back on the 15th” as a remediation story is fine. Pasted Slack screenshots as the evidence record are not.

They do not want a system architecture diagram. Exceptions exist — a CISO walking through the deployment topology is a reasonable conversation. But the audit is rarely about architecture. It is about what the API was doing on a specific date and how you know.

After the audit: what comes back

If a finding is issued, the response is structured and time-bounded. Three vehicles, in escalating severity:

Corrective Action Plan (CAP). The most common outcome. A documented set of remediation steps with milestones, deliverables, and oversight reporting. CAPs are not punitive on their face, but they are time-consuming to execute and they generate a paper trail that compounds if the next audit also issues findings.

Civil Money Penalty (CMP). Per-day penalties for continuing non-compliance, applied under the statutory authorities CMS uses for program integrity. The numbers are non-trivial; the public reputational exposure is often more painful than the dollar figure.

Public compliance reporting. CMS has historically included payer-level interoperability status in published reports. A negative entry in one of those reports affects member-acquisition channels, broker relationships, and competitive bids more than the underlying penalty does.

The trajectory through these vehicles is not deterministic. A clean CAP execution can close a finding without escalation. A repeated finding for the same root cause across two audits is the path to CMPs and public reporting. The single biggest lever in avoiding escalation is the quality of the evidence chain you can produce in response — a CAP for an organization with weeks of signed pre-finding conformance data is a different conversation from a CAP for an organization that “lost the logs.”

What this means for your roadmap

Three working conclusions for a payer engineering or compliance team reading this in May 2026:

The artifact you will hand the auditor is structurally specific. Signed, hash-linked, replayable, payload-free. Your current logging stack almost certainly does not produce this. The gap closes between now and January 1, 2027.
The continuous-evidence posture is a procurement decision before it is a technical one. Procurement cycles for payer-IT tooling run 9–12 months. If you are starting the conversation in October 2026, you are constrained to off-the-shelf options. If you are starting it in May 2026, you have time to evaluate and pilot.
The evidence has to predate the audit. A signed report dated the day of the audit is suspicious. The chain has to begin before any specific trigger event, not in response to one. That is what makes “continuous” load-bearing rather than a marketing word.

What we built

Tessara produces continuous, cryptographically verifiable conformance evidence for the FHIR APIs CMS-0057-F and CMS-9115-F mandate — including the Patient Access API at the center of this post. We probe only public /metadata and declared profile snapshots, sign every verdict with Ed25519, and hash-link the chain so the continuity property holds without trusting our infrastructure.

The mechanics are public. The evidence is replayable by any auditor with our public key, using any standard cryptographic library. See pricing for current design-partner slots, or contact us if you want to talk through what your specific audit posture would look like.

References: CMS-0057-F Final Rule (89 FR 8758), CMS-9115-F Patient Access Final Rule, 21st Century Cures Act Information Blocking, HHS OCR enforcement, HL7 FHIR R4.