Our Comments on CMS Interoperability Rule CMS-0057-P
March 13, 2023
Chiquita Brooks-LaSure, Administrator
Centers for Medicare & Medicaid Services,
Department of Health and Human Services,
Attention: CMS-0057-P
Mail Stop C4-26-05, 7500 Security Boulevard, Baltimore, MD 21244-1850
RE: Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children’s Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program
Dear Administrator Brooks-LaSure:
Thank you for providing the opportunity to comment on the Centers for Medicare and Medicaid Services (CMS) proposed Interoperability and Prior Authorization rule, issued on December 13, 2022. We are excited about your efforts to advance interoperability, reduce administrative burden, and accelerate consumers’ access to health information.
We are an interoperability software vendor committed to creating a platform that enables payers and providers to comply with the requirements to make available data in FHIR API format as specified by CMS and ONC. We have a rich history working with HL7 and their Accelerators, particularly DaVinci and Gravity projects. Our work history is oriented towards proving out the mutually agreed HL7 implementation guides from the contributing parties that make up these groups.
As a software vendor, HealthLX and our sister services company, TESCHGlobal, have worked in the interoperability space since 2005. We applaud CMS’s rule to promote and encourage patients to get and use a digital copy of their health information, specifically expanding the patient access API to include prior authorization information. This addition especially encourages us as information about prior authorizations is critical for individuals as they navigate their care.
Thank you in advance for CMS’s consideration and review of the following comments. We look forward to working with our clients to help them implement interoperability and enable their patients to access their health information.
Will Tesch
CEO, HealthLX Inc.
—————————
We appreciate the opportunity to provide comments regarding the proposed rule Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children’s Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program.
Background and Summary of Provisions
CMS implemented a critical starting point to transform the healthcare industry by releasing the “CMS Interoperability and Patient Access final rule” in May 2020. It was shown through the subsequent proposed rule in December 2020 that CMS was committed to taking an active approach to leveraging FHIR-based interoperability. This advancement can potentially reduce the burden of all stakeholders, ensure that current and accurate health information is available at the time of need, and empower patients and caregivers to take a more active role within their own healthcare.
CMS is proposing that “the policies included herein would have a longer implementation timeline.” It is believed that “a three-year timeline to recruit and train staff, update or build the APIs, and update operational procedures would be sufficient for these proposals, particularly based on the information we have from some payers and providers regarding similar initiatives already in progress.”
Based on our implementation experience with the “CMS Interoperability and Patient Access final rule” of May 2020, we believe the payer community needs added time to understand their data before the objectives of this proposed rule can be enforced. The reality that bad data doesn’t improve progress but delays or confuses stakeholders, while trite, is the underlying reality. Notwithstanding, this proposed rule creates the momentum to drive the industry to meet the mission of improved patient care. We support the need for extended timelines for the more complicated proposals including the Payer-to-Payer Data Exchange; and the Prior Authorization Requirements, Documentation, and Decision (PARDD) API. These proposals require significant operational and technical implementations by the impacted payers to address longitudinal patient record data governance, address patient opt-in and opt-out decisions, and fully codify and automate their prior authorization processes. The MIPS Promoting Interoperability Performance Category would fall into this classification based on its alignment with the PAARD proposal.
We believe that establishing a pace of advancement is critical to support the much-needed transformation that CMS is driving. Therefore, CMS should consider accelerating the implementation timelines for the enhanced Patient Access API and Provider Access API proposals. For example, we believe CMS should consider a July 1, 2024, or January 1, 2025, implementation date.
The “CMS Interoperability and Patient Access final rule” established the foundation for the Patient Access API, and most impacted payers have implemented the API in support of the mandate. It is acknowledged that some impacted payers may need to revisit these initial implementations based on their understanding of future CMS proposals and directions. However, the foundation is largely in place, and adding the proposed prior authorization data is less of an uplift for internally managed authorizations. Additionally, accelerating the Patient Access and Provider Access APIs would enable impacted payers to implement the opt-in and opt-out systems and processes in anticipation of the Payer-to-Payer Data Exchange requirements; to determine their attribution methods for provider requests; to determine their access approach for out-of-network providers; and to begin the enhanced patient education and engagement around health apps and their health data. The benefits would provide patients with enhanced transparency and care sooner while setting a pace of expected advancement and transformation to a new industry operating model.
The Patient Access Application Programming Interface (API) portion of the rule requires that the API includes information about patients’ prior authorization decisions to help patients better understand their payer’s prior authorization process and its impact on their care.
We support this requirement as this information is already available in many payers’ internal systems. We ask CMS to consider our accelerated timeline proposal as described above.
The Provider Access API proposes that impacted payers provide an API for providers that will include claims, encounters (without cost information), and USCDI version 1 data on demand. We support the direction of establishing a Provider Access API. However, CMS is asking payers to have an opt-out mechanism for patients to not include their data to a provider when requested. This can make the process confusing if the patient has already provided consent to the provider for that data. We suggest that patient opt-out is collected at the provider at the point of treatment to eliminate the confusion surrounding who has access. This would additionally support the identification of out-of-network providers that patients would like to have data access. Impacted payers should then additionally provide summaries of individual provider status for patient review and reclassification.
The 21st Century Cures Act requires creating a Common Agreement for the Trusted Exchange Framework. The current Framework lays out an interoperability network for all stakeholders. Can CMS comment on the adoption of TEFCA vs. the use of direct APIs between payers and providers?
We ask CMS to consider our accelerated timeline proposal as described above.
Payer-to-Payer Data Exchange on FHIR®
We are in support of the direction of establishing a Payer-to-Payer Data Exchange on FHIR.
CMS has required in Interoperability and Patient Access final rule (85 FR 25510) that at a patient’s request, payers exchange patient records to ensure a longitudinal view of a patient’s medical history. However, the method of exchange was not specific. As software vendors who have long been in this interoperability space, we respectfully ask that CMS specify the requirement for the use of FHIR APIs for this use in order to move the industry toward a single uniform standard. Barring that requirement, we suggest that the Payer-to-Payer Data Exchange can also be accomplished via the TEFCA framework using a Quality Health Information Network (QHIN).
We ask for clarification on the implications of a patient opting out of the Payer-to-Payer Data Exchange after previously opting in. The proposal states that “we propose to require impacted payers to have a process for patients to opt in to this data exchange at any time after the start of coverage, or if they have already opted in, to opt out, at any time.” The Data Incorporation and Maintenance section further states, “We propose that information received by an impacted payer through this data exchange must be incorporated into the patient’s record with the new payer. Those data would then be part of the patient’s record maintained by the new payer and should be included as appropriate in the data available through the Patient Access API, Provider Access API and Payer-to-Payer API, if our proposals are finalized as proposed. It further states that, “payers could choose to indicate which data were received from a previous payer so a future receiving payer, provider, or even the patient, would know where to direct questions (such as how to address contradictory or inaccurate information), but would not be required to do so under this proposal.”
If data exchange occurs due to an initial patient opt-in, and the data is “incorporated into the patient’s record with the new payer,” is that now considered the payer’s new patient record? If a patient later opts out, must the payer be prepared to expunge the data from prior payers or to exclude it from the appropriate APIs?
Improving Prior Authorization Processes
We support the direction to improve and automate the prior authorization processes.
CMS is requiring that payers implement APIs to automate the Prior Authorization process; however, no requirements are defined for providers to implement the corresponding automation needed in their electronic health records (EHR). Without corresponding rules requiring automation on the part of the provider, the full value of automation will not be realized.
CMS is asking that payers respond to prior authorization requests within 72 hours for expedited requests and 7 business days for normal requests. We feel that CMS should consider a shorter time frame since automation of these requests should be near real time. For the sake of patients and providers’ ability to render services, a more aggressive timeline is needed and is completely feasible with automated processing. We have direct experience developing HIE integrations that drive rules for prior authorization auto-adjudication and associated workflows within the payer environment.
Furthermore, the timelines articulated only apply to medical prior authorizations. We respectfully ask CMS to accelerate timelines for behavioral health prior authorizations since many patients don’t receive approval or denial of their treatment until the treatment days are nearly over. This puts patients in the difficult position of abruptly curtailing their treatment without appropriate time to transition to a different care setting.
CMS acknowledges the challenges of behavioral health data exchange within the proposal RFI section and we further highlight that, “Other regulatory restrictions, such as 42 CFR part 2, which governs the confidentiality of substance use disorder patient records maintained by certain entities, or more restrictive state laws,135 can also inhibit the exchange of behavioral health information.” In anticipation of behavioral health data inclusion, and to provide patients with data access control within the current proposal, we believe CMS should expand the patient opt-in and opt-out definitions to enable exclusion of data exchange for selective behavioral and substance use disorder data.
Interoperability Standards for APIs
Interoperability efforts are most successful if data and interface standards are aligned. Implementations left to interpretation, or multiple standard version options, create variability that hinders the advancement of the healthcare industry and our ability to better serve our patients. The proposal acknowledges that “evolving standards development has historically outpaced our ability to amend regulations.”
For example, the “standard currently referenced at 45 CFR 170.213 is the USCDI version 1.” It highlights that “in the future, as versions of the USCDI evolve, there may be multiple versions of the standard referenced at 45 CFR 170.213 at one time.” The errata of USCDI version 1 was published in July 2020, and USCDI version 2 (July 2021) and USCDI version 3 (October 2022) are currently available, while USCDI version 4 is in draft review with an anticipated release in July 2023. Each USCDI version contains advancements in the data classes and their respective data elements that could cause additional implementation burdens. This potential for misalignment will only be exacerbated, as acknowledged by CMS, between the final rule date and the January 1, 2026, implementation date.
We propose that CMS define a strategy for aligning with the implementation guides (IGs) and standards to maintain synchronization across the industry. This could be a published list of standards and IGs that are recommended, supported, planned, or sunset for the current period to enable planning by the payers, providers, app vendors, and healthcare IT vendor communities. This could be published routinely, such as every six months, to maintain alignment across the industry.
We understand why CMS no longer requires specific IGs for the APIs; however, CMS can take a stronger stance than mere encouragement for the use of the IGs. CMS should consider asking implementers to explain why the published IGs cannot be used in their implementation. This information will allow for improvements in the IGs to meet future needs. Without a feedback loop, we will run the risk that the lack of a requirement will mean that implementers provide the bare minimum adherence to standards.
In addition to a feedback loop, we support the suggestion by the Carin Alliance industry group calling for “a free, publicly available endpoint directory that allows applications acting on behalf of consumers to easily access endpoint information.” We, too, feel that in order to have interoperability in the industry, the APIs must be easy to locate. Additionally, we agree with Carin Alliance that the registration process is cumbersome and filled with delays. We suggest that payers publish a service level agreement (SLA) expectation with apps looking to connect their endpoints. CMS can help enforce timeliness by adding a reporting requirement around published SLAs.
HealthLX appreciates the opportunity to submit these comments and welcomes any questions.