CMS-0057-F will test operations, not just APIs
As the 2027 interoperability deadlines approach, health systems must move beyond FHIR connectivity to build governed data pipelines, cross-functional workflows and accountable operating models that can securely validate, route and act on increasingly automated healthcare data exchange.
The most visible CMS-0057-F technology deadlines arrive in 2027, but the rule is not simply an API implementation milestone. The final rule requires specified Medicare Advantage organizations, Medicaid and CHIP programs and plans, and Qualified Health Plan issuers on the federally facilitated exchanges to implement or expand several FHIR-based APIs, generally beginning January 1, 2027. For health systems, the direct API mandates largely fall on those impacted payers, yet providers will still feel the operational consequences as payer-provider exchange becomes more standardized and electronic prior authorization expands.
The rule also includes operational requirements that began earlier, including prior authorization metrics and process changes in 2026, along with a new electronic prior authorization measure for eligible clinicians, hospitals and critical access hospitals beginning with 2027 reporting periods. That makes the transition an enterprise operating challenge as much as a technical one, because payer, provider, health information management and compliance workflows will have to absorb more standardized digital exchange without losing control of identity, purpose, privacy or accountability.
An API can move data quickly, but it cannot by itself determine whether the right data reached the right party for the right reason. If organizations build endpoints without aligning the teams that govern requests, validate data, manage exceptions and act on the information, they can still create bottlenecks, privacy disputes and downstream rework even when the underlying technology is functioning as designed.
Payer demand is already straining manual workflows
The pressure is not new. MRO's internal tracking showed a 36% increase in payer requests for information between 2021 and 2022, an employer-generated data point that should be viewed as an operational signal rather than a current industry census. More broadly, payer requests that once clustered around risk adjustment and quality-review seasons have increasingly become year-round work, which makes episodic staffing fixes less effective.
Health information teams are also operating with limited workforce capacity. A national AHIMA survey conducted with NORC found that 66% of health information professionals reported understaffing at their organizations during the prior two years, with consequences that included slower information release, reimbursement problems, and data-quality concerns. Those workforce constraints matter because greater digital throughput does not eliminate the need for human oversight; in many cases, it shifts that work toward exception handling, governance and validation.
Administrative burden is substantial as well, although it should not be attributed to payer record requests alone. The American Hospital Association, citing Strata Decision Technology, reported that administrative costs account for more than 40% of the total hospital expenses incurred in delivering care. Request volume, staffing pressure and administrative expense come from different datasets and different years, but together they illustrate the environment into which the 2027 interoperability requirements are arriving.
Automation needs a governed data pipeline
FHIR provides the transport foundation, but standards alone do not complete the workflow. CMS identifies FHIR Release 4.0.1 and specified USCDI data classes and elements among the API standards used for the relevant exchange requirements, while also allowing certain updated ONC-approved standards when they do not disrupt end-user access. The distinction matters because FHIR describes how information can be exchanged; it does not automatically clean source data, reconcile identities, interpret scanned records or decide whether a disclosure is appropriate.
A modern data pipeline may therefore combine standardized APIs with other technologies where the workflow requires them. FHIR can normalize the transport of structured data, while optical character recognition, natural language processing or other AI tools can help extract usable information from scanned documents and unstructured records, and workflow software can route validated outputs to the appropriate destination. None of those complementary tools is mandated by CMS-0057-F, and each adds its own need for quality assurance, auditability and exception management.
The practical goal is not automation for its own sake. It is to reduce repetitive manual retrieval while keeping humans focused on the decisions that require context, such as ambiguous patient matching, incomplete documentation, unusual disclosure requests or data that fail validation before they move downstream.
Match the delivery model to the work
Not every exchange should use the same delivery pattern. On-demand digital retrieval is useful when an authorized user or system needs current information quickly from connected FHIR endpoints, health information exchanges or other active data sources. That model works best when identity, attribution and access rules are already established, because speed is valuable only when the request can be trusted and the returned data can be interpreted in context.
Structured data packages serve a different purpose. Clinical summaries, C-CDA documents and bulk FHIR exports can support population health, analytics and other workflows that depend on larger datasets rather than one immediate clinical question. These exchanges still require normalization, deduplication and data-quality checks before downstream teams can assume that a technically valid payload is analytically complete.
A third pattern is the workflow-ready record package, in which data from multiple sources are assembled for a specific operational use such as quality review, risk adjustment or payment-integrity work. Automation can accelerate assembly and summarization, but the package still needs clear provenance and validation so users can distinguish source data from machine-generated interpretation. Organizations may ultimately use all three models, but the choice should follow the use case rather than a one-size-fits-all architecture.
Governance has to travel with the data
Compliant API access does not mean unrestricted access to every part of the record. Health information management, privacy and compliance teams should define role-based and purpose-based access rules, identify when additional review is required, and document how automated exchanges handle sensitive information. The HIPAA Privacy Rule generally requires covered entities to apply the minimum necessary standard to uses, disclosures and requests for payment and healthcare operations, while recognizing important exceptions, including provider-to-provider requests for treatment and disclosures made pursuant to an individual authorization.
That nuance is important when organizations design automated release rules. Department restrictions can limit internal access based on role and need, while note-type or sensitivity rules can route certain records for specialized review rather than simply stripping them from every feed. For disclosures to which the minimum-necessary standard applies, organizations should configure repeatable protocols that release the information reasonably needed for the purpose and preserve an auditable record of what was sent.
Automation should also make governance more visible rather than bury it. Teams should be able to reconstruct who or what requested information, the stated purpose, which data were released, what rules were applied and where an exception required human review. Those controls become more important as throughput increases because a high-speed error is still an error, only one that can propagate faster.
Make 2027 a cross-functional operating model
Organizations preparing for 2027 should assign operational ownership before they scale technical connections. IT teams can own endpoint performance, integration and observability, while managed care teams clarify payer use cases and contractual expectations; HIM leaders oversee disclosure workflows and data stewardship; privacy and compliance teams define permissible uses and escalation rules; and cybersecurity teams manage identity, authentication and access controls. Clinical, revenue cycle and operational leaders then need to confirm that the information arriving through those channels can actually be consumed by the workflows expected to use it.
Performance monitoring should therefore go beyond whether an API is up or down. Useful dashboards can track failed calls, latency, incomplete payloads, unresolved patient or provider attribution, manual fallback rates, exception queues and the amount of rework required after an exchange is technically complete. Connecting those technical measures to operational outcomes gives executives a better view of whether interoperability is reducing burden or merely moving it somewhere else.
CMS-0057-F is accelerating an important shift toward standards-based exchange, but sustainable interoperability will require more than endpoint availability. Healthcare leaders should use the remaining runway to inventory data flows, define accountable owners, test governance rules and stress-test the manual processes that take over when automation fails. The decisive question for 2027 is not simply whether an API can answer a request; it is whether the organization can trust, govern, route and act on the data once it arrives.
Anthony Murray, CISSP, is Chief Interoperability Officer and Information Systems Security Officer at MRO, a clinical data exchange technology and services provider.