Onyx Blog
CMS-0057 Was Just the Start: Building the Right Foundation for CMS-0053
Health plans have spent the last several years preparing for CMS-0057. That work has focused on APIs, FHIR implementation, prior authorization workflows, and the January 1, 2027 deadline.
That progress matters. But as organizations move from planning to production, a broader reality is coming into view: interoperability is not just about whether data can move. It is about whether the data being exchanged is complete, trusted, and usable in the workflows where decisions are made.
That is why CMS-0053 deserves attention now.
CMS-0057 establishes the framework for API-based exchange across Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization. It gives health plans a standards-based path to make clinical and claims data available through modern APIs.
But APIs only expose the data available through those channels. They do not automatically capture the full clinical picture.
Much of the information payers and providers rely on every day still lives in clinical documentation: discharge summaries, progress notes, diagnostic reports, medical records, and supporting attachments tied to claims and utilization workflows. For decades, those documents have moved through fax, portals, manual upload, and fragmented retrieval processes.
CMS-0053 begins to address that gap by standardizing how healthcare attachments are submitted and exchanged electronically. In that sense, it is not separate from the CMS-0057 conversation. It builds on it.
CMS-0057 advances access. CMS-0053 brings the industry closer to completeness.
A payer may have APIs in place and still lack the clinical context needed to support accurate decisions. A provider may be able to connect to an endpoint and still need to send supporting documentation outside the API workflow. A plan may meet a technical requirement and still rely on manual review to interpret the information that matters most.
That is the gap health plans need to think about now.
If document-based clinical data is treated as a separate problem, the CMS-0057 foundation may be compliant but incomplete. It may move data, but not the full record. It may satisfy an API requirement but still leave downstream teams dependent on manual processes.
And in production, those gaps become visible quickly.
They show up in claims decisions, prior authorization workflows, risk adjustment, quality measurement, care management, payment integrity, and audit readiness. These are not abstract interoperability use cases. They are the operational workflows where clinical data either creates value or creates friction.
It is easy to think of attachments as administrative paperwork. In reality, they often contain the evidence behind the decision.
They explain why a service was performed, what conditions were documented, what care was delivered, and what justification exists for payment, quality, or audit outcomes.
That makes CMS-0053 important beyond claims administration. It creates a path for more of the clinical record to move digitally and consistently. But that also creates a new challenge: once the documents move electronically, can the organization actually use them?
A digital attachment is still not automatically usable. Clinical documents are complex. Some are semi-structured. Many are unstructured. The same information may appear in different formats depending on the source system, the provider workflow, and the type of documentation being exchanged.
To create value, health plans need to go beyond receiving and storing documents. They need to ingest clinical data at scale, normalize it, associate it with the right member and encounter, extract meaningful insights, and make that information available to the systems and teams that depend on it.
That is where the conversation shifts from compliance to operational maturity.
CMS-0057 and CMS-0053 should not be managed as disconnected regulatory projects. They are part of the same clinical data strategy.
APIs provide access to structured data. Attachments provide the documentation that often completes the record. One without the other leaves gaps.
Those gaps create rework. If APIs are built without a plan for the clinical documentation that sits outside them, organizations may find themselves rebuilding data pipelines, reworking workflows, and creating parallel processes later.
The better approach is to design for structured and unstructured data together from the start. That means thinking about document intelligence, not just document exchange. It means asking how clinical data will be used after it is received. And it means building a foundation that can support multiple workflows across the enterprise, rather than solving one mandate at a time.
CMS-0057 gets the APIs live. CMS-0053 raises the next question: is the clinical data behind those APIs complete and usable enough to support the work that depends on it?
That is why this matters now.
The organizations that get this right will not treat CMS-0057 as a finish line. They will use it as the foundation for a broader clinical data strategy—one that brings together APIs, attachments, structured data, unstructured documents, and the operational workflows that depend on them.
CMS-0057 moves the industry toward standardized access. CMS-0053 makes clear that access is only part of the job. CMS-0057 Prior Authorizations answers the “why perform a service”. CMS-0053, using a different transport and data container, answers the “what was done” question. They are different phases of the patient/member experience and together tell the story of the member’s care journey. When viewed in this light the real opportunity is to build once, avoid rework, and create a foundation where clinical data can be acquired, understood, and used across the business.
If your organization is working through CMS-0057, this is the right moment to look beyond API go-live and ask whether the foundation you are building can support the clinical data, documentation, and workflows that will come next.
That means looking at more than technical readiness. It means understanding where API, data quality, workflow, and implementation gaps could create risk or rework later.
At Onyx, we offer a complimentary CMS-0057 readiness review that can help identify those gaps now — while there is still time to address them.
Learn more and request a free CMS assessment:
https://info.onyxhealth.io/cms-0057-readiness-check-from-onyx
