Full webinar Q&A: How Opala is tackling CMS-0057-F the right way

During our recent webinar, From Mandate to Momentum: How Opala is tackling CMS-0057-F the right way, attendees asked a wide range of thoughtful, practical questions about FHIR-based prior authorization, CMS requirements, implementation timelines, and real-world challenges on both the payer and provider sides.

Our speakers from Opala and Firely dug into everything from data consent and patient attribution, to architectural best practices, to the realities of getting CMS APIs live on time. For a summary of the webinar, read our key takeaways.

In this blog, we’ve compiled all the burning questions from the audience—along with responses from Firely’s experts. Dive in below for the full Q&A.

Question #1:

Which implementation guide should I follow for the Provider Access and Payer-to-Payer APIs? Is there an IG mandated by CMS?

Response: 

For the Provider Access and Payer-to-Payer APIs, CMS mandates US Core and recommends several Da Vinci IGs to support the workflows. Firely maintains a summary here: https://docs.fire.ly/projects/Firely-Server/en/latest/compliance/cms.html 

Question #2: 

How should we handle member opt-in/opt-out if a member is not willing to share their data? Is there an IG for that?

Response: 

Yes, the Da Vinci Payer Data Exchange (PDex) IG defines how to use FHIR Consent resources to represent member opt-in and opt-out decisions.  For example: https://hl7.org/fhir/us/davinci-pdex/StructureDefinition-pdex-provider-consent.html 

Question #3: 

What happens if a member switches payers, and the provider from the previous payer’s side is trying to access the members’ data which is now not available?

Response: 

This scenario requires two things: 

1. Consent (permission from the patient to share data), and

2. Attribution (confirming a valid provider–patient relationship under the new payer). 

This is where the Da Vinci Member Attribution (ATR) IG comes in. This uses Group resources to associate patients, providers, and payers. 

Question #4: 

What’s the biggest lesson learned the hard way? What would you do differently? 

Response: 

You can find a more in-depth answer in the webinar, but both Opala and Firely agreed on the same core lesson: don’t try to do everything at once. Opala found it’s easy to over-scope a phase and take on too much. Starting smaller and delivering incrementally created far better outcomes. 

Firely added that while delivery should be incremental, the architecture still needs to be planned holistically. The CMS APIs share data and models, so treating them as totally separate projects leads to rework. We recommend a modular FHIR layer + phased rollout. Small steps on top of a unified foundation. 

Question #5: 

How are payers thinking about implementing CMS-0057 in terms of scoping to just Medicare Advantage or offering electronic prior authorization across all of their plans (commercial and government)?

Response: 

Some payers are starting with Medicare Advantage since that’s what CMS mandates first. But in reality, running two different workflows (one for MA, one for commercial) quickly becomes messy. Providers want a single experience, not different rules per line of business. 

That’s why we recommend planning rollout across all lines, even if MA goes first. It saves time later and avoids redoing work further down the line. 

Question #6: 

There are lots of questions from the payer side around how to get member data – to associate patients, providers, and payers. And also, if some payers don’t have data in their system but in their association, which makes it a multi-system check.

Response: 

Most payers pull member and provider data from multiple systems. The simplest way to deal with that is to use the FHIR layer as the aggregation point, pulling and normalizing data from each source. 

IGs like PDex and ATR help define how patients, providers, and plans should be linked. This lets you return complete data through the CMS APIs without having to rebuild your internal systems right away. 

Question #7: 

Are you using FHIR version R4?  What plans do you have to move to FHIR version R6 when it becomes available? Or will you backport the changes between R6 and the version of FHIR you are using currently?

Response: 

CMS and US Core will remain on FHIR R4 for coming years, and that is the version currently mandated for all CMS-0057-F use cases. Many implementation guides are beginning to adopt R4 -> R6 backporting, which allows newer R6 features to be represented while still using R4. 

Firely Server offers multi-version FHIR support and can accommodate backported elements, making the eventual transition to R6 smooth once CMS and major IGs move in that direction.

Question #8: 

Have you implemented CRD and DTR IGs for Prior Auth? Do you use CQL to describe and share clinical guidelines and decision support rules? 

Response: 

Great question! Yes, Firely supports these IGs for speeding up the prior auth process on both the provider side and payer side. CQL can indeed be used to encode rules for answering a Prior Auth request from the payer side, and this is something Firely Server supports. 

Question #9: 

Does Firely Server support the $export operation for Groups?

Response: 

Yes, Firely Server supports FHIR Bulk Data $export, including Group-level exports. You can read more here: https://docs.fire.ly/projects/Firely-Server/en/latest/features_and_tools/bulkdataexport.html 

Question #10: 

Do you think population health analytics will become a bigger focus on the payer side once they receive enough FHIR data from prior auth?

Response: 

Yes, absolutely. Once payers start receiving cleaner, standardized FHIR data, it naturally opens the door to analytics use cases like risk scoring, quality measurement, and value-based care. FHIR makes population health work a lot easier than trying to analyze raw claims alone. This becomes even more valuable as digital quality measures (dQMs) move to FHIR. 

Question #11: 

Once the doctors and medical staff see the integration for CRD and DTR in the Medicare and Medicaid space, they are going to ask the payers why this is not supported for Commercial plans which will automatically be a norm across all the plans.

Response: 

Agreed!

Question #12: 

What opportunities, if any, are you seeing with CQL in the market for these small-to-medium size health plans? Or will they use other (eg., AI, manual) approaches?

