Great expectations from payers used to be a complaint more than a standard. Providers waited days for prior authorization answers with little explanation, and members found doctors in the directory who had left the network years ago. Federal rules have now turned several of those expectations into deadlines.
This guide is for health plan leaders, payer operations and IT teams, and the vendors building payer software. It sets out what providers and members expect from health plans, explains the prior authorization timeframes and reporting in the CMS Interoperability and Prior Authorization final rule, covers provider directory requirements, and describes the systems that let a plan meet these expectations without adding staff for every new rule.
What are the great expectations from payers?
Modernizing payer systems?
Agnotic builds software for health plans, from prior authorization APIs and decision tracking to member apps and directories.
The great expectations from payers are fast, explained prior authorization decisions for providers, and accurate information and responsive service for members. CMS-0057-F now sets decision timeframes and denial explanations for many government-program payers, and the No Surprises Act sets directory accuracy rules for group and individual health plans.
These expectations overlap. A provider who cannot get an authorization answer passes the delay to the patient, and a member who chooses a doctor from a wrong directory listing ends up calling both the plan and the practice. Meeting them depends on the same thing: current data and systems that share it quickly.
What do providers expect from health plans?
Providers expect health plans to make prior authorization requirements easy to find, accept requests electronically, decide quickly, explain denials specifically and pay clean claims on time. Most frustration comes from uncertainty: not knowing whether a service needs approval, what documentation is missing or when a decision will arrive.
- Clear requirements: A way to check whether a service needs prior authorization before the patient leaves the office.
- Documentation lists: The exact records the plan needs, so requests are complete the first time.
- Electronic submission: Requests sent from the EHR rather than by fax or a separate portal.
- Predictable decisions: Known timeframes and status updates while a request is pending.
- Specific denials: A reason that tells the provider what to fix or how to appeal.
- Accurate payment: Claims paid according to the contract, with remittance details that match.
What prior authorization timeframes apply now?
Under the CMS Interoperability and Prior Authorization final rule, CMS-0057-F, affected payers must decide expedited prior authorization requests within 72 hours and standard requests within 7 calendar days. These timeframes took effect on January 1, 2026.
The rule covers Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans and CHIP managed care entities, and issuers of qualified health plans on the Federally-facilitated Exchanges. CMS's FAQ notes that these exchange issuers are not subject to the new decision timeframes, although other parts of the rule apply to them.
Meeting 72 hours across weekends and holidays is an operational challenge. Plans need intake that does not wait for business hours, automated checks for complete documentation, and queues that show reviewers which requests are closest to their deadline. The clock should start when a request arrives, not when someone keys it in.
What must payers explain and report about prior authorization?
Payers must give a specific reason when they deny a prior authorization request and must publicly report prior authorization metrics each year on their websites. The initial set of metrics was due by March 31, 2026, so providers and members can now compare how plans perform.
- Any channel: The specific denial reason is required whether the request came by portal, fax, email, mail or phone.
- Drugs excluded: The rule's prior authorization provisions do not apply to decisions about drugs.
- Existing notices: Written denial notices required by other rules still apply alongside the new requirement.
- Public posting: Metrics are posted on the payer's own website every year, not only filed with CMS.
A specific reason helps both sides. Providers can fix and resubmit a request instead of guessing, and plans see fewer repeat submissions of the same incomplete request. That only works if reviewers record the reason in a structured form the notice and the API can use, rather than in free-text notes.
Public metrics change the conversation with provider groups and regulators. Plans that track approval rates and decision times internally, by service type and by reviewer, can spot slow areas well before the annual report makes them visible.
Which interoperability APIs come next?
CMS-0057-F also requires affected payers to build FHIR-based APIs, with most compliance dates in January 2027. A Prior Authorization API lets provider systems learn whether authorization is needed, what documentation is required, and submit and track requests. A Provider Access API shares member data with in-network providers, and a Payer-to-Payer API moves data when members switch plans.
These APIs turn the provider expectations above into technical requirements. A provider's EHR can ask the payer, at the moment of ordering, whether a service needs approval, then send the request with the right documents, instead of the staff member checking a portal and faxing records.
CMS recommends the HL7 Da Vinci implementation guides for this work: Coverage Requirements Discovery to answer whether authorization is needed, Documentation Templates and Rules to gather the required information, and Prior Authorization Support to send the request. Members gain too, because prior authorization information, excluding drugs, must also be added to the Patient Access API.
Plans that wait until late 2026 to start these builds face a crowded vendor market and little time to test with provider partners. Starting with the rules library and authorization data model makes the API work far easier, because the API simply exposes data the plan already manages well.
What do members expect from health plans?
Members expect health plans to tell them accurately which doctors are in network, what a service will cost, whether it needs approval and how to get help. They also expect answers in the channel they choose, whether that is an app, a website or a phone call, without repeating their story at each step.
- Accurate directories: Doctors listed as in network who actually are, at the address shown, accepting patients.
- Cost estimates: The member's share for common services before scheduling.
- Authorization status: Updates on pending requests without calling the provider and the plan.
- Access to records: Claims and clinical data available through apps the member chooses.
- Helpful service: Agents who can see the member's recent claims, authorizations and calls.
Members judge a plan most harshly at stressful moments: a denied service, a surprise bill or a hospital discharge. Plans that send proactive updates at those points, such as a text when an authorization is approved, take pressure off both the member and the call center.
Data sharing is part of member service now. The Payer-to-Payer API carries a member's claims, clinical data and certain prior authorizations to a new plan, with the member's permission, so care does not restart from nothing after a plan change.
What do provider directory rules require?
Under the No Surprises Act provisions in 42 U.S.C. 300gg-115, group health plans and issuers must verify and update directory information at least every 90 days and update the directory within 2 business days of receiving new information from a provider. They must answer member questions about a provider's network status within 1 business day.
Plans must keep a record of each network status response for at least 2 years. If a member relies on wrong directory information showing a provider as in network, the plan generally cannot charge more than in-network cost sharing for that service.
That last protection puts a price on bad data. Directory errors become claims paid at in-network cost sharing for out-of-network providers, which makes automated verification with providers a financial decision as well as a compliance one. Plans that send providers short, prefilled verification requests every quarter, and flag listings that go unconfirmed, keep far fewer stale entries than plans that wait for providers to report changes.
How can payers meet these expectations with software?
Payers meet these expectations by connecting the systems that hold authorization, provider and member data and exposing them through APIs and member tools. The goal is one source of truth for each fact, so the portal, the API, the call center and the directory all give the same answer.
- Authorization platform: Intake from APIs, portals and fax into one queue, with deadline tracking and reason capture.
- Rules library: Coverage and documentation requirements stored as data, served to providers through the Prior Authorization API.
- Provider data hub: Verified provider records fed to the directory, claims and network management systems.
- Member data layer: Claims, authorizations and clinical data available to apps, agents and the Payer-to-Payer API.
- Reporting: Metrics computed from the authorization platform itself, ready for annual publication.
Where health plans fall short
- Fax-first intake: Requests arriving on paper, keyed in by hand and timed from when they are typed, not received.
- Generic denials: Denial letters built from codes that do not tell the provider what was missing.
- Directory lag: Provider changes sitting in email inboxes for weeks before the directory updates.
- Siloed service: Call center agents who cannot see authorization status or recent claims.
- Late metrics: Numbers assembled by hand from several systems shortly before the deadline.
The common thread is data entered once and copied many times by hand. Each manual copy adds delay and error, and each one becomes a point where a deadline can be missed without anyone noticing until a provider complains.
How Agnotic can help
Meeting provider and member expectations is now mostly a systems problem. Agnotic Technologies builds software for health plans, including prior authorization platforms with deadline tracking and structured denial reasons, FHIR APIs for CMS-0057-F and the reporting behind the annual metrics.
Agnotic also builds provider data hubs with automated verification, directory services that update within the required window, and member apps and agent tools that show the same authorization, claims and network data.
Meet provider and member expectations
Explore software for health plans and payers, or read more practical guides from our engineers.
Related reading on Agnotic
Continue with CMS programs, Epic Payer Platform, AI claims processing and eligibility checks.
