[email protected] /+1 (415) 689-8693

Schedule A Demo

Demystifying the Maze: A Deep Dive into the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) for Health Plans

HEALTH CHAIN INSIGHTS

Demystifying the Maze: A Deep Dive into the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) for Health Plans

April 26, 2024 | 10-minute read

CMS Interoperability

The Centers for Medicare & Medicaid Services (CMS) finalized the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) in January 2024. This rule dives deep into the intricacies of interoperability within the healthcare system, aiming to streamline prior authorization processes and enhance health information exchange for various entities, including Medicare Advantage (MA) organizations, Medicaid and Children's Health Insurance Program (CHIP) fee-for-service (FFS) programs, Medicaid managed care plans, CHIP managed care entities, and issuers of Qualified Health Plans (QHPs). Let's dissect the core elements of this rule and the specific implications for Health Plans.

Key Provisions of CMS-0057-F:

1. Enhanced Prior Authorization Transparency

  • Standardized Reasons for Denial (Effective January 1, 2026): This provision mandates impacted payers (as defined by the rule) to provide a specific, standardized reason for denial for prior authorization requests (excluding drugs) regardless of the communication method used (portal, fax, email, mail, phone). This standardized format, outlined in the rule, ensures clarity and consistency in denial communication, empowering providers to understand the rationale behind denials and potentially resubmit requests with the necessary information.
  • Patient Access to Prior Authorization Information (Effective January 1, 2027): This provision expands the scope of the existing HL7® FHIR® Patient Access API. Impacted payers must now include prior authorization request and decision data (excluding drugs) within this API. This allows members to view their prior authorization history directly through approved applications, fostering greater understanding and potentially facilitating communication with providers if further information is needed.

2. Leveraging Existing APIs for Improved Health Information Exchange

  • Building on the Patient Access API: CMS-0057-F capitalizes on the foundation laid by the CMS Interoperability and Patient Access Final Rule (CMS-9115-F). This previous rule mandated the implementation of the Patient Access API, allowing members to access a wider range of their healthcare data. CMS-0057-F expands the data set within this existing API by incorporating prior authorization information, streamlining the implementation process for health plans and adoption by members and providers.
  • Introducing the Provider Access API (Future Implementation): While not yet implemented, CMS-0057-F lays the groundwork for the future Provider Access API. This API aims to empower authorized providers to directly access specific member data from payers through the API. This has the potential to significantly streamline workflows by:
    • Reducing manual data entry and verification: Providers will be able to retrieve essential member data (demographics, allergies, medications, immunizations, procedures) directly from payers, eliminating the need for manual processes and potential human error.
    • Enhancing care coordination: Streamlined access to member data will facilitate improved communication and collaboration between providers, leading to more coordinated care delivery.

Specific API Requirements

Patient Access API

  • Prior Authorization Request Data: This includes detailed information about:
    • Service requested: This could be a specific procedure code or service description.
    • Member demographics: Member name, date of birth, address, etc.
    • Provider information: Provider name, National Provider Identifier (NPI), contact information, etc.
    • Date submitted: The date the prior authorization request was submitted to the payer.
  • Prior Authorization Decision Data: This includes:
    • Approval or denial status: Whether the request was approved or denied.
    • Standardized reason for denial (if applicable): If the request was denied, the payer must provide a specific reason using the standardized format outlined in the rule. This could include reasons like medical necessity criteria not met, lack of supporting documentation, etc.
    • Date of decision: The date the payer issued the decision on the prior authorization request.

Prior Authorization APIs :

  • Coverage Requirements Discovery (CRD): CMS emphasizes CRD as a tool for improving "transparency for all parties of coverage that may impact services rendered". This API allows for "real-time exchange of coverage plan requirements from payers to providers at the time of treatment decisions"
  • Documentation Templates & Rules (DTR): Building on CRD, CMS views DTR as a mechanism for payers to "express their documentation requirements computably" This enables providers to "navigate and quickly specify the needed information in a context-specific way" while minimizing burden
  • Prior Authorization Support (PAS): Regarding PAS, CMS highlights its role in defining "FHIR based services to enable provider, at point of service, to request authorization". This API streamlines the process by incorporating "existing HIPAA Tx standards" for secure data exchange.

USCDI and Interoperability

The rule mentions the United States Core Data Interchange Standards (USCDI) as a potential foundation for the standardized reasons for denial. USCDI is a set of standardized data classes, data elements and their definitions designed to improve the exchange of healthcare data. While not explicitly mandated in the rule, the use of USCDI-aligned standardized reasons for denial could further enhance consistency and clarity in communication between payers, providers and members.

Compliance Timeline:

Health Plans need to be aware of the specific deadlines outlined in the rule to ensure timely compliance:

  • Standardized Reasons for Denial: Effective January 1, 2026, impacted payers must incorporate standardized reasons for denial into their prior authorization communication processes.
  • Patient Access API Expansion: Effective January 1, 2027, impacted payers must update their Patient Access API to include prior authorization request and decision data (excluding drugs).
  • CRD, DTR and PAS APIs: Effective January 1, 2026, impacted payers would need to have systems in place to interact with these APIs by that date.

Actions for Health Plans:

  • Compliance Timeline: Understand and adhere to the compliance deadlines outlined in the rule. Notably, the Patient Access API implementation for prior authorization data is January 1, 2027.
  • Review Existing Systems: Evaluate current prior authorization processes and communication methods to ensure alignment with the standardized reason for denial requirement.
  • Internal Communication: Educate internal teams (utilization management, care management, claims processing) on the new rule's requirements, implications and benefits for their workflows.
  • Provider Communication: Collaborate with providers to ensure they understand the standardized reason for denial format, how to access member prior authorization data through the Patient Access API, and prepare for the potential future adoption of the Provider Access API.

Conclusion

The CMS Interoperability and Prior Authorization Final Rule signifies a significant step forward in the journey towards interoperability in healthcare. By embracing these API-driven solutions, Health Plans can position themselves to not only meet regulatory requirements but also drive benefits across the healthcare ecosystem, such as improved transparency, increased collaboration, streamlined workflows, reduced care costs and ultimately, a more efficient healthcare ecosystem for all stakeholders.

Featured Analyst Insight

HC in the Press

Explore Related Products

centaur api platform

CentaurTM Data Platform

API platform for Payers to facilitate the ingestion of data from multiple EMRs for storage in FHIR server.

Read More
payer_to_payer_data_connectivity

HC Prior Auth

Integrated product suite to streamline prior authorization processes for Payers, Providers and Patients.

Read More
payer_to_payer_data_connectivity

HC RiskRevPro

Beyond retrospection, HC RiskRevPro redefines proactive risk adjustment for accurate assessment of risk factors.

Read More
payer_to_payer_data_connectivity

HC SQL AI

Experience next generation data analysis with HC SQLAI, a powerful tool designed to securely democratize access to data.

Read More
Go to Top