For health insurers, the January 2027 prior-authorization deadline is not simply a FHIR endpoint launch. It is a test of whether data, intake, clinical review, communications, reporting, and Salesforce workflows operate as one controlled service.

That distinction matters now. CMS says certain regulated health plans must implement and maintain electronic prior-authorization and related interoperability APIs starting January 1, 2027. The exact date depends on payer type: the rule uses January 1 for Medicare Advantage organizations and state Medicaid and CHIP fee-for-service programs, while other affected plans follow applicable rating periods or plan years. The requirements cover medical items and services and generally exclude drugs under the 2024 final rule. CMS has proposed additional requirements for drugs, but that proposal should not be treated as final policy.

The deadline is close, but the larger risk is already visible. In guidance last modified on September 21, 2026, CMS clarified that the prior-authorization decision clock starts when the payer receives a request. For specified impacted payers, the maximum is 72 hours for an expedited request and seven calendar days for a standard request, subject to the patient's condition and program-specific rules. Those clocks apply whether a request arrives by API, portal, fax, phone, or another channel. CMS's updated process FAQ makes the operational implication plain: a modern API cannot compensate for fragmented work behind it.

Salesforce Health Cloud can be an important part of the solution. Its Utilization Management capabilities include FHIR-aligned data structures and APIs, guided workflows, business rules, clinical-review stages, queue routing, SLA tracking, and analytics. But the platform has to be connected to the payer's policy data, member and provider records, clinical systems, communications, and evidence model. Readiness is achieved when a complete request can move through that system correctly under normal and adverse conditions.

Start with scope, not software

Before changing Health Cloud, establish which legal entities, plans, products, and request types are in scope. CMS identifies impacted payers as Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed-care entities, and qualified health plan issuers on federally facilitated exchanges. The exact implementation date and some process provisions differ among them.

Create a scope register that records:

  • regulated entity and line of business;
  • applicable compliance date;
  • medical item or service categories;
  • intake channels used today;
  • system of record for each request and decision;
  • party responsible for clinical policy, review, integration, and reporting;
  • treatment of delegated utilization management; and
  • explicit exclusions, including the final rule's general exclusion of drugs.

Have regulatory counsel or a qualified compliance specialist validate this register. Salesforce configuration should follow the approved interpretation; it should not become the place where applicability is guessed.

Treat the API as an entry point to a service

CMS-0057-F encompasses more than one interface. CMS's current readiness page identifies Patient Access, Provider Directory, Provider Access, Payer-to-Payer, and Prior Authorization APIs. The Prior Authorization API must support coverage and documentation discovery as well as request and response behavior. CMS says a response must approve the request and identify when the authorization ends, deny it with a specific reason, or request additional information. CMS's API FAQ was also updated on September 21, 2026.

For a Salesforce-centered architecture, map each external interaction to its internal owner and system behavior. A useful chain is:

  1. Discover: Can the provider determine whether authorization is required and which documentation is needed?
  2. Submit: Does the payer receive a complete, traceable request with a reliable receipt timestamp?
  3. Normalize: Are member, provider, coverage, diagnosis, service, and supporting-document data mapped without silent loss?
  4. Route: Does Health Cloud assign the request to the correct administrative or clinical queue with the right priority?
  5. Decide: Can reviewers apply current policy, document their reasoning, and record item-level outcomes?
  6. Respond: Does the outbound response contain the required status, reason, and authorization end condition?
  7. Expose: Can providers, members, downstream APIs, and service teams see a consistent status?
  8. Evidence: Can the organization reconstruct the timeline and explain the outcome later?

An interface can pass a conformance test while this chain still fails. That is why CMS is urging organizations to test real workflows with EHR vendors and payer partners, not just validate the API in isolation. CMS's electronic prior-authorization guidance includes CRD, DTR, and PAS test resources and explicitly calls for early cross-party testing.

Build one clock across every intake channel

Health plans often measure API transactions separately from portal, fax, phone, or manual intake. CMS's September FAQ makes that separation dangerous for operational management: the applicable decision timeframes run regardless of channel, and calendar time is not business time.

The Salesforce design should therefore establish a canonical received timestamp and an auditable SLA calculation for every request. At minimum, test:

  • urgent requests received overnight, on weekends, and on holidays;
  • requests entered manually after arriving by fax or phone;
  • duplicate requests arriving through two channels;
  • requests transferred between administrative and clinical teams;
  • delegated reviews and requests sent to external partners;
  • partial approvals involving several requested items;
  • extensions allowed by the applicable program; and
  • outages or integration retries that delay record creation.

Do not start the operational clock only when a Salesforce case is assigned. If the source request arrived earlier, that design hides queue time and understates the true elapsed period.

Documentation logic needs equal attention. CMS says the clock does not stop or restart if the payer asks for additional documentation that was not disclosed when the provider submitted the request, although program-specific extensions may be available. Coverage Requirement Discovery and Documentation Templates and Rules should therefore be tested against the payer's live policy catalog. Missing, ambiguous, or outdated documentation rules create both provider friction and preventable timing risk.

