6 lessons we learned from Opala about tackling CMS-0057-F

As the CMS-0057-F deadlines for 2026 and 2027 draw closer, payers are facing mounting regulatory pressure, major architectural decisions, and rising expectations from providers. 

To give the industry a clearer picture of real-world implementation, Firely and Opala hosted a fireside-style webinar sharing practical lessons on architecture, performance, provider adoption, and the ROI of modernization.

If you missed it, you can watch the full webinar on demand. 

Here are the key takeaways from the discussion. 

1. Most payers still haven’t started

The webinar opened with a live poll asking attendees how far along they were with CMS-0057-F. Only 2% said they were nearly compliant. Most had either not started (35%) or still planning (35%), while only 28% had begun implementation. 

That means 70% of organizations are still at square one. 

Opala’s SVP of Product and Customer Success Meghan Quint explained why: despite broad agreement that interoperability brings ROI, internal IT pipelines have been overwhelmed for years. Many payers simply couldn’t prioritize modernization without regulation forcing the issue. Until now, initiatives like prior authorization reform were “nice-to-haves” competing with a long list of must-do operational demands. 

Now that CMS has moved these requirements to the top of the list, organizations must accelerate. The challenge with CMS-0057-F is that the deadlines look far away until you factor in the real operational lift. Data cleanup, mapping, workflow redesign, clinical context alignment, system integration, and testing cycles can easily stretch across 12–18 months.  

The takeaway: there’s still time, but only if payers start now and move intentionally with a phased, pragmatic approach.

2. The modular approach to modern architecture

One reason Opala is ahead of the industry curve is that they chose a FHIR-first architecture even before CMS mandated it, which dramatically accelerated their readiness. 

This FHIR-first architecture means claims, clinical data, and provider data flow into a unified, longitudinal record that can be exposed through CMS-required APIs without complex rewrites. This foundation not only supported rapid implementation of Patient Access and Provider Access but also makes extending into CRD, DTR, and PAS far more efficient. 

In short: teams that treat FHIR as a foundation, not a checkbox, will move faster, spend less, and be ready for whatever CMS and NCQA mandate next.

3. A modular, incremental architecture is the only way to scale

Across the panel, one message came up repeatedly: don’t try to implement everything at once, but also don’t treat the CMS APIs as disconnected projects. 

Opala learned the hard way that it’s easy to over-scope a phase and try to deliver too much at once. Their biggest lesson: starting smaller and building incrementally delivers value faster, builds internal trust, and reduces risk. 

Firely echoed this from the technical side, adding an important nuance. While the rollout should be incremental, the underlying architecture must be planned holistically. Alexander Zautke emphasized that the CMS APIs aren’t four or five “separate projects” — they share data, depend on common models, and ultimately form one integrated ecosystem. 

That’s why both teams recommend a modular FHIR layer rather than siloed implementations. A unified FHIR foundation lets payers add CRD, DTR, and PAS as manageable extensions without scrapping existing systems. 

This combination of big-picture architecture, small-step execution dramatically reduces implementation risk, accelerates rollout, and ensures each step is testable and repeatable. 

4. Performance and scalability must be designed from day one

The speakers also highlighted the gap between “design assumptions” and “real-world usage”. 

Opala works with large datasets, sometimes exporting groups of 30,000–40,000 members. Through this work, they uncovered performance issues that only surface at production scale. 

Lakshmi Saravanan, Director of Software Engineering at Opala, shared how Opala and Firely collaborated to refine configuration settings, bulk export behavior, recursive resource handling, and Pub/Sub message flows for greater efficiency. These weren’t theoretical challenges, they were issues discovered only in end-to-end live environments. 

With CMS APIs expected to handle high-volume, near-real-time exchanges, scale isn’t a “later problem”; it’s foundational. 

The message was clear: you won’t find scale problems in a sandbox. Payers need to test with real data, real volume, and real provider scenarios early in the process. 

5. The ROI of FHIR goes far beyond compliance 

While CMS-0057-F is a regulatory mandate, the panelists made it clear that the business benefits extend far beyond meeting deadlines. 

Once data is in FHIR: 

• Quality measures (including FHIR-based HEDIS and dQMs) become easier to compute
• Value-based care programs get higher-quality, more complete data
• Longitudinal patient records become more actionable
• Patient-facing tools and AI/ML services become more feasible
• Providers receive clearer, more timely insights at the point of care 

As Opala noted, the real impact is turning compliance from a cost center into an ROI generator, while also delivering improvements in trust, communication, efficiency, and patient outcomes. 

Compliance may be the starting point, but automation, reduced administrative burden, and reusable data pipelines create lasting strategic value. 

6. Strong partnerships accelerate everything

Another consistent theme across the webinar was the importance of collaboration. 

Opala highlighted how hands-on coordination with Firely helped them overcome real-world performance and scaling challenges as they emerged. This was especially valuable when dealing with edge cases at scale, IG interpretation, and architectural flexibility. 

Collaboration also shortens the feedback loop. Issues that might take months to uncover in isolation surface early through joint testing. 

The takeaway: payer implementations move faster and avoid reworks when vendors and internal teams work together early, rather than tackling CMS requirements in isolation. 

Building toward future-ready interoperability

If one idea captures the spirit of the webinar, it’s this: you don’t need to rebuild everything, but you do need the right foundation. 

A modular FHIR layer allows payers to modernize incrementally, accelerate automation, meet CMS deadlines, improve provider relationships, and future-proof for dQMs, value-based care, and upcoming CMS rules. 

The organizations that start now, plan in phases, invest in scalable architecture, and choose the right partners will not only meet compliance milestones but also gain long-term strategic advantage. 

If you’d like to dive deeper, you can watch the full webinar recording.

Need a hand? Firely helps payers build CMS-ready FHIR APIs without ripping out existing systems. Get in touch for a strategy session or download our CMS-0057-F guide to learn more.