AWS for Industries
Meet CMS-0057-F while accelerating AI transformation with AWS HealthLake
The Centers for Medicare & Medicaid Services (CMS) estimate that prior authorization costs payers and providers $20–50 per hour and takes an average of 13 hours per week, adding up to hundreds of hours and tens of thousands of dollars per physician annually. For healthcare payers navigating Fast Healthcare Interoperability Resources (FHIR)-based compliance with the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), the strategic question isn’t whether to comply. The question is if your compliance investment create an extensible AI data foundation, or a siloed point solution.
Payers who treat CMS-0057-F as a modernization initiative, not just a regulatory checkbox, will emerge with a FHIR data and AI foundation: One that powers agentic AI workflows, real-time analytics, and operational automation across the enterprise.
In this post, we show how you can use AWS HealthLake to meet CMS-0057-F requirements while building a FHIR data solution that accelerates your broader digital transformation.
What CMS-0057-F means for your organization
CMS-0057-F is a federal regulation released on January 17, 2024, that mandates standardized, API-driven prior authorization and data exchange through HL7® FHIR® standards. It covers the Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs. CMS-regulated payers—including Medicare Advantage organizations, state Medicaid programs, Children’s Healthcare Insurance Program (CHIP) programs, and Qualified Health Plan issuers on Federally Facilitated Exchanges—face an aggressive compliance timeline:
- January 1, 2026: Operational provisions take effect. Prior authorization decisions within 72 hours (urgent) or 7 calendar days (standard), specific and actionable denial reasons, and public reporting of prior authorization metrics.
- January 1, 2027: All four FHIR-based APIs must be fully operational: Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization. The Prior Authorization API follows a three-step FHIR workflow: Coverage Requirement Discovery (CRD), Documentation Templates & Rules (DTR), and Prior Authorization Support (PAS).
The industry standard implementation guides (IGs) for the Prior Authorization API are published by Da Vinci. Da Vinci is a private sector initiative of providers, payers, and vendors, working together to accelerate HL7 FHIR adoption. An implementation guide is a set of rules about how FHIR resources are used in specific use cases, with associated documentation to support and clarify the usage. See Table 1 for the list of implementation guides supporting CMS-0057-F requirements that are supported by HealthLake.
| API endpoint | Key requirements | Supported IGs |
|---|---|---|
| Prior Authorization Service API | FHIR-based prior authorization submit and inquiry. Urgent: 72 hours, Standard: 7 calendar days. Denial must include clinical basis. CRD: real-time coverage discovery. DTR: documentation templates. | PAS, CRD, DTR, CDex |
| Provider Access API | Share claims and clinical data with attributed providers. Member Attribution Lists (ATR 2.1). $member-add and $member-remove reconciliation. $davinci-data-export for bulk retrieval. | PDex, ATR 2.1 |
| Payer-to-Payer Data Exchange API | Exchange member data during coverage transitions. $bulk-member-match across health plans. Consent management (HRex). 1-business-day response SLA. | PDex, HRex |
| Patient Access API + CMS Reporting | Extends 9115-F with PA status visibility. Members see denial reasons and clinical data. Public reporting: approval and denial rates, decision times, overturn rates | CARIN BB, Metrics |
Table 1: CMS-0057-F API requirements and associated Da Vinci implementation guides supported by HealthLake as of July 2026
Why CMS-0057-F is a business transformation moment
The Prior Authorization API requirement presents challenges that touch nearly every function of a payer organization. These cross-functional requirements are what make it different from previous regulatory mandates:
It forces data standardization. Payers manage multiple system integrations while bridging the gap between legacy systems and modern FHIR requirements. This includes implementing secure API endpoints, converting proprietary data formats to FHIR standards, and maintaining data consistency across various healthcare partners and systems. For the first time, payers must expose clinical and administrative data through standardized FHIR APIs, creating a single source of truth that downstream teams—from care management to finance—can build on.
It breaks down system silos. Payers must meet specific FHIR implementation requirements (provided in implementation guides) while adhering to security and privacy regulations. Legacy architectures that store prior authorization data in one system, claims in another, and member records in a third can’t meet real-time API response requirements. These requirements drive architectural consolidation.
It creates an AI-ready data layer. Interoperability implementation teams face strict timelines while impacted stakeholders, including Compliance, Operations, Digital Product, Analytics, and Member Service teams, must stay aligned. Structured FHIR data is inherently computable. After you have the structured data, generative AI and analytics workloads can access it without additional extract, transform, and load (ETL) pipelines or data warehouses.
The payers who recognize this convergence are investing in an architectural approach rather than a point solution. They’re asking how to build once and use many times. The first step in your interoperability roadmap is deciding on your technical approach:
- Purchase an end-to-end software solution. Fastest time-to-compliance but creates vendor lock-in and limits future extensibility.
- Build the FHIR infrastructure in-house. Maximum control and customization, but requires specialized HL7 expertise, ongoing maintenance of more than seven implementation guides, and significant engineering investment. Industry estimates for enterprise-wide in-house FHIR build can require 12–16 dedicated engineers and a multi-million dollar commitment over 18–24 months, which leaves little margin for error against the January 2027 deadline.
- Build on a managed FHIR service. Balances speed-to-compliance with long-term flexibility. You own the data and the innovation roadmap, without maintaining FHIR middleware.
How HealthLake accelerates CMS-0057-F compliance
AWS HealthLake is a fully managed healthcare interoperability and intelligence service. For CMS-0057-F compliance, it streamlines the path to production by maintaining FHIR implementation guides (see Table 2) and automatically provisioning the required CMS API endpoints in a no-license, pay-as-you-go model.
HealthLake exposes four dedicated FHIR R4 endpoints mapped to each CMS workflow:
- /priorauthservice/v2/r4/ — supports $submit, $inquire, and $questionnaire-package operations
- /provideraccess/v2/r4/ — supports $member-add, $member-remove, $attribution-status, $confirm-attribution-list, and $davinci-data-export
- /payertopayerdx/v2/r4/ — supports $member-match, $bulk-member-match, $bulk-member-match-status, and $davinci-data-export
- /patientaccess/v2/r4/ — supports FHIR R4 Read, Search, CARIN Blue Button 2.0/2.1, and prior authorization status resources
Built-in CMS compliance metrics track per-API usage by URI type dimension across all four endpoints, with per-user and per-app audit trails through Amazon CloudWatch and AWS CloudTrail. Pre-built metrics include call count, latency, errors, and availability.
Figure 1: AWS HealthLake compliance service reference and four workflows for CMS-0057-F compliance
FHIR compliance, out of the box. HealthLake comes with pre-loaded FHIR IGs aligned with Da Vinci guidelines, Substitutable Medical Applications, Reusable Technologies (SMART) on FHIR authorization, and CMS requirements for 0057-F and 9115-F (see Table 1). It provides dedicated API endpoints for Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization workflows, with all of the more than 15 required FHIR operations ($submit, $inquiry, $member-match, $davinci-data-export, and more) available as capabilities. FHIR Subscriptions support real-time event-driven notifications, so downstream systems are automatically informed when prior authorization determinations, member eligibility changes, or coverage updates occur, without polling.
Performance that scales with your member population. HealthLake processes up to 50,000 FHIR resources per second in large-scale deployments, delivering 180 million resources per hour in sustained CRUD operations. Response latency is sub-60 ms at the ninetieth percentile with a 0.00% error rate across all operations. It maintains consistent performance from 10 GB to petabyte-scale datasets in a single unified FHIR datastore. Customers have achieved 8,000 sustained transactions per second in production workloads. For payers processing millions of prior authorization requests annually, this means real-time API response requirements are met without capacity planning or performance engineering on your side.
Economics that scale. Pay-as-you-go pricing eliminates upfront licensing and replaces fixed infrastructure costs with usage-based pricing. As a fully managed service, HealthLake includes infrastructure management, FHIR server patching, and scaling, which reduces operational overhead that would otherwise grow with every datastore added. Built on the top rated public cloud for healthcare (KLAS Research), it provides the enterprise-grade security and technical depth to support both your compliance deadlines and your multi-year modernization strategy.
| Implementation guide | Version |
|---|---|
| Security for Scalable Reg, AuthN, and AuthZ | 1.1.0 |
| CARIN Blue Button | 2.0.0 |
| Da Vinci Patient Cost Transparency | 1.1.0 |
| CARIN Digital Insurance Card | 1.1.0 |
| CARIN Consumer Real-Time Pharmacy Benefit Check | 1.0.0 |
| Da Vinci Coverage Requirements Discovery | 2.1.0 |
| Da Vinci Documentation Templates and Rules | 2.1.0 |
| Da Vinci Prior Authorization Support | 2.1.0 |
| Da Vinci Health Record Exchange (HRex) | 1.1.0 |
| DaVinci Payer Data Exchange (PDex) US Drug Formulary | 2.1.0 |
Table 2: Implementation guide versions supported by HealthLake as of July 2026
From compliance to competitive advantage
After your FHIR data layer is operational, compliance becomes a byproduct of your operating model rather than a separate budget. The same infrastructure that satisfies CMS-0057-F becomes the engine for initiatives that directly impact your medical loss ratio (MLR), administrative cost ratio, and member experience scores.
A top-5 US national payer uses AWS HealthLake to power a unified data interoperability layer across multiple business units. Customers see reduction in total cost of ownership, no license fees, significantly reduced engineering overhead, and faster time to market. This same FHIR foundation is now enabling customers to build generative AI workloads for personalized care and advanced analytics.
Analytics that deliver payer value
Beyond FHIR APIs, HealthLake provides zero-ETL access to flattened, SQL-ready FHIR data through Apache Iceberg tables registered in AWS Glue Data Catalog. AWS Lake Formation provides fine-grained access controls and data governance over these tables, so your security teams can enforce column-level and row-level permissions aligned with HIPAA and organizational policies. Your analytics teams can query this data directly using Amazon Athena (Trino) or Amazon Redshift Spectrum, and build dashboards with Amazon Quick, without building separate data pipelines.
For health plans, this makes analytics use cases that traditionally require months of data engineering available: Healthcare Effectiveness Data and Information Set (HEDIS) measure calculation for entire member populations, CMS Star Rating performance tracking, risk adjustment factor (RAF) scoring, network adequacy reporting, and cost-of-care trend analysis. Data science teams can use Amazon SageMaker Unified Studio to build, train, and deploy machine learning (ML) models directly against HealthLake Iceberg tables for predictive analytics such as readmission risk scoring, member churn prediction, and fraud detection.
AI agents that reason over FHIR data
The open source AWS HealthLake MCP server provides a Model Context Protocol (MCP) interface that powers AI agents built on Amazon Bedrock AgentCore to reason over FHIR data. For payers, this opens high-value agentic use cases: an automated utilization management agent that retrieves member clinical history, evaluates medical necessity criteria against payer policies, and generates a determination with supporting evidence. A prospective risk adjustment agent that continuously reviews incoming clinical data, identifies suspected Hierarchical Condition Category (HCC) gaps, and triggers provider outreach for documentation. A member engagement agent that proactively identifies care gaps from HEDIS data, drafts personalized outreach, and schedules follow-up across channels. A denials management agent that analyzes denial patterns, auto-generates appeal letters with clinical citations, and routes complex cases to human reviewers. These agents operate on the same governed FHIR data layer used for compliance, with no separate data infrastructure required.
The compounding value
The value compounds across the organization:
- Unified FHIR data improves risk adjustment accuracy.
- Better risk scores fund care management programs.
- Proactive care reduces claims costs. Lower costs improve margins. Each investment reinforces the next.
Executive impact across use cases:
- Prior authorization automation. Reduced cycle time, lower administrative cost per decision, improved provider satisfaction scores.
- Intelligent member services. Lower average handle time, higher first-call resolution, improved member retention metrics.
- Proactive cost of care management. Reduced inpatient utilization, improved CMS Star ratings, measurable impact on MLR.
Conclusion
In this post, we showed how you can use AWS HealthLake to meet CMS-0057-F requirements while building a FHIR data environment that drives long-term business value. Approaching this mandate as a transformation opportunity will compound your organization’s investment across every function that touches clinical and administrative data.
HealthLake reduces the compliance effort with out-of-the-box FHIR capabilities, automated data normalization, and built-in security controls. Beyond compliance, it transforms unstructured health data into standardized, analytics-ready formats that power generative AI, operational automation, and the next generation of member experiences.
To get started, explore the AWS HealthLake Developer Guide. You can also contact an AWS Representative to learn how AWS can help you achieve compliance with CMS-0057-F and accelerate your modernization strategy.
If you have questions or want to share your implementation experience, leave a comment on this post.