Configure Health Cloud around observable outcomes

Salesforce documents Health Cloud Utilization Management capabilities for both payers and providers. The payer model includes care requests, request items, diagnoses, reviewers, processing errors, tracked communications, and related details. The product also supports FHIR-aligned workflows for Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support. Salesforce's Utilization Management overview describes rules, queue routing, SLA tracking, analytics, and MuleSoft-deployed APIs.

Use those capabilities to make the service observable. A payer should be able to answer, without assembling spreadsheets after the fact:

  • Which requests are approaching an SLA threshold?
  • Which intake channel or integration produces the most incomplete records?
  • Which policies generate repeated requests for more information?
  • Which queues, delegates, or request types contribute the most delay?
  • Are denial reasons specific, consistent, and transmitted correctly?
  • Do Salesforce, the API response, the provider view, and the member-service view show the same status?
  • Can every reported metric be traced to request-level evidence?

CMS already requires affected payers to publish specified prior-authorization metrics annually. The September FAQ lists approval and denial percentages, approvals after appeal, extension-related measures, and average and median decision times, among other measures. A trustworthy reporting layer should reuse governed operational events rather than reconstruct those events from inconsistent status fields.

Test the decision, not only the transport

Health Cloud supports configurable review processes, including administrative, nurse, and medical-director stages. Salesforce also documents automatic approval for qualifying requests through a cloned and configured flow. Automation can improve throughput, but it increases the need for explicit boundaries and evidence.

Build a test pack that covers business outcomes as well as FHIR behavior:

  • approval, denial, partial approval, and request-for-information paths;
  • specific denial reasons and their rendering in every consuming channel;
  • authorization end dates or end conditions;
  • incomplete clinical documentation;
  • invalid or unmatched members and providers;
  • out-of-network providers;
  • changed benefits or policy rules;
  • unsupported codes and malformed attachments;
  • human escalation and medical-review requirements;
  • retries, timeouts, duplicates, and replayed messages;
  • consent, attribution, and opt-in or opt-out behavior for the related access APIs; and
  • reconciliation after an interface or downstream system outage.

Run the tests with representative provider and EHR partners. In May 2026, CMS announced an early-adopter initiative involving health systems, EHR developers, networks, and health plans because the remaining barriers include workflow gaps and technical handoffs across organizations. The CMS announcement is a useful reminder that a payer cannot prove the provider experience alone.

Use the next 90 days deliberately

With the 2027 implementation period approaching, a focused readiness program should prioritize continuity and evidence over broad redesign.

Days 1-15: establish scope and truth

  • Approve the payer, product, request, and compliance-date register.
  • Map every intake channel and authoritative timestamp.
  • Inventory Health Cloud, MuleSoft, EHR, policy, document, identity, analytics, and delegated-review dependencies.
  • Compare current public metrics with source-system records to identify data-definition gaps.

Days 16-30: close contract and data gaps

  • Validate CRD, DTR, and PAS payload mappings against actual policy and request data.
  • Confirm specific denial reasons, end conditions, additional-information requests, and item-level outcomes.
  • Define canonical identifiers and duplicate-handling rules.
  • Establish monitoring for processing errors, stale policy data, failed messages, and delayed record creation.

Days 31-60: prove the operating workflow

  • Configure or correct routing, review stages, SLA calculations, escalation, and tracked communications.
  • Test calendar-time behavior across nights, weekends, and permitted extensions.
  • Verify status consistency across API, Health Cloud, provider, member, and service channels.
  • Train utilization-management and member-service teams on exception handling.

Days 61-80: test with external parties

  • Run conformance tests, then end-to-end tests with representative EHR and provider partners.
  • Inject incomplete documentation, invalid identifiers, duplicates, timeouts, and downstream outages.
  • Reconcile every request from inbound payload through final response and reporting event.
  • Capture defects by business impact and assign owners and retest dates.

Days 81-90: rehearse cutover and control

  • Run a production-like readiness exercise with operational leaders.
  • Confirm dashboards, alerts, support ownership, escalation contacts, and evidence retention.
  • Freeze nonessential changes and define emergency release criteria.
  • Obtain technical, operational, security, privacy, and qualified regulatory sign-off.

The leadership question is whether the service works end to end

The wrong readiness question is, “Is the Prior Authorization API turned on?” The better question is, “Can we receive any in-scope request, preserve its true clock, route it correctly, reach a supported decision, communicate a complete response, keep every audience synchronized, and prove what happened?”

Salesforce Health Cloud can provide much of the workflow and data structure needed to answer that question. It does not eliminate the integration, policy, operating-model, or testing work. No platform configuration by itself establishes compliance.

If Health Cloud is part of your prior-authorization architecture, Yuniq's Salesforce services include consulting, custom development, integration, migration, and managed support. Ask Yuniq to scope a focused readiness review across data mapping, integrations, workflow configuration, test coverage, monitoring, and operational handoffs. The useful output is a prioritized remediation plan and verified workflow evidence, alongside review by your legal, compliance, clinical, privacy, and security teams.