Ankit Kumar Agarwal
Ankit Kumar agarwal is a Wharton Graduate and working as “Director of IT” with NewWave Telecom and Technologies Inc. Ankit is passionate about bringing impactful changes in people’s life and writes blogs to educate people and promote digital Health.
Background
Patients tend to receive care from multiple providers, leading to fragmented patient health records where various pieces of an individual’s longitudinal record are locked in disparate, siloed data systems. With patient data scattered across these disconnected systems, it can be challenging for providers to get a clear picture of the patient’s care history, and patients may forget or be unable to provide critical information to their provider. CMS is focused on breaking the silo’s and handling the key issues of the Electronic Prior Authorization, Payer-to-Payer Data Exchange and Payer-Provider Data Exchange to reduce the healthcare waste and improve the Healthcare Outcome.
Key Burden Reduction Rule Highlights
The Burden Reduction rule places new requirements on Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children’s Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs) to improve the electronic exchange of healthcare data and streamline processes related to prior authorization, while continuing CMS’ drive toward interoperability in the healthcare market. This rule also adds a new measure for eligible hospitals and critical access hospitals (CAHs) under the Medicare Promoting Interoperability Program and for Merit-based Incentive Payment System (MIPS) eligible clinicians under the Promoting Interoperability performance category of MIPS. These policies taken together would play a key role in reducing overall payer and provider burden and improving patient access to health information.
In this rule, CMS requires that the impacted payers (MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) include information about prior authorizations in the data that are available through the Patient Access API. In addition, it is required that these impacted payers annually report to CMS certain metrics about patient data requests via the Patient Access API.
To improve coordination across the care continuum and movement toward value-based care, the rule requires that the impacted payers implement and maintain a Provider Access API that, consistent with the technical standards finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558), utilize HL7 FHIR version 4.0.1. That API can be used to exchange current patient data from payers to providers, including all data classes and data elements included in a standard adopted at 45 CFR 170.213 (currently USCDI version 1), adjudicated claims and encounter data (not including provider remittances and enrollee cost-sharing information), and the patient’s prior authorization decisions.
The new proposed policy would require impacted payers (Medicaid, MA organizations, Medicaid managed care plans, CHIP managed care entities, CHIP FFS and QHP issuers on the FFEs) to build a Payer-to-Payer API to facilitate the exchange of patient information between payers, both at a patient’s request and at the start of coverage with a new payer. Specifically, that data exchange would include all data classes and data elements included in a standard adopted at 45 CFR 170.213 (currently USCDI version 1), adjudicated claims and encounter data (not including provider remittances and enrollee cost-sharing information), and the patient’s prior authorization decisions.
To streamline the prior authorization process, the rule requires all impacted payers to implement and maintain a FHIR Prior Authorization Requirements, Documentation, and Decision API (PARDD API). The API would streamline the prior authorization process by automating the process to determine whether a prior authorization is required for an item or service, thereby eliminating one of the major pain points of the existing prior authorization process. The API would then be able to query the payer’s prior authorization documentation requirements and make those requirements available within the provider’s workflow as well as support the automated compilation of certain information from the provider’s system. Finally, the API would support an automated approach to compiling the necessary data elements to populate the HIPAA-compliant prior authorization transactions and enable payers to compile specific responses regarding the status of the prior authorization, including information about the reason for a denial. For the exchange of the prior authorization transaction, covered entities would continue to use the HIPAA-mandated transaction standards. Use of the FHIR API integrates identification of prior authorization and documentation requirements as well as information about prior authorization requests and decisions into a provider’s workflow while maintaining compliance with the adopted HIPAA standard.
The rule requires that the impacted payers send information to providers regarding the specific reason for denial when a prior authorization request is denied, regardless of the mechanism used to submit the prior authorization request. It is required that the impacted payers, except for QHP issuers or the FFEs, respond to prior authorization requests within certain timeframes. In addition, the impacted payers should publicly report certain metrics about their prior authorization processes for transparency.
Implementation Timeline
The rule requires that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers would be required to make information available to patients via the Patient Access API about prior authorization requests and decisions (and related administrative and clinical documentations), including, as applicable, the status of the prior authorization; the date the prior authorization was approved or denied; the date or circumstance under which the authorization ends; the items and services approved; the quantity used to date; and, if the prior authorization was denied, a specific reason why the request was denied, no later than 1 business day after the payer receives a prior authorization request for items and services (excluding drugs) or there is another type of status change for the prior authorization. Beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers must make prior authorization information (and related administrative and clinical documentation), available to patients via the Patient Access API for the duration it is active and at least 1 year after the last status change. These proposals would apply to MA organizations, state Medicaid FFS and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.
Guidance to the Payers
In order to meet the January 1, 2026 timeline, the payers would have to implement the key functionality by December 31, 2024 in order to meet certain CMS Reporting Requirements for the Fiscal year 2025. CMS expects that the Electronic Prior Authorization Implementation duration for the majority of the plans could be between 18 months to 24 months.
Similarly, it is going to be time consuming effort to implement Payer-to-Payer and Provider-to-Payer Data Exchange. It is recommended that all of the plans start the planning exercise in Q1 2023 with a plan to start the design phase towards Mid of 2023 in order to meet the CMS mandated timelines.
*This article is Peer Reviewed by the Distilinfo Editorial team prior to the publication.*