Response: 

HEDIS has fully shifted to digital measures authored in CQL. Because these measures are machine-readable and evaluated directly against FHIR data, plans—especially smaller ones—no longer need proprietary or expensive black-box HEDIS engines. CQL allows clinical logic to be loaded and executed on a FHIR server in minutes, enabling consistent, transparent, and repeatable calculations. 

Beyond HEDIS, CQL on FHIR also supports custom rules, analytics, and data-quality assessment using the same standardized logic framework. For small and medium health plans in particular, CQL can streamline repeatable workflows such as coverage determination, prior authorization checks, and benefit rules. 

That said, adoption will vary: 

• Some plans will use CQL directly, especially those already investing in FHIR infrastructure or seeking more control over their logic.
• Others will adopt vendor tools that hide CQL behind graphical rule builders or low-code interfaces. 
• Some may lean on AI or semi-manual approaches, especially if they lack internal engineering capacity. 

CQL provides a standardized foundation for expressing clinical and operational logic, but smaller plans may choose a range of implementation paths depending on their technical maturity and resources. 

Question #13: 

What are the most common mistakes you see from orgs implementing FHIR?

Response: 

A few patterns show up again and again: 

• Treating each CMS API as a separate project.
• Underestimating data quality issues.
• Not bringing in the appropriate technical and subject matter experts onto the project.
• Skipping observability (logs, metrics, audit trails).
• Not testing with real-world volume or real provider scenarios. 
• Designing for payers first instead of provider workflow.

Most problems can be avoided by planning the architecture up front and starting small. 

Question #14: 

What are Firely’s plans for implementing support for bulk data filtering, sensitive data filtering, and removing payer specific data? Specifically, which support payer to payer and provider access API from the patient access data?

Response: 

Firely relies as much as possible on the SMART on FHIR standards for filtering data access, including for bulk data operations. This can be done at a very fine-grained level based on data in individual records. (https://docs.fire.ly/projects/Firely-Server/en/latest/security/permissions.html) 

On top of SMART on FHIR and granular access filters, we also support controlling access based on Consent records which can represent a Patient’s decision to opt-in or opt-out of their data being shared. (https://hl7.org/fhir/us/davinci-pdex/StructureDefinition-pdex-provider-consent.html) 

And beyond using standards, FHIR servers typically will also use a pattern for intercepting data requests to ensure the right data is filtered. Firely Server does this with custom plugins. (https://docs.fire.ly/projects/Firely-Server/en/latest/reference/architecture.html) 

A common approach is to use FHIR Security Labels to tag sensitive data and using the plugin to remove anything with the labels. We also see approaches by maintaining a sensitive data library that will allow resources to be filtered and/or redacted based on specified values so the data can be filtered on retrieval if it is not tagged. (https://hl7.org/fhir/R4/security-labels.html)  

Question #15: 

Is any part of the CMS mandate directed at providers? If not, when do we anticipate that?

Response: 

Right now, CMS-0057-F focuses on payers. That said, providers are deeply affected because CRD, DTR, and PAS only work when they’re integrated into clinical workflows, so even without a direct mandate, adoption pressure will be high. 

And as Alexander mentioned during the webinar, ONC’s HTI-1 rule and ASTP requirements are starting to introduce provider-side expectations around decision support, interoperability, and FHIR-based data exchange. These aren’t full mandates yet, but they signal the direction things are heading. 

Most experts expect stronger provider requirements (or incentives) once CMS sees enough payer-side progress. 

Question #16: 

How long does it take to develop these CMS APIs?

Response: 

It depends a lot on data readiness, architecture, and resourcing, but generally: 

• A payer starting from scratch might need 12–18 months for full implementation.
• A payer with a FHIR layer already in place can move much faster.
• Doing everything at once usually slows things down. We recommend a phased delivery as discussed in the webinar. 

The earlier you start, the more realistic the timeline becomes. 

Question #17:

Are PA denials automatically appealed on behalf of the patient? The appeal process is arduous and a patient centric process would seem to mandate this.

Response:  

No, CMS-0057-F doesn’t require automatic appeals. The appeals process still sits outside the automated FHIR APIs. But better data exchange and clearer rationale for decisions may help reduce the number of denials that get escalated in the first place. 

Question #18: 

Providers have typically been reluctant to external data entering their systems because of litigative risks. Do you think the mandate will override this?

Response: 

It will likely move things in that direction, yes. Because CMS is defining exactly what data must be shared and how it must be exchanged securely, providers will have more confidence in the process. But trust will still depend heavily on good audit trails, clear consent management, and robust security practices. 

Question #19: 

I work for the NHS in England, and am curious about what you might think the NHS could learn from the use of CMS-0057-F in the USA?

Response: 

A few themes apply internationally: 

• Standardized APIs accelerate interoperability
• Mandates create the momentum that voluntary adoption rarely achieves
• Shared infrastructure (FHIR, standard IGs, bulk data) reduces administrative burden
• Automation works best when providers and payers share the same data model 

While the NHS ecosystem is different, the principle is the same: Clean, accessible data unlocks better care and less paperwork.

Want to know more? 

If you missed the webinar, be sure to watch the recording and explore our key takeaways to see how CMS-0057-F can become more than a compliance requirement, serving as real momentum toward automation, interoperability, and long-term operational efficiency.

Want to take it a step further? 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.