Animal and Plant Health Inspection Service
Forest Service
Foreign-Trade Zones Board
International Trade Administration
National Oceanic and Atmospheric Administration
National Telecommunications and Information Administration
Navy Department
Federal Energy Regulatory Commission
Agency for Toxic Substances and Disease Registry
Centers for Disease Control and Prevention
Centers for Medicare & Medicaid Services
Children and Families Administration
Food and Drug Administration
Health Resources and Services Administration
National Institutes of Health
Coast Guard
Federal Emergency Management Agency
Fish and Wildlife Service
Land Management Bureau
National Park Service
Reclamation Bureau
Alcohol, Tobacco, Firearms, and Explosives Bureau
Copyright Royalty Board
Federal Aviation Administration
National Highway Traffic Safety Administration
Internal Revenue Service
Consult the Reader Aids section at the end of this issue for phone numbers, online resources, finding aids, and notice of recently enacted public laws.
To subscribe to the Federal Register Table of Contents electronic mailing list, go to https://public.govdelivery.com/accounts/USGPOOFR/subscriber/new, enter your e-mail address, then follow the instructions to join, leave, or manage your subscription.
Office of Personnel Management.
Final rule; correction.
This document corrects the preamble to a final rule published in the
This correction is effective on December 13, 2022.
Joe Ratcliffe by email at
In the
Federal Aviation Administration (FAA), Department of Transportation (DOT).
Final rule; correction.
The FAA is correcting a final rule that appeared in the
Effective 0901 UTC, February 23, 2023. The Director of the Federal Register approves this incorporation by reference under 1 CFR part 51, subject to the annual revision of FAA Order JO 7400.11,
Nathan A. Chaffman, Federal Aviation Administration, Western Service Center, Operations Support Group, 2200 S 216th Street, Des Moines, WA 98198; telephone (206) 231-3460.
The FAA published a final rule in the
Class D, Class E2, Class E4, and Class E5 airspace designations are published in paragraphs 5000, 6002, 6004, and 6005, respectively, of FAA Order JO 7400.11G, dated August 19, 2022, and effective September 15, 2022, which is incorporated by reference in 14 CFR 71.1. The Class E airspace designation listed in this document will be published subsequently in FAA Order JO 7400.11.
FAA Order JO 7400.11 is published annually and becomes effective on September 15.
Accordingly, pursuant to the authority delegated to the FAA, “Modification of Class D Airspace and Class E Airspace; Bozeman Yellowstone International Airport, MT”, published in the
Coast Guard, DHS.
Temporary final rule.
The Coast Guard is establishing a temporary safety zone for certain navigable waters within the Detroit River, Detroit, MI. The safety zone is needed to protect personnel, vessels, and the marine environment from potential hazards during a fireworks event. Entry of vessels or persons into this zone is prohibited unless specifically authorized by the Captain of the Port Detroit.
This rule is effective from 11:59 p.m. on December 31, 2022, through 12:15 a.m. on January 1, 2023.
To view documents mentioned in this preamble as being available in the docket, go to
If you have questions on this rule, call or email Ms. Tracy Girard, U.S. Coast Guard; (313) 475-7475,
The Coast Guard is issuing this temporary rule without prior notice and opportunity to comment pursuant to authority under section 4(a) of the Administrative Procedure Act (APA) (5 U.S.C. 553(b)). This provision authorizes an agency to issue a rule without prior notice and opportunity to comment when the agency for good cause finds that those procedures are “impracticable, unnecessary, or contrary to the public interest.” Under 5 U.S.C. 553(b)(B), the Coast Guard finds that good cause exists for not publishing a notice of proposed rulemaking (NPRM) with respect to this rule because doing so is impracticable. The Coast Guard did not receive notice of the fireworks with sufficient time to undergo notice and comment. We must establish this safety zone by December 31, 2022 in order to protect the public form the hazards associated with a fireworks event.
Under 5 U.S.C. 553(d)(3), the Coast Guard finds that good cause exists for making this rule effective less than 30 days after publication in the
The Coast Guard is issuing this rule under authority in 46 U.S.C. 70034 (previously 33 U.S.C. 1231). The Captain of the Port Detroit (COTP) has determined that potential hazards associated with fireworks starting December 31, 2022, will be a safety concern for anyone within a 250-yard radius of the fireworks location. This rule is needed to protect personnel, vessels, and the marine environment in the navigable waters within the safety zone while fireworks show is being displayed.
This rule establishes a safety zone from 11:59 p.m. on December 31, 2022 through 12:15 a.m. on January 1, 2023. The safety zone will cover all navigable waters within a 250 yard radius of location 42°19.66′ N 083°02.34′ W (WGS 84) in the Detroit River, Detroit, MI. The duration of the zone is intended to protect personnel, vessels, and the marine environment in these navigable waters while the fireworks show is being displayed. No vessel or person will be permitted to enter the safety zone without obtaining permission from the COTP or a designated representative.
We developed this rule after considering numerous statutes and Executive orders related to rulemaking. Below we summarize our analyses based on a number of these statutes and Executive orders, and we discuss First Amendment rights of protestors.
Executive Orders 12866 and 13563 direct agencies to assess the costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits. This rule has not been designated a “significant regulatory action,” under Executive Order 12866. Accordingly, this rule has not been reviewed by the Office of Management and Budget (OMB).
This regulatory action determination is based on the size, location, duration, and time-of-day of the safety zone. Vessel traffic will be able to safely transit around this safety zone which will impact a small designated area of the Detroit River for less than an hour during the night when vessel traffic is normally low. Moreover, the Coast Guard would issue a Broadcast Notice to Mariners via VHF-FM marine channel 16 about the zone, and the rule would allow vessels to seek permission to enter the zone.
The Regulatory Flexibility Act of 1980, 5 U.S.C. 601-612, as amended, requires Federal agencies to consider the potential impact of regulations on small entities during rulemaking. The term “small entities” comprises small businesses, not-for-profit organizations that are independently owned and operated and are not dominant in their fields, and governmental jurisdictions with populations of less than 50,000. The Coast Guard certifies under 5 U.S.C. 605(b) that this rule will not have a significant economic impact on a substantial number of small entities.
While some owners or operators of vessels intending to transit the safety zone may be small entities, for the reasons stated in section V.A above, this rule will not have a significant economic impact on any vessel owner or operator.
Under section 213(a) of the Small Business Regulatory Enforcement Fairness Act of 1996 (Pub. L. 104-121), we want to assist small entities in understanding this rule. If the rule would affect your small business, organization, or governmental jurisdiction and you have questions concerning its provisions or options for compliance, please call or email the person listed in the
Small businesses may send comments on the actions of Federal employees who enforce, or otherwise determine compliance with, Federal regulations to the Small Business and Agriculture Regulatory Enforcement Ombudsman and the Regional Small Business Regulatory Fairness Boards. The Ombudsman evaluates these actions annually and rates each agency's responsiveness to small business. If you wish to comment on actions by employees of the Coast Guard, call 1-888-REG-FAIR (1-888-734-3247). The Coast Guard will not retaliate against small entities that question or complain about this rule or any policy or action of the Coast Guard.
This rule will not call for a new collection of information under the Paperwork Reduction Act of 1995 (44 U.S.C. 3501-3520).
A rule has implications for federalism under Executive Order 13132, Federalism, if it has a substantial direct effect on the States, on the relationship between the National Government and the States, or on the distribution of power and responsibilities among the various levels of government. We have analyzed this rule under that Order and have determined that it is consistent with the fundamental federalism principles and preemption requirements described in Executive Order 13132.
Also, this rule does not have tribal implications under Executive Order 13175, Consultation and Coordination with Indian Tribal Governments, because it does not have a substantial direct effect on one or more Indian tribes, on the relationship between the Federal Government and Indian tribes, or on the distribution of power and responsibilities between the Federal Government and Indian tribes.
The Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1531-1538) requires Federal agencies to assess the effects of their discretionary regulatory actions. In particular, the Act addresses actions that may result in the expenditure by a State, local, or tribal government, in the aggregate, or by the private sector of $100,000,000 (adjusted for inflation) or more in any one year. Though this rule will not result in such an expenditure, we do discuss the effects of this rule elsewhere in this preamble.
We have analyzed this rule under Department of Homeland Security Directive 023-01, Rev. 1, associated implementing instructions, and Environmental Planning COMDTINST 5090.1 (series), which guide the Coast Guard in complying with the National Environmental Policy Act of 1969 (42 U.S.C. 4321-4370f), and have determined that this action is one of a category of actions that do not individually or cumulatively have a significant effect on the human environment. This rule involves a safety zone lasting less then an hour that will prohibit entry within 250 yard radius of 42°19.66′ N 083°02.34′ W (WGS 84). It is categorically excluded from further review under paragraph L[60] of Appendix A, Table 1 of DHS Instruction Manual 023-01-001-01, Rev. 1. A Record of Environmental Consideration supporting this determination is available in the docket. For instructions on locating the docket, see the
The Coast Guard respects the First Amendment rights of protesters. Protesters are asked to call or email the person listed in the
Harbors, Marine safety, Navigation (water), Reporting and record keeping requirements, Security measures, Waterways.
For the reasons discussed in the preamble, the Coast Guard amends 33 CFR part 165 as follows:
46 U.S.C. 70034, 70051; 33 CFR 1.05-1, 6.04-1, 6.04-6, and 160.5; Department of Homeland Security Delegation No. 00170.1, Revision No. 01.3.
(a)
(b)
(c)
(2) The safety zones are closed to all vessel traffic, except as may be permitted by the COTP Detroit or a designated on-scene representative.
(3) The “on-scene representative” of the COTP Detroit is any Coast Guard commissioned, warrant or petty officer or a federal, state, or local law enforcement officer designated by the COTP Detroit to act on his behalf.
(4) Vessel operators desiring to enter or operate within the safety zones must contact the COTP Detroit or an on-scene representative to obtain permission to do so. The COTP Detroit or an on-scene representative may be contacted via VHF Channel 16. Vessel operators given permission to enter or operate in the safety zone must comply with all directions given to them by the COTP Detroit or an on-scene representative.
Environmental Protection Agency (EPA).
Interim final determination.
The Environmental Protection Agency (EPA) is making an interim final determination that the California Air Resources Board has submitted a revised rule on behalf of the Yolo-Solano Air Quality Management District (YSAQMD) that corrects a deficiency in its Clean Air Act (CAA or Act) State implementation plan (SIP) provisions concerning reasonably available control technology (RACT) ozone nonattainment requirements for controlling emissions of volatile organic compounds (VOC) from solvent cleaning and degreasing operations. This determination is based on a proposed approval, published elsewhere in this issue of the
This interim final determination is effective on December 13, 2022. However, comments must be received on or before January 12, 2023.
Submit your comments, identified by Docket ID No. EPA-R09-OAR-2022-0795 at
Arnold Lazarus, EPA Region IX, 75 Hawthorne St., San Francisco, CA 94105. By phone: (415) 972-3024 or by email at
Throughout this document, “we,” “us,” and “our” refer to the EPA.
On July 30, 2021 (86 FR 40959), the EPA issued a rule promulgating a limited approval and limited disapproval for the YSAQMD rule listed in Table 1 that was submitted by the California Air Resources Board (CARB) to the EPA for inclusion into the California SIP.
Areas classified as Moderate nonattainment for an ozone standard must implement reasonably available control technology (RACT) for each category of sources covered by a Control Techniques Guidelines (CTG) document as well as each major source of VOCs in ozone nonattainment areas classified as Moderate or above (see CAA section 182(b)(2)). The YSAQMD area is classified as Severe nonattainment for the 2008 ozone national ambient air quality standard (NAAQS) and Moderate nonattainment for the 2015 ozone NAAQS.
In the 2021 final rule, we determined that the submitted YSAQMD rule included a deficiency that precluded our full approval of the rule into the SIP. YSAQMD's previously submitted Rule 2.31 exempted solvent degreasing operations subject to the National Emission Standards for Hazardous Air Pollutants (NESHAP) requirements of 40 CFR part 63 Subpart T—National Emission Standards for Halogenated Solvent Cleaning from the control requirements under the rule, which we found did not satisfy SIP requirements under CAA section 182(b)(2) because the RACT requirements for sources subject to the NESHAP requirements of 40 CFR Subpart T are not included in the SIP. Pursuant to section 179 of the CAA and our regulations at 40 CFR 52.31, the disapproval action on Rule 2.31 under title I, part D started a sanctions clock for imposition of offset sanctions 18 months after the action's effective date of August 30, 2021, and highway sanctions 6 months later.
On July 14, 2021, the YSAQMD revised Rule 2.31, and on July 18, 2022, CARB submitted the SIP revision to the EPA for approval into the California SIP as shown in Table 2 below.
On September 30, 2022, the submittal for YSAQMD Rule 2.31 was determined to meet the completeness criteria in 40 CFR part 51 Appendix V, which must be met before formal EPA review.
The revised YSAQMD Rule 2.31 in Table 2 is intended to address the disapproval issues in our 2021 final rule. In the Proposed Rules section of this
The EPA is providing the public with an opportunity to comment on this deferral of sanctions. If comments are submitted that change our assessment described in this interim final determination and the proposed full approval of YSAQMD Rule 2.31, we would take final action to lift this deferral of sanctions under 40 CFR 52.31. If no comments are submitted that change our assessment, then all sanctions and any sanction clocks triggered by our 2021 final action would be permanently terminated on the effective date of our final approval of Rule 2.31.
We are making an interim final determination to defer the imposition of sanctions under CAA section 179 associated with our disapproval action on July 30, 2021, of YSAQMD's Rule 2.31 with respect to the requirements of part D of title I of the CAA. This determination is based on our concurrent proposed approval of Rule 2.31 which resolves the deficiency that triggered sanctions under section 179 of the CAA.
Because the EPA has preliminarily determined that YSAQMD's Rule 2.31 addresses the limited disapproval issue under part D of title I of the CAA identified in our 2021 final action and the rule is now fully approvable, relief
The EPA believes that notice-and-comment rulemaking before the effective date of this action is impracticable and contrary to the public interest. The EPA has reviewed the State's submittal and, through its proposed action, is indicating that it is more likely than not that the State has submitted a revision to the SIP that corrects deficiencies under part D of the Act that were the basis for the action that started the sanctions clocks. Therefore, it is not in the public interest to impose sanctions. The EPA believes that it is necessary to use the interim final rulemaking process to defer sanctions while the EPA completes its rulemaking process on the approvability of the State's submittal. Moreover, with respect to the effective date of this action, the EPA is invoking the good cause exception to the 30-day notice requirement of the Administrative Procedures Act because the purpose of this notice is to relieve a restriction (5 U.S.C. 553(d)(1)).
This action defers sanctions and imposes no additional requirements. For that reason, this action:
• Is not a “significant regulatory action” subject to review by the Office of Management and Budget under Executive Orders 12866 (58 FR 51735, October 4, 1993) and 13563 (76 FR 3821, January 21, 2011);
• Does not impose an information collection burden under the provisions of the Paperwork Reduction Act (44 U.S.C. 3501
• Is certified as not having a significant economic impact on a substantial number of small entities under the Regulatory Flexibility Act (5 U.S.C. 601
• Does not contain any unfunded mandate or significantly or uniquely affect small governments, as described in the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4);
• Does not have federalism implications as specified in Executive Order 13132 (64 FR 43255, August 10, 1999);
• Is not an economically significant regulatory action based on health or safety risks subject to Executive Order 13045 (62 FR 19885, April 23, 1997);
• Is not a significant regulatory action subject to Executive Order 13211 (66 FR 28355, May 22, 2001);
• Is not subject to requirements of Section 12(d) of the National Technology Transfer and Advancement Act of 1995 (15 U.S.C. 272 note) because application of those requirements would be inconsistent with the Clean Air Act; and
• The State did not evaluate environmental justice considerations as part of its SIP submittal. There is no information in the record inconsistent with the stated goals of E.O 12898 of achieving environmental justice for people of color, low-income populations, and indigenous peoples.
• Is not approved to apply on any Indian reservation land or in any other area where the EPA or an Indian tribe has demonstrated that a tribe has jurisdiction. In those areas of Indian country, the rule does not have tribal implications and will not impose substantial direct costs on tribal governments or preempt tribal law as specified by Executive Order 13175 (65 FR 67249, November 9, 2000).
• Is subject to the Congressional Review Act (CRA), 5 U.S.C. 801
Under section 307(b)(1) of the CAA, petitions for judicial review of this action must be filed in the United States Court of Appeals for the appropriate circuit by February 13, 2023. Filing a petition for reconsideration by the EPA Administrator of this final rule does not affect the finality of this rule for the purpose of judicial review nor does it extend the time within which petition for judicial review may be filed, and shall not postpone the effectiveness of such rule or action. This action may not be challenged later in proceedings to enforce its requirements (see CAA section 307(b)(2)).
Environmental protection, Air pollution control, Carbon monoxide, Incorporation by reference, Intergovernmental relations, Nitrogen oxides, Ozone, Particulate matter, Reporting and recordkeeping requirements.
42 U.S.C. 7401
Centers for Medicare & Medicaid Services (CMS), Department of Health and Human Services (HHS).
Final rule; correction.
This document corrects typographical errors in the final rule that appeared in the August 10, 2022,
Donald Thompson, and Michele Hudson, (410) 786-4487 or
In the final rule which appeared in the August 10, 2022,
In FR Doc. 2022-24077 of November 4, 2022 (87 FR 66558), there was an inadvertent omission that is identified and corrected in this correcting document. This document also corrects computational errors in FR Doc. 2022-48780 of August 10, 2022 (87 FR 48780). The corrections in this correcting document are applicable to discharges occurring on or after October 1, 2022, as if they had been included in the document that appeared in the August 10, 2022
On page 49075, in an untitled table regarding direct graduate medical education (DGME) Medicare advantage (MA) payments, we inadvertently made computational errors in the CY 2020 and CY 2021 figures for “Percent Reduction to MA DGME Payments.”
On page 66563 of the FY 2023 IPPS/LTCH PPS correcting amendment, we inadvertently omitted a correction to the outlier fixed-loss cost threshold for FY 2023 on page 49428 of the FY 2023 IPPS/LTCH PPS final rule, to reflect our recalculation of the outlier fixed-loss cost threshold.
Under 5 U.S.C. 553(b) of the Administrative Procedure Act (APA), the agency is required to publish a notice of the proposed rulemaking in the
We believe that this final rule correction does not constitute a rule that would be subject to the notice and comment or delayed effective date requirements. This document corrects typographical errors in the FY 2023 IPPS/LTCH PPS final rule and the FY 2023 IPPS/LTCH PPS final rule correcting amendment, but does not make substantive changes to the policies or payment methodologies that were adopted in the final rule. As a result, this final rule correction is intended to ensure that the information in the FY 2023 IPPS/LTCH PPS final rule accurately reflects the policies adopted in that document.
In addition, even if this were a rule to which the notice and comment procedures and delayed effective date requirements applied, we find that there is good cause to waive such requirements. Undertaking further notice and comment procedures to incorporate the corrections in this document into the final rule or delaying the effective date would be contrary to the public interest because it is in the public's interest for providers to receive appropriate payments in as timely a manner as possible, and to ensure that the FY 2023 IPPS/LTCH PPS final rule accurately reflects our policies. Furthermore, such procedures would be unnecessary, as we are not altering our payment methodologies or policies, but rather, we are simply implementing correctly the methodologies and policies that we previously proposed, requested comment on, and subsequently finalized. This final rule correction is intended solely to ensure that the FY 2023 IPPS/LTCH PPS final rule accurately reflects these payment methodologies and policies. Therefore, we believe we have good cause to waive the notice and comment and effective date requirements. Moreover, even if these corrections were considered to be retroactive rulemaking, they would be authorized under section 1871(e)(1)(A)(ii) of the Act, which permits the Secretary to issue a rule for the Medicare program with retroactive effect if the failure to do so would be contrary to the public interest. As we have explained previously, we believe it would be contrary to the public interest not to implement the corrections in this final rule correction for discharges occurring on or after October 1, 2022, because it is in the public's interest for providers to receive appropriate payments in as timely a manner as possible, and to ensure that the FY 2023 IPPS/LTCH PPS final rule accurately reflects our policies.
In FR Doc. 2022-16472 of August 10, 2022 (87 FR 48780), we are making the following corrections:
1. On page 49075, in the untitled table, line 8 (“Percent Reduction to MA DGME Payments”),
a. Second column (CY 2020), the figure “3.71%” is corrected to read “3.73%”.
b. Fourth column (CY 2021), the figure “3.22% ” is corrected to read “3.26%”.
In FR Doc. 2022-24077 of November 4, 2022 (87 FR 66558), we are making the following correction:
3. On page 66563, second column, after the 14th full paragraph (item (2)(b)) the text is corrected by adding a paragraph (item (2)(c)) to read as follows:
“(c) Second full paragraph, line 9, the figure “$38,859” is corrected to read “$38,788”.”
Office of Acquisition Policy, General Services Administration (GSA).
Final rule.
The General Services Administration (GSA) is issuing a final rule amending the General Services Administration Acquisition Regulation (GSAR) to make technical amendments to GSAR clause 552.212-4 regarding commercial items and its prescribing section. This GSAR clause is a deviation to FAR clause 52.212-4. These technical amendments update obsolete references, correct typographical errors, and make minor editorial changes to improve clarity of GSA's deviation to FAR clause 52.212-4.
Effective January 12, 2023.
Mr. Nicholas Giles and Mrs. Johnnie McDowell, Procurement Analyst, at 202-718-6112, for clarification of content. For information pertaining to status or publication schedules, contact the Regulatory Secretariat Division at 202-501-4755 or
GSA is amending the GSAR to make several minor technical amendments to 552.212-4 and its prescribing section to improve clarity of GSA's Deviation to the equivalent FAR Commercial Items Clause. These technical amendments will assist contracting offices and contractors with understanding applicability of GSA's deviation to their specific commercial procurement actions.
Title 40 of the United States Code (U.S.C.) Section 121 authorizes GSA to issue regulations, including the GSAR, to control the relationship between GSA and contractors.
The final rule makes general wording and cross-reference changes to GSAR clause 552.212-4 and other related sections. For example, the final rule corrects the prescribing section cross-referenced in the introductory text of GSAR clause 552.212-4 from “512.301(e)”, which is now obsolete, to “512.301(b)”, which is current. In addition, the prescribed use of GSAR clause 552.212-4 is not limited to a defined circumstance. Therefore, the final rule removes the term “Alternate II” and any associated language from GSAR clause 552.212-4 to clarify the clause is a “Deviation” as defined and used by FAR 1.401 and GSAR 501.4, and not an “Alternate” as defined by FAR 2.101. Other technical amendments include minor grammatical corrections and minor editorial changes to clarify the applicability of GSA's Deviation to FAR clause 52.212-4.
Executive Orders (E.O.s) 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). E.O. 13563 emphasizes the importance of quantifying both costs and benefits, of reducing costs, of harmonizing rules, and of promoting flexibility. This rule is not a significant regulatory action and, therefore, is not subject to review under section 6(b) of E.O. 12866, Regulatory Planning and Review, dated September 30, 1993.
The Congressional Review Act, 5 U.S.C. 801
The statute that applies to the publication of the GSAR is the Office of Federal Procurement Policy statute (codified at title 41 of the United States Code). Specifically, 41 U.S.C. 1707(a)(1) requires that a procurement policy, regulation, procedure or form (including an amendment or modification thereof) must be published for public comment if it relates to the expenditure of appropriated funds and has either a significant effect beyond the internal operating procedures of the agency issuing the policy, regulation, procedure, or form, or has a significant cost or administrative impact on contractors or offerors. This rule is not required to be published for public comment, because GSA is not issuing a new regulation; rather, this rule merely makes minor editorial changes to improve clarity and corrects typographical errors and outdated cross-references in the GSAR. The rule does not expand or shrink the universe of products or services that the Government may procure using GSAR part 552, nor does it change the terms and conditions vendors must comply with. This rule does not add any new solicitation provisions or contract clauses nor does it add any new burdens because the case does not add or change any requirements with which vendors must comply.
The Regulatory Flexibility Act (5 U.S.C. 601
The final rule does not contain any information collection requirements that require the approval of the Office of Management and Budget under the
Government procurement.
Therefore, GSA amends 48 CFR parts 512 and 552 as set forth below:
40 U.S.C. 121(c).
The revisions read as follows:
Fish and Wildlife Service, Interior.
Final rule.
We, the U.S. Fish and Wildlife Service (Service or USFWS), determine endangered status under the Endangered Species Act of 1973 (Act), as amended, for the Dolphin and Union caribou (
The rule is effective January 12, 2023.
This final rule is available on the internet at
Rachel London, Acting Chief, Branch of Delisting and Foreign Species, Ecological Services Program, U.S. Fish and Wildlife Service, 5275 Leesburg Pike, MS: ES, Falls Church, VA 22041; telephone 703-358-2491. Individuals in the United States who are deaf, deafblind, hard of hearing, or have a speech disability may dial 711 (TTY, TDD, or TeleBraille) to access telecommunications relay services. Individuals outside the United States should use the relay services offered within their country to make international calls to the point-of-contact in the United States.
On August 31, 2021, we proposed to list the Dolphin and Union caribou as a threatened species under the Act (86 FR 48619) with a rule issued under section 4(d) of the Act. Please refer to the August 31, 2021, proposed rule for a detailed description of previous Federal actions concerning Dolphin and Union caribou that occurred prior to August 31, 2021.
In preparing this final rule, we reviewed and fully considered comments from the public on the proposed rule. During the public comment period, we received new survey information that reveal that the Dolphin and Union caribou experienced a catastrophic decline during the years 2015 to 2018 in which the herd lost 75 percent of its 2015 population (from 18,000 individuals down to 4,000 individuals) in a 4-year timespan. While this decline seems to have somewhat stabilized in the 2020 survey (3,800 individuals), this survey data means that since 1997 the Dolphin and Union caribou herd has now declined from approximately 34,000 individuals to approximately 3,800 individuals. This rapid decline is due to a combination of factors described in both the proposed rule and this final rule. These factors include a decline in foraging quality due to climate change, changes in sea-ice level, an increase in shipping traffic, and parasites. Some population decline due to hunting may also be a contributing factor. For these reasons, we are finalizing the listing of the Dolphin and Union caribou in 50 CFR 17.11(h) as an endangered species under the Act. We have also revised the proposed listing entry by adding specific geographic information about the straits that the Dolphin and Union caribou use when migrating between Victoria Island the mainland; however, this revision to the “Where listed” column is not the result of new information.
Finalizing the listing of the Dolphin and Union caribou as endangered means that the proposed rule under section 4(d) of the Act will not be finalized or put in place, including the proposed trophy import exemption from the prohibition that was provided in the proposed rule. Rather, the prohibitions under section 9(a)(1) of the Act and our implementing regulations for endangered wildlife will apply to all Dolphin and Union caribou specimens. Therefore, for example, when this final rule is effective (see
A thorough review of the taxonomy, life history, and ecology of the Dolphin and Union caribou is presented in the species report and the proposed rule (86 FR 48619; Service 2021, pp. 4-10; available at
The Dolphin and Union caribou is found on Victoria Island and the Canadian mainland, encompassing the Canadian provinces of Nunavut and the Northwest Territories (NWT). The caribou is a migratory species with a calving period occurring during the summer months on Victoria Island. The herd then crosses the sea ice of the Coronation Gulf, Dolphin and Union Strait, and Dease Strait to their wintering grounds on the mainland. The primary driver of the Dolphin and Union caribou status is climate change and its effect on the formation and breaking up of sea ice between Victoria Island and the mainland. As of 2020, the herd population was estimated to be 3,815 individuals (Campbell et al. 2021, p. 70). This number represents a decline of approximately 90 percent from the population peak of 34,558 individuals in 1997. After 1997, the population steadily declined to 27,787 individuals in 2007 and 18,413 individuals in 2015. In 2018, the population was 4,105, a decline of over 78 percent from the 2015 population. Possible reasons for this decline are the cumulative effects of known stressors such as the effects of climate change, disease, and parasites (discussed in greater detail below in the Summary of Biological Status and Threats (Campbell et al. 2021, p. 15)). The survey conducted in 2020 confirmed that the 2015-2018 decline did occur, with an estimated size at that time of 3,800 caribou.
Under section 3(16) of the Act, we may consider for listing any species, including subspecies, of fish, wildlife, or plants, or any DPS of vertebrate fish or wildlife that interbreeds when mature (16 U.S.C. 1532(16)). Those entities are considered eligible for listing under the Act (and, therefore, are referred to as listable entities), should we determine that they meet the definition of an endangered or threatened species.
Under the Service's DPS Policy (61 FR 4722, February 7, 1996), three elements are considered in the decision concerning the determination and classification of a possible DPS as threatened or endangered. These elements include are:
(1) The discreteness of a population in relation to the remainder of the species to which it belongs;
(2) The significance of the population segment to the species to which it belongs; and
(3) The population segment's conservation status in relation to the Act's standards for listing, delisting, or reclassification (
A population segment of a vertebrate taxon may be considered discrete under the DPS policy if it satisfies either one of the following conditions:
(1) It is markedly separated from other populations of the same taxon as a consequence of physical, physiological, ecological, or behavioral factors. Quantitative measures of genetic or morphological discontinuity may provide evidence of this separation.
(2) It is delimited by international governmental boundaries within which differences in control of exploitation, management of habitat, conservation status, or regulatory mechanisms exist that are significant in light of section 4(a)(1)(D) of the Act.
If a population segment is considered discrete under one or more of the conditions described in the Service's DPS policy, its biological and ecological significance will be considered in light of congressional guidance that the authority to list DPSs be used “sparingly” (see Senate Report 151, 96th Congress, 1st Session). In making this determination, we consider available scientific evidence of the DPS's importance to the taxon to which it belongs. Since precise circumstances are likely to vary considerably from case to case, the DPS policy does not describe all the classes of information that might be used in determining the biological and ecological importance of a discrete population. However, the DPS policy describes four possible classes of information that provide evidence of a population segment's biological and ecological importance to the taxon to which it belongs. As specified in the
(1) Persistence of the DPS in an ecological setting unusual or unique to the taxon;
(2) Evidence that loss of the DPS would result in a significant gap in the range of a taxon;
(3) Evidence that the DPS represents the only surviving natural occurrence of a taxon that may be more abundant elsewhere as an introduced population outside its historical range; or
(4) Evidence that the DPS differs markedly from other populations of the species in its genetic characteristics.
To be considered significant, a population segment needs to satisfy only one of these criteria, or other classes of information that might bear on the biological and ecological importance of a discrete population segment, as described in the DPS policy. Below, we summarize discreteness and significance for the Dolphin and Union caribou.
Please refer to the proposed rule for a more in-depth evaluation of the Dolphin and Union status as a DPS of the barren-ground caribou (
The Dolphin and Union caribou is markedly separate from other populations of the barren-ground caribou (
Morphological and genetic discontinuities between Dolphin and Union caribou and other subpopulations of the barren-ground caribou provide further evidence of this separation. Morphologically, the Dolphin and Union caribou are smaller and lighter in color than the mainland barren-ground caribou (McFarlane et al. 2009, p. 125). Genetically, the Dolphin and Union caribou is more closely related to the mainland barren-ground caribou than other island caribou with which it shares Victoria Island (McFarlane et al. 2009, p. 125). Despite being more closely related to mainland subpopulations, the Dolphin and Union caribou also maintains genetic distinctness from them (McFarlane et al. 2016, pp. 8, 14; McFarlane et al. 2009, p. 125, Zittlau 2004, p. 113). Phylogenetic analyses conducted on mitochondrial DNA reveals that, during the caribou recolonization of the Arctic at the end of the last Ice Age, the Dolphin and Union caribou diverged from the other barren-ground caribou subpopulations approximately 3,000 years ago (McFarlane et al. 2016, pp. 15-16).
In summary, we determine that the Dolphin and Union caribou is markedly separated from neighboring caribou subpopulations. At different times of the year, the Dolphin and Union caribou is physically (geographically) and reproductively isolated from the mainland subpopulations. The Dolphin and Union caribou also exhibit unique migratory behavior, and genetic data supports the separation of the subpopulation from the barren-ground caribou. Therefore, we consider the Dolphin and Union caribou subpopulation to be discrete under our DPS policy.
We found that the Dolphin and Union caribou is significant to the
The barren-ground caribou contains three genetic variants: the mainland subpopulations, the Southampton Island subpopulations, and the Dolphin and Union caribou subpopulations. A study of allelic frequency shows that each subpopulation forms a unique cluster (McFarlane et al. 2016, p. 9), with the Dolphin and Union caribou being closer genetically to the mainland subpopulations than the Southampton subpopulation. This conclusion is further supported by a comparison of the fixation index (F
In addition to their allelic differences, a study of the gene flow of the Dolphin and Union caribou supports the genetic distinctness of the subpopulation. Gene flow of the Dolphin and Union caribou appears to flow in a southward direction. That is, there is an outward flow of the Dolphin and Union caribou gene into the neighboring mainland barren-ground caribou subpopulation located to the south of Victoria Island. However, the gene flow of the mainland barren-ground caribou into the Dolphin and Union caribou subpopulation is slower (McFarlane et al. 2014, p. 88). This phenomenon can be explained by the behavioral difference between male and female caribous. While female caribous display site fidelity, male caribous tend to wander farther afield. Because female Dolphin and Union calve exclusively on Victoria Island, they are geographically isolated from the mainland barren-ground caribou subpopulation (Nagy et al. 2011, p. 2,335). On the other hand, there is greater detection of first- and second-generation male migrants among other subpopulations of caribou (McFarlane et al. 2016, pp. 11, 14). This result suggests that some male Dolphin and Union caribou may migrate to other barren-ground caribou subpopulations resulting in outward gene flow. Additionally, in periods of multiple years the dispersal rate is zero, meaning
This conclusion is supported by other studies that identified the genetic distinctness of Dolphin and Union caribou from other caribou subpopulations (McFarlane et al. 2014, pp. 82-83; McFarlane et al. 2009, p. 125; Zittlau 2004, p. 113). Additionally, the Dolphin and Union caribou experience geographic isolation on Victoria Island during calving season, which contributes to a limited outward gene flow between the Dolphin and Union caribou and other populations of
Given that both the discreteness and the significance elements of the DPS policy are met for the Dolphin and Union caribou, we find that the Dolphin and Union caribou constitutes a valid DPS of
In 2004, COSEWIC (2004, entire) evaluated the status of Dolphin and Union caribou and assessed them as a special concern. In February 2011, Dolphin and Union caribou were added to Canada's Federal Species at Risk Act (SARA or S.C.) as a species of special concern (Stock Assessment Review Committee (SARC) 2013, p. 97). The recovery plan for the Dolphin and Union caribou published in 2018. We discuss the recovery plan in greater detail in Status of Existing Regulatory Mechanisms (Governments of the NWT and Nunavut 2018, entire; SARC 2013, p. 97). In 2017, COSEWIC assessed the Dolphin and Union caribou status to be endangered (COSEWIC 2017, p. x). However, as of the publication of this final rule, the Dolphin and Union caribou has not been reclassified as endangered under SARA.
Section 4 of the Act (16 U.S.C. 1533) and the implementing regulations in title 50 of the Code of Federal Regulations set forth the procedures for determining whether a species is an endangered species or a threatened species, issuing protective regulations for threatened species, and designating critical habitat for threatened and endangered species. In 2019, jointly with the National Marine Fisheries Service, the Service issued final rules that revised the regulations in 50 CFR parts 17 and 424 regarding how we add, remove, and reclassify threatened and endangered species and the criteria for designating listed species' critical habitat (84 FR 45020 and 84 FR 44752; August 27, 2019). At the same time the Service also issued final regulations that, for species listed as threatened species after September 26, 2019, eliminated the Service's general protective regulations automatically applying to threatened species the prohibitions that section 9 of the Act applies to endangered species (collectively, the 2019 regulations).
As with the proposed rule, we are applying the 2019 regulations for this final rule because the 2019 regulations are the governing law just as they were when we completed the proposed rule. Although there was a period in the interim—between July 5, 2022, and September 21, 2022—when the 2019 regulations became vacated and the pre-2019 regulations therefore governed, the 2019 regulations are now in effect and govern listing and critical habitat decisions (see
However, given that litigation remains regarding the court's vacatur of the 2019 regulations, we also undertook an analysis of whether the decision would be different if we were to apply the pre-2019 regulations. We concluded that the decision would have been the same if we had applied the pre-2019 regulations. The analyses under both the pre-2019 regulations and the 2019 regulations are included in the decision file for this final rule. The Act defines an endangered species as a species that is “in danger of extinction throughout all or a significant portion of its range,” and a threatened species as a species that is “likely to become an endangered species within the foreseeable future throughout all or a significant portion of its range.” The Act requires that we determine whether any species is an “endangered species” or a “threatened species” because of any of the following factors:
(A) The present or threatened destruction, modification, or curtailment of its habitat or range;
(B) Overutilization for commercial, recreational, scientific, or educational purposes;
(C) Disease or predation;
(D) The inadequacy of existing regulatory mechanisms; or
(E) Other natural or manmade factors affecting its continued existence.
These factors represent broad categories of natural or human-caused actions or conditions that could affect a species' continued existence. In evaluating these actions and conditions, we look for those that may have a negative effect on individuals of the species, as well as other actions or conditions that may ameliorate any negative effects or may have positive effects.
We use the term “threat” to refer in general to actions or conditions that are known to or are reasonably likely to negatively affect individuals of a species. The term “threat” includes actions or conditions that have a direct impact on individuals (direct impacts), as well as those that indirectly affect individuals such as through alteration of their habitat or required resources (stressors). The term “threat” may encompass—either together or separately—the source of the action or condition, or the action or condition itself.
However, the mere identification of any threat(s) does not necessarily mean that the species meets the statutory definition of an “endangered species” or a “threatened species.” In determining whether a species meets either definition, we must evaluate all identified threats by considering the expected response by the species, and the effects of the threats—in light of those actions and conditions that will ameliorate the threats—on an individual, population, and species level. We evaluate each threat and its expected effects on the species, then
The Act does not define the term “foreseeable future,” which appears in the statutory definition of “threatened species.” Our implementing regulations at 50 CFR 424.11(d) set forth a framework for evaluating the foreseeable future on a case-by-case basis. The term “foreseeable future” extends only so far into the future as the Services can reasonably determine that both the future threats and the species' responses to those threats are likely. In other words, the foreseeable future is the period of time in which we can make reliable predictions. “Reliable” does not mean “certain”; it means sufficient to provide a reasonable degree of confidence in the prediction. Thus, a prediction is reliable if it is reasonable to depend on it when making decisions. It is not always possible or necessary to define the foreseeable future as a particular number of years. Analysis of the foreseeable future uses the best scientific and commercial data available and should consider the timeframes applicable to the relevant threats and to the species' responses to those threats in view of its life-history characteristics. Data that are typically relevant to assessing the species' biological response include species-specific factors such as lifespan, reproductive rates or productivity, certain behaviors, and other demographic factors.
The species report documents the results of our comprehensive biological status review for the Dolphin and Union caribou, including an assessment of the potential threats to the DPS. The report does not represent a decision by the Service on whether the species should be listed as an endangered or threatened species under the Act. It does, however, provide the scientific basis that informs our regulatory decisions, which involve the further application of standards within the Act and its implementing regulations and policies. The following is a summary of the key results and conclusions from the report; the full report can be found at Docket FWS-HQ-ES-2019-0014 on
In this portion of the preamble, we review the biological condition of the species and its resources and factors that affect the species to assess the species' overall persistence. The Dolphin and Union caribou live in a harsh environment that is sparsely populated with people. Ecosystems can be complex, and factors affecting the health and viability of species are not always readily apparent. Caribou biologists have suggested a number of factors that may have contributed to the decline of the Dolphin and Union caribou. In addition to the major threats discussed below, we also assessed other threats that we concluded have minor effects on the species; those assessments can be found in our species report. The minor threats include deterioration of the quality and quantity of nutrients available within their habitat, predation (primarily by wolves), and outbreak of parasites or disease. The major threats that will be discussed below are:
• Sea-ice loss;
• Hindered ability to seasonally migrate due to lack of sea ice and possible drowning;
• Hunting;
• Disturbance due to development, oil and gas exploration, or shipping.
A primary factor affecting the Dolphin and Union caribou is the timing of freeze-up and sea-ice connectivity; these conditions are affected by ships breaking up the gray ice (young ice the thickness of which is less than 4-6 inches), other ice-breaking activities for tourism and oil and gas industries, and potential loss of sea ice due to climate change (Leclerc and Boulanger 2018, pp. 39-40; Dumund and Lee 2013, p. 335; Poole et al. 2010, entire). These related factors are discussed in two reports: Sea Ice and Migration of the Dolphin and Union Caribou Herd in the Canadian Arctic: An Uncertain Future (Poole et al. 2010, entire) and the species status report prepared by the Species at Risk Committee for the Dolphin and Union Caribou, published in December 2013, for the Northwest Territories (SARC 2013, entire). Additionally, a draft management plan for the Dolphin and Union caribou was made available for public comment in the spring of 2017 after a reassessment conducted by COSEWIC in 2015-2016 (Leclerc 2017, pers. comm.). We refer readers to these documents, which are available at
Changes in climate and weather patterns are suspected to be a major contributor to the decline of this caribou (Hansen et al. 2011, pp. 1,917, 1,920-1,922; Miller and Barry 2009, p. 176; Prowse et al. 2009a, p. 269; Tews et al. 2007a, pp. 95-96; COSEWIC 2004, pp. viii, 55-58). The term “climate change” thus refers to a change in the mean or variability of one or more measures of climate (
The demographic, ecological, and evolutionary responses of caribou to threats from climate change are complicated to predict. The complexity stems from the species' habitat requirements and resilience to the effects of climate change. Current models for the Arctic predict deeper snow cover, increasing rainfall, increasing rain-on-snow events, warm periods, more thawing-freezing cycles, and a higher risk of ice-layer formation on the soil within the snowpack during the winters of the coming decades (Hansen et al. 2011, p. 1,917; Turunen et al. 2009, pp. 813-814; Putkonen and Roe 2003, entire). Caribou populations respond negatively to the occurrence of more precipitation, greater snowfall, and subsequently more freezing rain events, which makes access to food more difficult (COSEWIC 2015, pp. 44-46; Miller et al. 2007, p. 33). However, other models support a conclusion that caribou may experience increases in population numbers if climate change results in a 50 percent increase of taller, denser vegetation and woody shrubs (Leclerc 2017, pers. comm.; Tews et al. 2007a, p. 95). As ecological systems are dynamic, it is complicated to predict how one change (such as a rise in temperature) will affect other elements within the ecosystem (such as the amount of precipitation that falls as freezing rain, rather than snow) (Parrott 2010, p. 1,070; Green and Sadedin 2005, pp. 117-118; Burkett et al. 2005, p. 357).
For the purpose of this assessment, given that the primary threat to the Dolphin and Union caribou is considered by caribou researchers to be loss of sea ice due to climate change and increase in shipping activities, we rely on climate projection models undertaken by the IPCC (IPCC 2014a, pp. 8-12). Relevant to our discussion, these models discuss future trends for precipitation and air and water temperature, which has an impact on
In addition to sea-ice loss, the thinning of sea ice can also have an impact on the caribou, because if sea ice is too thin, it will not be able to support the caribou's weight. We thus take into consideration changes in ratio over time between the thinner first-year ice versus the thicker, multiyear ice (Li et al. 2019, p. 2) in the Dolphin and Union caribou's range. In addition to changes in sea ice, because the Dolphin and Union caribou use the Dolphin and Union strait as part of its migration route, we also take into account information on historical, current, and projected shipping traffic through the Dolphin and Union strait. Because of a projected increase in ice-free periods, shipping traffic is highly likely to increase (Governments of the NWT and Nunavut 2018, p. 41).
Most models project that portions of the Canadian Arctic will be ice free by 2040-2060 (Derksen et al. 2018, pp. 198, 218; Johnson et al. 2017, p. 16; Lu et al. 2014, p. 61).
Sea ice is an important component of the seasonal migration of the Dolphin and Union caribou. Dolphin and Union caribou migrate across the Dolphin and Union Strait using the temporary, annual seasonal ice bridge from Victoria Island to the mainland. During the months of September and October, Dolphin and Union caribou “stage” on the south coast of Victoria Island waiting for the ice to form for the herds to cross. The caribou may cross at any time during this time period on the newly formed gray ice to their winter range on the mainland (Nishi and Gunn 2004, as cited in COSEWIC 2004, p. 35). More recently, the formation of the sea ice has been delayed, which results in caribou waiting a longer period for ice to form. Due to limited food availability on Victoria Island during the winter months to support the herd during the winter months, longer delays for crossings risk reducing the fitness of individuals within the herd. Furthermore, when crossings do take place, because of the delay in sea ice formation, the sea ice that forms is often too thin to hold the caribou's weight resulting in individuals falling through the ice. This likely increases energy consumption for the caribou to get out of the water, and increases the likelihood of both individual and mass drowning events (Poole et al. 2010, p. 414; Gunn 2003, as cited in COSEWIC 2004, p. 35).
Since the beginning of monitoring in 1979, record low levels of sea ice have occurred in recent years. From 1968 to 2015, sea ice declined at a rate of 6.1 percent per decade (Environment and Climate Change Canada 2016, p. 8). Multiyear ice, which is thick enough to support the caribou's weight, has been declining over time. In the mid-1980s, multiyear ice accounted for 75 percent of all ice in the Arctic. By 2011, it accounted for 45 percent of all ice (Li et al. 2019, p. 2). Climate models indicate that the Arctic will continue to experience accelerated loss of sea ice (Zhang et al. 2010, as cited in in Meier et al. 2011, p. 9-3; Boé et al. 2009, p. 1; Wang and Overland 2009, pp. 1-3).
Additionally, landfast ice has also been decreasing. Landfast ice is important to the Dolphin and Union caribou as the Dolphin and Union strait is a narrow passage that the DPS uses for its migration corridors. Over the 10-year intervals starting in 1976, the maximum extent of landfast ice throughout the Arctic was: 2.1×10
A decrease in sea ice has continued to occur with trends accelerating since the year 2000 (COSEWIC 2015, p. 46). Sea-ice freezing now occurs 8-10 days later in the Dolphin and Union Strait and Coronation Gulf than in 1982 (Poole et al. 2010, pp. 414, 419, 425). Current and projected decreases in sea ice is negatively affecting and is likely to continue to negatively affect the crossings by the Dolphin and Union caribou, including the potential of breaking through the ice and drowning (Governments of the NWT and Nunavut 2018, pp. 41-42; Poole et al. 2010, p. 426). Because the Dolphin and Union strait is located at the southernmost point of the Canadian Arctic Archipelago, sea-ice loss in this region is higher than in other regions farther to the north (Pizzolato 2015, p. 28). Additionally, continued increase in shipping is expected through the Northwest Passage (Governments of the NWT and Nunavut 2018, p. 42). The effects of increasing shipping will be especially pronounced for the Dolphin and Union caribou because the Dolphin and Union strait is the primary migration route for the caribou and is also a major shipping lane through the Northwest Passage (Engeler and Pelot 2013, p. 9).
As the sea-ice season is shortened and the ice thins, it is more easily broken by ice-breaking ships. A longer shipping season and an increase in ships in the Northwest Passage can fragment the Dolphin and Union caribou's summer and wintering ranges while delaying their migration. Due to the shorter sea-ice season, the number of ships travelling through the Northwest Passage has already increased from four per year in the 1980s to 20-30 per year in 2009-2013. The majority of these transits are icebreakers with trips primarily occurring in August through October, the period of time when the Dolphin and Union caribou are preparing for their southward migration to the mainland (Governments of the NWT and Nunavut 2018, p. 41). For example, in late October 2007, barge ships broke the ice every 12 hours for a few days in the Cambridge Bay to keep a channel open. This channel prevented the caribou from crossing during this time (Poole et al. 2010, p. 426). As stated above, sea-ice freezing in the fall now forms 8-10 days later than it did in 1982. Using RCP models 4.5 and 8.5, the annual time period where the Arctic is ice-free is projected to increase over the course of the 21st century (Governments of the NWT and Nunavut 2018, p. 43; Poole et al. 2010, p. 425). Given the increases in periods of ice-free months, it is reasonable to conclude that shipping traffic through the strait will increase over the course of the 21st century. Therefore, the breaking up of sea ice due to continued increases in shipping traffic, combined with projected sea-ice loss due to climate change will have a significant negative impact on the species now and into the future (Governments of the NWT and Nunavut 2018, pp. 41-44; Leclerc and Boulanger 2018, pp. 39-40; Johnson
Given the Dolphin and Union caribou's current population, it is unlikely that Victoria Island will be able to support the subpopulation if
Climate change is negatively affecting and likely to continue to negatively affect the Dolphin and Union caribou in a number of ways. The most significant impact of climate change on the caribou is the timing of the formation of sea ice. As part of their life cycle, Dolphin and Union caribou migrate between calving ground on Victoria Island and wintering ground on the mainland (Nishi and Gunn 2004, as cited in COSEWIC 2004, p. 35). However, sea-ice formation has been delayed with caribou having to wait for a longer period of time before they can cross between Victoria Island and the mainland (Poole et al. 2010, p. 414; Gunn 2003, as cited in COSEWIC 2004, p. 35). In addition to a delay in sea-ice formation, the sea ice that forms tends to be thinner, increasing the likelihood of ice breakup and drowning events (Poole et al. 2010, p. 426).
Overall, the Dolphin and Union caribou subpopulation appears to continue to decline (Leclerc and Boulanger 2018, p. 36; Gunn et al. 2000, pp. 42-43).The delay and loss in the formation of sea ice can impact the Dolphin and Union caribou's ability to migrate between the mainland and Victoria Island thereby increasing the likelihood of mass mortality event as a result of drowning and starvation due to insufficient food resources on Victoria Island during the winter months. Therefore, given the projected impacts of sea-ice loss in the Dolphin and Union strait, we conclude that these effects have had a negative impact on the Dolphin and Union caribou.
Caribou serve as host to two oestrid species: warble flies (
Temperature and cloud cover are vital factors for harassment of caribou by warble flies as these two factors affect the flies' activity level (Weladji et al. 2003, p. 80; Nilssen 1997, p. 301). Warble flies are most active during warm, sunny days; warble fly activity increases with increasing temperature (Weladji et al. 2003, p. 80). Within the Arctic, the annual mean surface temperature has increased at a rate of 0.34 degrees Celsius (°C) (0.61 degrees Fahrenheit (°F)) per decade from 1982 to 2004 (Wang et al. 2012, p. 1). The duration of the melt season has increased by 10-17 days per decade, which is representative of these warmer temperatures (Comiso 2003, p. 3,498).
In Cambridge Bay, Victoria Island, the mean average daily temperature in the winter is between −36.2 and −29.8 °C (−33.2 and −21.6 °F). In summer, the mean average daily temperature is between −6.8 and 10 °C (37.4 and 44.2 °F) (Dumund and Lee 2013, p. 330). Average annual temperatures may increase by 3-6 °C by 2080 (Meier et al. 2011, pp. 9-17-9-18; Olsen et al. 2011, p. 112; Dunkley-Jones et al. 2010, p. 2,411). Based on these anticipated temperatures, we calculated the expected temperatures if the temperature was to increase by 3 °C (scenario 1) and by 6 °C (scenario 2). The climate models used in this table used a previous set of scenarios known as the Special Report on Emissions Scenarios (SRES) to project the low-emissions scenario (SRES B1) and high-emissions scenario (SRES A2). More recently, a newer set of scenarios (
The low-temperature threshold for warble fly activity is around 10 °C (50 °F) (Vistness et al. 2008, p. 1,312; Weladji et al. 2003, p. 81; Nilssen 1997, pp. 296, 300; Breyev 1956, 1961, as cited in Nilssen and Anderson 1995, p. 1,236). Before pupation, warble fly larvae can move at least 30 centimeters (12 inches) per day at 4 °C (39.2 °F). At 4 °C (39.2 °F), pupation did not occur, but larvae were observed to be alive (crawling) up to 47 days after exit from the host (Nilssen 1997, p. 298). The transition of warmer temperatures to areas of cooler air creates a barrier north of which pupation may not occur. Because parasitic fly harassment is low below 13 °C (55.4 °F), and no oestrid harassment occurs below 10 °C (50 °F), this temperature threshold is significant for caribou, particularly the Dolphin and Union caribou with respect to oestrid harassment. Under both scenarios, summer temperatures are projected to increase to a high of 13-16 °C where the Dolphin and Union caribou occur, which would result in an increase in warble fly harassment.
Infestations by both warble flies and botflies result in metabolic costs, such as behavioral responses (Witter et al. 2012, p. 292; Nilssen and Anderson 1995, p. 1,237). Caribou increase and modify their movement when harassed by warble flies (Witter et al. 2012, p. 284). When warble flies are present, caribou spend a greater proportion of time avoiding insects, rather than resting or feeding (Witter et al. 2012, p. 292; Fauchald et al. 2007, p. 496). Avoidance behaviors include jumping, running, leg stomping, and, with respect
Caribou experts consider the potential negative effects of nose botfly on caribou to be less than warble flies. While the types of effects are similar between the two species of flies, such as causing avoidance behavior in caribou, the magnitude of those effects are not as extreme for the nose botfly as that caused by the warble fly. This species enters the caribou through the caribou's nose and lives in the caribou's throat for part of its life cycle. The caribou exhibit distress from this species—they have been observed to duck their heads under water to avoid nose botflies (Witter et al. 2012, p. 284; Fauchald et al. 2007, p. 496). An increase in the temperature by more than 3 or 6 °C in July could increase harassment of nose botflies on the Dolphin and Union caribou, although the severity will not be as high as that caused by warble flies.
Currently, oestrids that use caribou as their hosts are at the latitudinal extreme of their range due to temperature, hours of daylight, and wind conditions (Vistness et al. 2008, p. 1,307). We note that a threat to the Dolphin and Union caribou and the caribou's response to that threat are not, in general, equally predictable or foreseeable. Oestrid flies could expand their range, and they could possibly negatively affect the Dolphin and Union caribou if the temperature increases by 3 to 6 °C by 2080. The low-temperature threshold for warble fly activity has been determined to be around 10 °C (50 °F) (Vistness et al. 2008, p. 1,312; Weladji et al. 2003, p. 81; Nilssen 1997, pp. 296, 300; Breyev 1956, 1961, as cited in Nilssen and Anderson 1995, p. 1,236). However, a warmer climate is likely to increase the distribution and abundance of warble flies and will lead to greater impact on the Dolphin and Union caribou.
Under the Act, we are required to evaluate whether the existing regulatory mechanisms are adequate. With respect to existing regulatory mechanisms, the Dolphin and Union caribou was listed as special concern under SARA in 2011 and the Government of the Northwest Territories Species at Risk Act (SARC 2013, p. v). “Special concern” means that the Northwest Territories (NWT) manage a species on the basis that it may become threatened if it is not managed effectively. Species listed as of special concern are not protected under prohibitions that apply to threatened and endangered species. For these species, conservation benefits are provided through a management plan that is prepared after the species is listed (S.C. Ch. 65). In 2017, COSEWIC recommended the herd be listed as endangered due to population decline within the past 20 years and continued persistence of threats related to climate change (COSEWIC 2017, p. x). However, as of 2022, the Dolphin and Union caribou has not yet been changed from a species of special concern to endangered under SARA.
The management plan for the Dolphin and Union caribou was published in 2018 (NWT 2018, entire; SARC 2013, p. 97). The management plan contains a list of recommended actions, including holding regular meetings between management agencies and local communities to make recommendation on the management of the Dolphin and Union caribou, monitoring changes in the Dolphin and Union caribou's population and habitat, and obtaining better harvest data (Governments of the NWT and Nunavut 2018, pp. 56-61). However, these recommendations are voluntary (Governments of the NWT and Nunavut 2018, p. 3). While the management plan does not commit any parties to any actions, the management and hunting of the Dolphin and Union caribou is mutually agreed upon by the native people (Inuit and Inuvialuit) and the territorial governments (NWT and Nunavut). Species experts note that the jurisdictional structure of caribou management in Canada is complex (Festa-Bianchet et al. 2011, p. 422). Wildlife management in the territories is under a co-management structure and falls under the Land Claims Agreement of the different indigenous groups. Caribou conservation involves legislation at the Federal and Territorial levels, in addition to wildlife management boards (COSEWIC 2004, p. 61).
Caribou are an integral element of human society in the high Arctic (Taylor 2005, as cited, in Maher et al. 2012, p. 78; Miller and Barry 2009, p. 176). Under SARA, exceptions to prohibitions enable indigenous peoples to exercise their harvesting rights (COSEWIC 2015, p. 52). The Dolphin and Union caribou is currently hunted by the Inuit and Inuvialuit for subsistence, and this subsistence hunting is managed by local governments and the communities. However, concerns about the sustainability of hunting exist due to the lack of accurate harvesting data, although mandatory reporting has recently been implemented for indigenous communities (Governments of the NWT and Nunavut 2021, p. 2; Governments of the NWT and Nunavut 2018, pp. 20, 67; Governments of Nunavut and the NWT 2011, p. 18). Caribou are protected by land claim agreements, and hunts are co-managed by boards such as the Nunavut Wildlife Management Board, the Government of Nunavut, Department of Environment (GN-DOE), and hunting associations (COSEWIC 2004, p. 61). The Wildlife Management Advisory Council for the Inuvialuit Settlement Region in the Northwest Territories, Nunavut Wildlife Management Board for the Nunavut Territory, the GN-DOE, and the Inuit and Inuvialuit native people all play a role in the regulation of hunting of the Dolphin and Union caribou population.
Although there are no harvest limitations of the Dolphin and Union caribou for indigenous communities, Inuit hunters who hunt caribou for subsistence have voluntarily placed moratoriums on hunts in the past (Governments of the NWT and Nunavut 2018, pp. 20-21). Based on extrapolations of harvest between 1996 and 2001 of the communities of Kugluktuk, Cambridge Bay, Umingmaktok, and Bathurst Inlet, subsistence harvest of the “island” caribou (which may include individuals not from the Dolphin and Union herd) in Nunavut was estimated to be from 2,000 to 3,000 annually for those years (Schneidmiller 2011, p. 1). From 1988 to 1997, annual harvest of Dolphin and Union caribous by the community of Ulukhaktok varied between 178 and 509 per year (Governments of the NWT and Nunavut 2018, p. 20). Since then, local communities have tried to reduce the annual harvests of the caribou through the implementation of a quota system (Governments of the NWT and Nunavut 2021, in litt.). Data for 2010-2014 reveal a decline of annual harvest to 10-80
In contrast to indigenous communities, Canadian citizens and resident immigrants are limited to a specific number of caribou they can hunt per year. Non-subsistence hunting including sport-hunting by nonindigenous residents and nonresidents is managed through an annual quota system (Governments of the NWT and Nunavut 2018, pp. 68-69). In the NWT, Canadian citizens and residents are allowed to take up to two bulls per year during the hunting season (August 15-November 15). Nonresident and non-Canadian citizens are allowed the same number but need to be accompanied by a guide. In Nunuvut, residents can hunt up to five caribou per year (Governments of the NWT and Nunavut 2018, pp. 68-69). Despite the availability of hunting tags, in the past several years, no tag-based sport-hunting of Dolphin and Union caribou has occurred in Nunavut (Governments of the NWT and Nunavut 2018, p. 69; Leclerc 2017, pers. comm.; Governments of Nunavut and the NWT 2011, p. 18). Hunting is now currently restricted to indigenous hunters (Governments of the NWT and Nunavut 2021, in litt.).
In the NWT, the governments reported that 25 tags are available annually for outfitted sport-hunting on Dolphin and Union caribou, but no such hunts have occurred in more than 20 years (Governments of NWT and Nunavut 2011, p. 10). At a more local scale, committees and trapper associations are involved in monitoring caribou. In 2007, nonbinding management recommendations were made to maintain a balanced harvest for subsistence (
With respect to imports into the United States, as noted above, no tag-based non-subsistence hunting (sport-hunting) has occurred in Nunavut or NWT in recent years, and no trade data indicates that Dolphin and Union caribou are hunted and subsequently imported into the United States. This caribou entity is not listed in the Appendices of the Convention on International Trade in Endangered Species of Wild Fauna and Flora (CITES) (
Hunting has not been implicated as a current threat to Dolphin and Union caribou. While unsustainable hunting may have contributed to a historical decline in the Dolphin and Union caribou, currently subsistence hunting is managed, and sport hunting is not taking place. (Dumond and Lee 2013, p. 329; SARC 2013, p. ix; Dumund 2012, unpaginated). The Dolphin and Union caribou is being monitored closely by the Government of Nunavut, the Government of the Northwest Territories, and the Government of Canada. In summary, hunting may have played a role in the decline of the Dolphin and Union caribou in the past; however, management of the Dolphin and Union caribou has reduced the impact of hunting.
The southwestern portion of the Dolphin and Union caribou range lies within the boundaries of Tuktut Nogait National Park (COSEWIC 2017, p. 4). While protected, this area constitutes a small portion of the DPS's overall range. On the other hand, the calving ground for the Dolphin and Union caribou on Victoria Island is not protected. Studies are currently under way to define a calving strategy and determine suitable habitat (Leclerc and Boulanger 2018, pp. 37-38). Caribou biologists indicate that areas that are suitable for calving but are currently unused should be anticipated and managed for potential future use (Nagy 2011, p. 35). The best available information suggests that current protected areas are well managed.
The Northwest Passage, which includes the Dolphin and Union Strait, is likely to become more navigable to large ships in the near future due to decreased ice in the passage, and thus could be exposed to increased exploration activities. Ships traveling through the Northwest Passage could be routed through the Dolphin and Union Strait as temperatures become substantially warmer. In recent years, the strait has been ice free for 2 months during the summer, leading to increased maritime traffic with heavy ship traffic concentrating around the strait used by the Dolphin and Union caribou (Leclerc 2017, pers. comm.; Pizzolato et al. 2016, pp. 12,148-12,149). Given that ice levels in the 2010-2012 periods have been the lowest since 1968, it is very likely that shipping traffic through the strait will increase (Howell et al. 2013, as cited in Pizzolato et al. 2016, p. 12,152). Currently, traffic to the Beaufort Sea is the second highest in the Northwest Passage after the Hudson Bay (Pizzolato et al. 2016, p. 12,149; SARC 2013, p. 94). Shipping traffic through the strait increases in years where multiyear-ice levels, which present significant impediment to ship traffic, are low (Pizzolato et al. 2016, p. 12,152). In the Victoria Strait region (located at the opposite end of the channel to the Dolphin and Union strait), shipping activity tripled during the 2006-2013 period (Pizzolato et al. 2016, p. 12,152). Shipping traffic negatively affects the migration of the Dolphin and Union caribou by causing ice breakup during the winter (SARC 2013, p. 47).
If the warming trend continues in this region as climate models indicate, conditions for offshore oil and gas exploration and production will likely improve, increasing the likelihood of shipping traffic (Pizzolato et al. 2016, p. 12,152; Barber et al. 2008, p. 17). The potential increase in mining and shipping traffic in the Dolphin and Union Strait could have demographic and ecological consequences for the Dolphin and Union caribou. A larger number of Dolphin and Union caribou on the mainland have been sighted with thicker coats of fur, suggesting that more of them are falling through the ice (Poole et al. 2010, p. 416). While increasing shipping traffic will lead to the breakup of the ice, some Inuit have indicated ships run through the straits during the summer months, which is outside of the primary migration months (SARC 2013, p. 47). However, the reduction in multiyear ice in the strait over time will result in greater shipping traffic even during the winter (Pizzolato et al. 2016, p. 12,152; SARC 2013, p. 94).
Compounding the increasing trend of shipping traffic is a complicated
In an attempt to better coordinate these different regulations and protect environmentally sensitive areas, Canada began to implement the Northern Marine Transportation Corridors (NMTC) Initiative in 2017. This initiative involves multiple governing agencies including the Canadian Coast Guard, Transport Canada and the Canadian Hydrographical Service. The initiative sought to limit the ecological impact of shipping by identifying routes where service levels and supporting infrastructure are available at the highest level. One of the routes identified would pass through the Dolphin and Union strait. While local communities and civil society has expressed general support for the initiative, concerns remain regarding the integration and creation of protection for environmentally and culturally sensitive areas (Porta et al. 2017, p. 67). This suggest that more efforts and coordination need to take place between governing agencies, the shipping industry, and local communities to better manage and mitigate the effects of shipping on the environment. Overall, while Canada has undertaken efforts to better manage environmentally sensitive areas, in light of increasing shipping traffic as a result of loss of sea ice, more coordination will likely be needed to mitigate the effects of shipping on the local ecosystem.
Species endemic to small regions, or known from few, widely dispersed locations, are inherently more vulnerable to extinction than widespread species because of the higher risks from localized stochastic (random) events and processes, such as industrial spills and drought. Those species face an increased likelihood of stochastic extinction due to changes in demography, the environment, genetics, or other factors, in a process described as an extinction vortex (a mutual reinforcement that occurs among biotic and abiotic processes that drives population size downward to extinction) (Courtois et al. 2003, pp. 394, 402). The negative impacts associated with vulnerability to random demographic fluctuations or natural catastrophes can be further magnified by synergistic interactions with other threats.
The Dolphin and Union caribou is known from a single geographic population that migrates between Victoria Island and the Canadian mainland (SARC 2013, p. xiv; Governments of NWT and Nunavut 2011, p. 2; Poole et al. 2009, p. 415). As a result, the Dolphin and Union caribou is vulnerable to stochastic processes and is highly likely to be negatively affected by these processes. Year-to-year variation in the timing of sea-ice formation, shipping traffic, and usage of icebreakers, in combination with other threats, could impact the migration of the Dolphin and Union caribou (Poole et al. 2010, pp. 414, 419, 425; Sharma et al. 2009, p. 2,559). Therefore, it is likely that stochastic processes have negative impacts on the species in combination with other factors such as sea-ice loss and shipping. Given the recent, significant decline in the Dolphin and Union caribou, the effects of stochastic events on the herd will be magnified resulting in greater vulnerability.
We have evaluated the individual threats to the Dolphin and Union caribou throughout its range. The primary threat affecting the Dolphin and Union caribou is the loss of sea ice due to climate change and increased shipping through the straits. Other factors, though not as severe as loss of sea ice and shipping, can become threats in the future due to the cumulative effects they will have on the Dolphin and Union caribou. For the Dolphin and Union caribou DPS, warble fly and nose botfly harassment, disease, and predation are threats that, synergistically, could have an impact on the Dolphin and Union caribou.
As discussed above in this document, the Dolphin and Union caribou population continues to decline from its recent peak in 1997 (Dumond and Lee 2013, p. 334). While the exact cause of the decline is not known, a number of factors acting synergistically can put additional pressure on the population. Botfly harassment has the potential to increase if surface temperature increases by more than 3-6 °C (Dumund and Lee 2013, p. 330). One recent climate-projection model points toward an increase in botfly activity, which will increase the energy expenditure of caribou (Witter et al. 2012, p. 284). Although these factors individually do not amount to a significant threat to the Dolphin and Union caribou, acting synergistically with major threats of sea-ice loss and shipping, they can have a detrimental impact.
In our August 31, 2021, proposed rule (86 FR 48619), we requested that all interested parties submit written comments on the proposal by November 1, 2021. We also contacted appropriate Federal agencies, scientific experts and organizations, and other interested parties and invited them to comment on the proposed rule. We did not receive any requests for a public hearing. All substantive information provided during the comment period either has been incorporated directly into the final rule or is addressed below.
In accordance with our joint policy on peer review published in the
We received 12 public comments in response to the proposed rule. We reviewed all comments we received during the public comment period for substantive issues and new information regarding the proposed rule. Two commenters provided substantive comments or new information concerning the proposed listing and 4(d) rule for Dolphin and Union caribou. Below, we provide a summary of the two substantive issues raised in the public comments we received. Comments outside the scope of the proposed rule, and those without supporting information, did not warrant an explicit response and, thus, are not presented here. Similar comments have been consolidated.
(1) The Governments of Nunavut and the Northwest Territories provided additional information on the hunting program currently implemented in Canada. Specifically, the comment identified current harvesting quotas and types of individuals who are allowed to hunt.
(2) Two comments, one from the Governments of Nunavut and the Northwest Territories, provided updated information resulting from surveys conducted in 2018 and 2020. As noted above, these new surveys identified significant decline in the herd after 2015.
Section 4 of the Act (16 U.S.C. 1533) and its implementing regulations (50 CFR part 424) set forth the procedures for determining whether a species meets the definition of “endangered species” or “threatened species.” The Act defines an “endangered species” as a species that is in danger of extinction throughout all or a significant portion of its range and a “threatened species” as a species that is likely to become an endangered species within the foreseeable future throughout all or a significant portion of its range. The Act requires that we determine whether a species meets the definition of “endangered species” or “threatened species” because of any of the following factors: (A) the present or threatened destruction, modification, or curtailment of its habitat or range; (B) overutilization for commercial, recreational, scientific, or educational purposes; (C) disease or predation; (D) the inadequacy of existing regulatory mechanisms; or (E) other natural or manmade factors affecting its continued existence. For a more detailed discussion on the factors considered when determining whether a species meets the definition of “endangered species” or “threatened species” and our analysis on how we determine the foreseeable future in making these decisions, please see Regulatory and Analytical Framework, above.
We have carefully assessed the best scientific and commercial information available regarding the past, present, and future threats to the Dolphin and Union caribou. In section 3(6), the Act defines an “endangered species” as any species that is in danger of extinction throughout all or a significant portion of its range and in section 3(20), defines a “threatened species” as any species that is likely to become an endangered species within the foreseeable future throughout all or a significant portion of its range. The best available information indicates that the Dolphin and Union caribou has experienced a steep decline (Leclerc and Boulanger 2018, p. 36). A number of threats including sea ice loss, icing events, and parasitic harassment, acting synergistically likely played a role in reducing the population. We have concluded that the decline was primarily as a result of loss of sea ice due to climate change and an increase in shipping traffic (Factor A). Other threats, including parasitism (Factor C), predation (Factor C), and hunting (Factor B), have a limited or unknown impact at this time, but could become more serious threats in the future.
Although the herd has changed its migration patterns and its resource use in the past, access to the wintering ground on the mainland played an important role in the historical recovery of the species (Leclerc and Boulanger 2018, p. 37; Nishi and Gunn 2004, as cited in COSEWIC 2004, p. 35). Current trends indicate sea-ice loss in the Dolphin and Union caribou's range will continue through the end of the 21st century (Meier et al. 2011, pp. 9-2-9-3; Wang and Overland 2009, p. L07502; Boé et al. 2009, p. 1). While crossings are still taking place suggesting that current sea-ice thickness is sufficient for crossing (Governments of the NWT and Nunavut 2018, p. 30), the continued decline in the DPS population suggests that other stressors are having a larger effect in negatively affecting the Dolphin and Union caribou's current overall resilience.
One such factor in addition to sea-ice loss from climate change is the increase in shipping traffic through the Dolphin and Union caribou's habitat, which delays the formation of sea ice. Sea ice between Victoria Island and the mainland now forms 8-10 days later than it did in 1982, a trend that will continue to accelerate (Poole et al. 2010, p. 414). Additionally, because the Dolphin and Union strait occurs at the southernmost point of the Northwest Passage, shipping traffic is more concentrated in this region than in other portions of the Canadian Archipelago (Pizzolato et al. 2016, pp. 12,148-12,149). The continued increase in shipping traffic combined with projected ice loss in this region will have a significant effect on the Dolphin and Union caribou by delaying or preventing the migration to wintering grounds on the mainland (Poole et al. 2010, p. 414). Additionally, the breaking up of the sea ice can result in caribous falling through the thinner ice and increases the likelihood of mass drowning events.
Although the Dolphin and Union caribou was able to adapt in the past after the caribou ceased migration to the mainland during the early 1900s due to introduction of firearms (USFWS 2021, pp. 9-10), the trend since 1997 suggests a steady decline. Furthermore, given the decline in the DPS population, it is unlikely that Victoria Island will be able to support the Dolphin and Union caribou (Leclerc and Boulanger 2018, p. 39). Additionally, with only one extant population, the Dolphin and Union caribou possess very limited redundancy making it highly susceptible to stochastic events. The Dolphin and Union caribou representation is also limited as little to no genetic exchange occurs with adjacent caribou subspecies. As noted in
In addition to the potential loss of connectivity between Victoria Island and the mainland, the Dolphin and Union caribou also experience impacts from other threats. The impacts of these other threats, however, are more uncertain. Insect harassment from warble flies increases the energy expenditure of affected animals (Scheer 2004, pp. 10-11). With regard to disease, although local communities have identified affected individuals, the impact on the overall subpopulation is unknown (SARC 201, p. 80). Predation could have an impact on the Dolphin and Union caribou. Earlier reports suggest that predation does not represent a major threat, but lingering concerns remain (COSEWIC 2017, p. 27; Gunn 2005, pp. 10-11, 39-41). Lastly, while unregulated hunting played an important role in the historical decline of the Dolphin and Union caribou, current management efforts in place regulate hunting, and sport hunting is not currently taking place. However, the DPS continues to decline (Dumond and Lee 2013, p. 329; SARC 2013, p. ix; Dumond 2012, unpaginated). As noted elsewhere, the Dolphin and Union caribou has consistently declined within the past 20 years to around 3,800 individuals from 34,000 individuals, and the resiliency of the DPS has been significantly compromised, affecting its ability to withstand stochastic events (Campbell et al. 2021, p. 2). Furthermore, with only one extant population, the Dolphin and Union caribou has very limited redundancy and representation.
In summary, the Dolphin and Union caribou has experienced significant population change over the past century. The Dolphin and Union caribou experienced a significant decline in the early 20th century due to the introduction of firearms and excessive hunting (COSEWIC 2004, p. 41; Gunn et al. 2011, p. 37; Manning 1960, pp. 9-10). The population rebounded in the latter half of the 20th century reaching its maximum size in 1997. Since then, however, the single population of the Dolphin and Union caribou has declined once more. Surveys conducted in 2007 revealed a modest decline of the species (Dumond and Lee 2013, p. 334). A survey in 2015 revealed that the decline continues (Governments of the NWT and Nunavut 2018, p. 36; Leclerc and Boulanger 2018, p. 36). Additionally, recent survey data in 2018 and 2020 documented continued, major decline from approximately 18,000 individuals in 2015 to about 3,800 individuals in 2020 (Campbell et al. 2021, p. 2). We find that a number of threats, including primarily sea-ice loss due to climate change and shipping, and to a lesser extent insect harassment, predation, and hunting, acting in tandem and synergistically, has negatively impacted the species to such a degree that is in danger of extinction.
Given the new information regarding the continued decline and current population size of the species, we have reevaluated the status of the species. In the proposed rule, we concluded that continuation of the current trends would likely result in the species becoming in danger of extinction within the foreseeable future. We now find that a number of threats, including primarily sea-ice loss due to climate change and shipping, and to a lesser extent insect harassment, predation, and hunting, acting in tandem and synergistically, has negatively impacted the species to such a degree that it is already in danger of extinction, even in the absence of future intensification of the threats.
Therefore, after evaluating threats to the species and assessing the cumulative effect of the threats under the section 4(a)(1) factors, we conclude that the Dolphin and Union caribou is currently in danger of extinction throughout all of its range as a result of the ongoing and projected decline caused by the increase in threats described above that has already occurred.
Under the Act and our implementing regulations, a species may warrant listing if it is in danger of extinction or likely to become so in the foreseeable future throughout all or a significant portion of its range. We have determined that the Dolphin and Union caribou is in danger of extinction throughout all of its range and accordingly did not undertake an analysis of any significant portion of its range. Because the Dolphin and Union caribou warrants listing as endangered throughout all of its range, our determination is consistent with the decision in
Our review of the best available scientific and commercial information indicates that the Dolphin and Union caribou DPS meets the definition of an endangered species. Therefore, we are listing the Dolphin and Union caribou DPS as an endangered species in accordance with sections 3(6) and 4(a)(1) of the Act.
The purposes of the Act are to provide a means whereby the ecosystems upon which endangered species and threatened species depend may be conserved, to provide a program for the conservation of such endangered species and threatened species, and to take such steps as may be appropriate to achieve the purposes of the treaties and conventions set forth in the Act. Under the Act there are a number of tools available to advance the conservation of species listed as endangered or threatened species under the Act. As explained further below, these conservation measures include: (1) recognition, (2) recovery actions, (3) requirements for Federal protection, (4) financial assistance for conservation programs, (5) prohibitions against certain activities.
Recognition through listing results in public awareness, as well as in conservation by Federal, State, Tribal, and local agencies, foreign governments, private organizations, and individuals. The Act encourages cooperation with the States and other countries and calls for recovery actions to be carried out for listed species.
Our regulations at 50 CFR part 402 implement the interagency cooperation provisions found under section 7 of the Act. Under section 7(a)(1) of the Act, Federal agencies are to use, in consultation with and with the assistance of the Service, their authorities in furtherance of the purposes of the Act. Section 7(a)(2) of the Act, as amended, requires Federal agencies to ensure, in consultation with the Service, that any action authorized, funded, or carried out by such agency is not likely to jeopardize the continued existence of a listed species or result in destruction or adverse modification of its critical habitat.
A Federal “action” that is subject to the consultation provisions of section 7(a)(2) is defined in our implementing regulations at 50 CFR 402.02 as all activities or programs of any kind authorized, funded, or carried out, in whole or in part, by Federal agencies in the United States or upon the high seas. With respect to the Dolphin and Union caribou, actions that may require consultation under section 7(a)(2) of the Act include incidental take of the caribou on the high seas. Additionally, no critical habitat will be designated for this species because, under 50 CFR 424.12(g), we will not designate critical habitat within foreign countries or in other areas outside of the jurisdiction of the United States.
Section 8(a) of the Act (16 U.S.C. 1537(a)) authorizes the provision of limited financial assistance for the development and management of programs that the Secretary of the Interior determines to be necessary or useful for the conservation of endangered or threatened species in foreign countries. Sections 8(b) and 8(c) of the Act (16 U.S.C. 1537(b) and (c)) authorize the Secretary to encourage conservation programs for foreign listed species, and to provide assistance for such programs, in the form of personnel and the training of personnel.
The Act puts in place prohibitions against certain actions with listed species. The Act and its implementing regulations set forth a series of general prohibitions and exceptions that apply to all endangered wildlife. The prohibitions of section 9(a)(1) of the Act, codified at 50 CFR 17.21, make it illegal for any person subject to the jurisdiction of the United States to import; export; deliver, receive, carry, transport, or ship in interstate or foreign commerce, by any means whatsoever and in the course of commercial activity; or sell or offer for sale in interstate or foreign commerce any species listed as an endangered species. In addition, it is unlawful to take (which includes harass, harm, pursue, hunt, shoot, wound, kill, trap, capture, or collect; or to attempt any of these) endangered wildlife within the United States or on the high seas. It is also illegal to possess, sell, deliver, carry, transport, or ship, by any means whatsoever any such wildlife that has been taken illegally. Under section 9(g) of the Act it is also unlawful for any person subject to the jurisdiction of the United States to attempt to commit, solicit another to commit, or cause to be committed, any of these prohibited acts. Certain exceptions apply to employees of the Service, the National Marine Fisheries Service, other Federal land management agencies, and State conservation agencies
We may issue permits to carry out otherwise prohibited activities involving endangered wildlife under certain circumstances. Regulations governing permits for endangered wildlife are codified at 50 CFR 17.22, and general Service permitting regulations are codified at 50 CFR part 13. With regard to endangered wildlife, a permit may be issued for the following purposes: For scientific purposes, to enhance the propagation or survival of the species, and for incidental take in connection with otherwise lawful activities. The Service may also register persons subject to the jurisdiction of the United States through its captive-bred-wildlife (CBW) program if certain established requirements are met under the CBW regulations (50 CFR 17.21(g)). Through a CBW registration, the Service may allow a registrant to conduct certain otherwise prohibited activities under certain circumstances to enhance the propagation or survival of the affected species: take; export or re-import; deliver, receive, carry, transport or ship in interstate or foreign commerce, in the course of a commercial activity; or sell or offer for sale in interstate or foreign commerce. A CBW registration may authorize interstate purchase and sale only between entities that both hold a registration for the taxon concerned. The CBW program is available for species having a natural geographic distribution not including any part of the United States and other species that the Director has determined to be eligible by regulation. The individual specimens must have been born in captivity in the United States. Sections 9 and 10 of the Act also contain certain statutory exemptions from the prohibitions for certain qualifying specimens and activities.
It is our policy, as published in the
(1) Take of the Dolphin and Union caribou in its native range in Canada; and
(2) Trade in the Dolphin and Union caribou and its products that is both outside the United States and conducted by persons not subject to U.S. jurisdiction.
Based on the best available information, the following activities may potentially result in a violation of section 9 of the Act if they are not authorized in accordance with permits or exemptions under the Act; this list is not comprehensive:
(1) Import into the United States of the Dolphin and Union caribou and its products, without obtaining permits required under section 10 of the Act.
(2) Export of the Dolphin and Union caribou and its products from the United States without obtaining permits required under section 10 of the Act.
(3) Take of the Dolphin and Union caribou within the United States or on the high seas, or possess, sell, deliver, carry, transport, or ship, by any means whatsoever any such wildlife and its products that has been taken illegally.
(4) Deliver, receive, carry, transport, or ship in interstate or foreign commerce, by any means whatsoever and in the course of commercial activity; or sell or offer for sale in interstate or foreign commerce the Dolphin and Union caribou and its products.
(5) Attempt to commit, solicit another to commit, or cause to be committed, any of these prohibited acts with Dolphin and Union caribou and its products.
Separate from its listing as an endangered species, applicable wildlife import/export requirements established under section 9(d)-(f) of the Act, the Lacey Act Amendments of 1981 (16 U.S.C. 3371,
We have determined that we do not need to prepare environmental analyses pursuant to the National Environmental Policy Act (42 U.S.C. 4321
A complete list of references cited is available on
The authority for this action is the Endangered Species Act of 1973, as amended (16 U.S.C. 1531
The primary authors of this rule are the staff members of the Branch of Delisting and Foreign Species, Ecological Services, U.S. Fish and Wildlife Service.
Endangered and threatened species, Exports, Imports, Plants, Reporting and recordkeeping requirements, Transportation, Wildlife.
Accordingly, we hereby amend part 17, subchapter B of chapter I, title 50 of the Code of Federal Regulations, as set forth below:
16 U.S.C. 1361-1407; 1531-1544; and 4201-4245, unless otherwise noted.
(h) * * *
National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.
Temporary rule; commercial quota holdback.
NMFS issues this temporary rule to withhold a portion of the commercial allocation of gag for the 2023 fishing year in anticipation of an upcoming rulemaking that would amend the Fishery Management Plan for the Reef Fish Resources of the Gulf of Mexico (FMP) by implementing interim measures to reduce overfishing of gag. These interim measures would, in part, reduce the commercial sector annual catch limit (ACL) and quota. This temporary rule will withhold the distribution of gag individual fishing quota (IFQ) allocation on January 1, 2023, to shareholders in the Groupers and Tilefishes IFQ (GT-IFQ) program in the amount equal to the anticipated reduction in the commercial quota.
This temporary rule is effective from January 1, 2023, until June 1, 2023.
Dan Luers, NMFS Southeast Regional Office, telephone: 727-824-5305, email:
The reef fish fishery in the Gulf of Mexico (Gulf) includes gag and is managed under the FMP. The FMP was prepared by the Gulf of Mexico Fishery Management Council (Council) and is implemented by NMFS through regulations at 50 CFR part 622 under the authority of the Magnuson-Stevens Fishery Conservation and Management Act (Magnuson-Stevens Act).
The Gulf gag fishery is divided into commercial and recreational sectors, with a stock ACL that is allocated 39 percent to the commercial sector and 61 percent to the recreational sector. The commercial sector is managed under the GT-IFQ program and landings are constrained to the commercial quota, which is reduced from the commercial ACL. Recreational harvest is currently permitted from June 1 each year until NMFS projects that recreational landings reach the recreational ACL. If the recreational ACL is exceeded, recreational harvest is constrained the following year to the recreational annual catch target (ACT). All weights described in this temporary rule are in gutted weight.
In January 2022, NMFS notified the Council that gag is overfished and undergoing overfishing. The Council is developing an amendment to the FMP to end overfishing and rebuild the stock that NMFS expects to implement in January 2024. In July 2022, the Council sent a letter to NMFS recommending interim measures to reduce overfishing for the 2023 fishing year. These interim measures would reduce the gag catch limits and modify the recreational season. NMFS is working on a proposed temporary rule to implement the interim measures and expects any final rule implementing these measures to be effective before the current recreational season opens on June 1, 2023.
The interim measures would reduce the current commercial ACL and commercial quota from 1.217 million lb (0.552 million kg) and 939,000 lb (426,000 kg), respectively, to 258,000 lb (117,027 kg) and 199,000 lb (90,265 kg). Under the GT-IFQ program, annual quota is distributed to IFQ shareholders
NMFS notes that the interim measures recommended by the Council included a commercial quota of 199,157 lb (90,336 kg) for 2023. However, the analyses supporting the implementation of interim measures use a commercial quota rounded to the nearest thousand (199,000 lb (90,265 kg)), consistent with the format of the current gag quota. Therefore, this temporary rule withholds 740,000 lb (335,658 kg) of allocation from the current commercial quota of 939,000 lb (425,923 kg). NMFS will distribute the available allocation, including multi-use allocation, on January 1, 2023.
If NMFS does not implement the interim action and associated temporary rule by June 1, 2023, then NMFS will distribute the withheld allocation back to the current shareholders, as determined by the shares held on the same date that NMFS distributes the withheld IFQ quota.
NMFS issues this action pursuant to section 305(d) of the Magnuson-Stevens Act. This action is taken under 50 CFR 622.22(a)(4), which was issued pursuant to section 304(b) of the Magnuson-Stevens Act, and is exempt from review under Executive Order 12866, and other applicable laws.
Pursuant to 5 U.S.C. 553(b)(B), there is good cause to waive prior notice and an opportunity for public comment on this action, as notice and comment is unnecessary and contrary to the public interest. Such procedures are unnecessary because the regulation at 50 CFR 622.22(a)(4) has already been subject to notice and public comment, and the public is aware that the Council requested interim measures to reduce overfishing for the 2023 fishing year. Therefore, all that remains is to notify the public that a portion of the commercial gag allocation in 2023 will be withheld to allow for the implementation of the interim measures in 2023. Such procedures are contrary to the public interest because notice and comment would not allow NMFS to implement the interim measures to reduce overfishing for the 2023 fishing year. If NMFS does not withhold the necessary commercial gag allocation, shareholders can begin transferring or landing allocation on January 1, 2023, and NMFS would not be able to retroactively withdraw allocation from shareholder accounts.
For the reasons previously stated, the NMFS Assistant Administrator also finds good cause to waive the 30-day delay in the effectiveness of this action under 5 U.S.C. 553(d)(3).
16 U.S.C. 1801
U.S. Small Business Administration.
Proposed rule.
This rule proposes revisions to Small Business Development Centers Program (the SBDC Program or the Program) regulations to align with current policy and guidance from the U.S. Small Business Administration (SBA or the Agency) and to incorporate updates to uniform administrative requirements, cost principles, and audit requirements for Federal awards (Uniform Guidance). This proposed rule also includes policy and procedural changes identified by the Agency as necessary to preserve the integrity and legislative intent of the Program.
To be assured of consideration, written comments must be postmarked on or before February 13, 2023.
In order to ensure proper receipt, written comments must be submitted through one of the following methods only. You may submit comments, identified by RIN 3245-AE05 by one of the following methods:
•
•
Comments sent by other methods not listed above will not be accepted and subsequently, not posted. All comments submitted in response to this proposed rule will be included in the record and will be made available to the public. Duplicate comments are not considered. Please be advised that the substance of the comments and the identity of the individuals or entities submitting the comments will be subject to public disclosure. SBA will make the comments publicly available on the internet via
If you wish to submit Confidential Business Information (CBI) as defined in the user notice at
Rachel Karton, Program Manager for the SBDC Program, at 202-205-6766 or
The SBDC Program was authorized in 1980 by the Small Business Development Centers Act of 1980 (Pub. L. 96-302, 94 Stat. 833) and is currently codified in section 21of the Small Business Act, 15 U.S.C. 648 (the Act). According to the Act, the purpose of the Program is to assist in establishing SBDCs explicitly to provide “management and technical assistance” to small businesses. Section 21(a)(3)(A) requires SBA to consult with the recognized association of SBDCs in any rulemaking action for the Program.
Title II of the Small Business Development Act of 1980, authorized the SBDC Program at an initial annual funding level of $8.5 million. The new law specifically provided for Federal funding to be matched one-for-one with non-Federal funds and required an evaluation of the Program to be submitted to Congress by January 31, 1983.
SBA's Associate Administrator, Small Business Development Centers (AA/SBDC) holds statutory responsibility for the general management and oversight of the SBDC Program by means of a cooperative agreement with each recipient organization. A recipient organization is an institution of higher education or state agency which receive Federal funds to operate an SBDC. Through these recipient organizations, the SBDC Program is made available to the American public to provide small businesses and aspiring entrepreneurs with a wide array of technical assistance, strengthening business performance and sustainability, and enabling the creation of new business entities.
The SBDC Program regulations were revised in 1995,
SBA published an advanced notice of proposed rulemaking (ANPRM) was published on April 2, 2015, at 80 FR 17708, seeking comments on the development of new definitions, clarification of existing program requirements, and the renewal or termination of the notice of award. The ANPRM also solicited comments on international trade counselor certification requirements, required steps for the selection of Lead Center Directors, procedures for international travel, and procedures regarding the determination to effect suspension, termination or nonrenewal of an SBDC's cooperative agreement.
SBA received 133 comments on this ANPRM, which have been considered during the development of this proposed rule. Comments received generally fell into four categories: the role of the District Office, definitions/clarifications, client confidentiality, and the Lead Center Director hiring process. First, SBA proposes to clarify and define the role of the District Office regarding
Through the ANPRM, the Agency also sought feedback on its existing collection and use of individual SBDC client data.
This proposed rule also incorporates the Uniform Guidance at 2 CFR part 200, which streamlined and consolidated government requirements for receiving and using Federal awards to reduce administrative burden and improve outcomes. The Uniform Guidance was published in the
SBA proposes to add a paragraph providing a broad overview of the Program and purpose. SBA believes that this will provide clarity.
This section proposes to add 23 new definitions to clarify and codify current District Office responsibilities, State/Lead Center Director responsibilities, and define other terms already in use in the notice of funding opportunity.
As required in the Small Business Act, 15 U.S.C. 656 and 648(a)(1), this section proposes to add a Women's Business Center operating pursuant to section 29 of the Small Business Act as an entity eligible to apply to be a Lead Center SBDC. This section also proposes to add eligibility criteria for the Commonwealth of the Northern Mariana Islands.
This section would codify the statutory authority for the Administrator to operate and administer the SBDC Program through cooperative agreements issued to recipient organizations, as established under the Small Business Act.
This section proposes to require service centers to be primarily housed within institutions of higher education or a Women's Business Center operating pursuant to section 29 of the Small Business Act, under paragraph (c).
This section proposes to add five requirements already in use in the notice of funding opportunity as paragraphs (d) through (g) of the section to standardize SBDC naming/branding nationwide and enhance the current conflict of interest policy as follows:
• The name of the Lead SBDC must contain the official identification of “Small Business Development Center” and that, unless waived by the AA/SBDC, the SBDC has one year from the date of promulgation to make any necessary changes;
• Any entity operating as an SBDC service center, whether receiving Federal funding or not, is now considered a part of the recipient organization's network and is required to report its goals, achievements, etc. as any other service center;
• The process to obtain the minimum number of required staff members for international trade assistance as required by the Act; and
• The requirement for every SBDC to annually sign the conflict of interest form and to have a policy, which addresses how the recipient organization will deal with competing and conflicting issues.
SBA proposes to provide an overview of the services that an SBDC must provide to prospective entrepreneurs and existing small businesses and the related reporting requirements. Further, SBA proposes to require the SBDC network work with other state and local government programs providing assistance to small businesses and potential small business. This change will provide clarity and transparency to the regulations and is consistent with the notice of funding opportunity.
This section proposes to clarify the responsibilities of the AA/SBDC and the SBDC Lead Center Director (Lead Center Director). Currently, this section refers to SBA as the entity making decisions or determinations. The proposed rule would distinguish between AA/SBDC and the District Director to provide for more transparent identification of roles and responsibilities for the public.
This section would replace the words “shall” and “may” with “must” and “will” and imposes term limits and language to provide guidance to the boards, consistent with the cooperative agreement.
This section would codify the current selection process, for SBDC Lead Center Director utilized by SBDCs.
This section proposes to codify the requirements process for an SBDC to enter a contract with another Federal agency.
Section 21(a)(7) of the Act requires SBDCs and the Administration to protect the privacy of any individual or small business receiving assistance in the Program. Under this proposed rule, an SBDC, including its contractors and other agents, would not be permitted to disclose to an entity outside the individual SBDC, the name, address, email address, or telephone number, referred to as “client contact data” of any individual or small business without the consent of such individual or small business, unless such disclosure meets on the three exceptions discussed below.
The three exceptions, as authorized by the Act, would permit disclosure if: (1) a court orders the Administrator to disclose the information in any civil or criminal enforcement action initiated by a Federal or state agency; or (2) the Administrator considers such a disclosure to be necessary for the purpose of conducting a financial audit of a center, not including those required under § 130.830, as determined on a case-by-case basis when formal requests
This rule would require SBDCs to provide an opportunity for clients to opt in to allow SBA to obtain their contact data. SBA's use of client contact data would be restricted only to conduct survey and studies that help stakeholders better understand how the services the client received affect their business outcomes over time. These surveys or studies would include, but not be limited to, program evaluation and performance management studies.
Under this proposed rule, the agency would not allow use of client contact data for any other purpose beyond program surveys or studies.
This proposed rule would also prohibit the denial of services to clients solely based on a client's refusal to provide consent to use their contact data for study purposes.
Section 21(a)(7)(C) of the Act directs the Agency to publish standards for requiring disclosures of client information during a financial audit. Other Federal or state agencies making such disclosure requests would be required to submit formal requests including a justification for the need for individual client contact and/or Program activity data for the Administrator's review on a case-by-case basis. Public comments on these proposed standards are encouraged.
This proposed rule would also codify the current privacy protections in place in the Program employed by the Agency. Any reports on the Program produced by an SBDC, including its contractors and other agents, and the Agency, could not disclose individual client information without consent from the client. Any such reports could only report activity data in the aggregate, unless given consent, to protect the individual privacy of clients.
Currently, this section is not used. This section would require all SBDC applicants to comply with the current annual notice of funding opportunity procedures for their new or renewal applications to receive consideration. This proposed rule would reinforce that an SBDC applicant must follow procedures for submitting a new or renewal application, to clarify the application procedures.
Currently, this section outlines outdated procedures that are no longer enforced. This proposed rule would codify the current new application procedures utilized by SBDCs, which require applicants to be located in the same state/region where the SBDC is located. This section also proposes new recruitment and selection procedures for new recipient organizations.
Currently, this section outlines outdated procedures that are no longer enforced. This proposed rule would revise the existing renewal and nonrenewal process to reflect the process currently utilized by SBDCs. Factors of consideration in the renewal application under paragraph (c) would be expanded to include corrective measures implemented as a result of examinations conducted; and the accreditation provision of § 130.810(c), including any conditions, recommendations from the accreditation report, and corrective measures implemented, affecting the recipient organization and the SBDC network.
This proposed rule would clarify and make transparent the existing approval process of an application by outlining the options to grant approval, conditional approval, or denial of an application.
This proposed rule would codify the limitations on grant funding set forth in section 21(a)(6)(C) of the Act and the exceptions set forth under paragraph (b). The legislative language was revised in this codification to be clear and transparent.
This proposed rule would expand and clarify the requirements on matching funds for cash, in-kind, or authorized indirect funds so that it is clearer and more transparent.
Under this proposed rule, paragraph (c) would be added to clarify matching requirements for insular territories.
Paragraph (d) would codify the requirement for all applicants to submit a certification of cash match and program income, currently required by the notice of funding opportunity.
Paragraph (e) would require all matching funds, in addition to the Federal and Program income funds, to be under the direct management of the SBDC State/Region Director.
Paragraph (g) would expand the list of unallowable sources of matching funds.
This section proposes to add the current budget justification procedures used by SBDCs, as required by the notice of funding opportunity. In accordance with 2 CFR part 200, the SBDC would be required to have the prior approval from the Agency for the purchase of equipment, either through a specific disclosure in an annual cost proposal or through an approved amendment to an existing cooperative agreement.
This proposed rule would also outline procedures for foreign travel requests. Specifically, all foreign travel requests would be required to be submitted to the appropriate District Director and the Office of Small Business Development Centers (OSBDCs) Program Manager for review and then to the AA/SBDC for final approval.
Paragraph (i) would be revised to allow dues to the recognized association to be charged to the cooperative agreement.
Under this proposed rule, this new section would prohibit the use of Federal funds, matching funds and program income as required under the cooperative agreement for the purposes identified as unallowable in applicable sections of 2 CFR part 200. Currently regulations do not restrict the use of these above cited funds. These proposed changes, in accordance with 2 CFR part 200, would ensure that program funds are not used by recipient organizations for the purpose of sub-grants, or as seed money for venture capital, or for other purposes outside the scope of authorized SBDC activities.
This section proposes to prohibit SBDC network entities, staff, consultants, or volunteers to solicit or accept fees or other compensation for counseling services, including, but not limited to, business or marketing plan development, loan packaging or credit application assistance, or other advisory services described in the Act. SBA proposes to add a second paragraph to codify, clarify and make more transparent the intent of the section.
This section proposes to codify the existing requirement that SBDCs may not report program income as a matching resource. Further, unused program income is permitted to be carried over to the subsequent budget period by the SBDC network; however, the aggregate amount of network
This rule proposes to create a new section to require the SBDCs to adopt and implement the respective Office of Management and Budget (OMB) guidelines for property standards.
Current regulations outline the process for SBDC submission of reimbursement requests and advancements. Under this rule, the language of this section is revised to provide clarity and transparency. The intent of the section remains the same.
Currently, this section is not used. This section proposes to codify program requirements currently enforced through the notice of funding opportunity and followed by the SBDCs.
Under this proposed rule, paragraph (a) would require that a recipient organization will incorporate the cooperative agreement into its SBDC sub-agreements and contracts, which is already being done by the SBDCs.
Paragraph (b) would clarify that SBA will not direct or otherwise approve any sub-agreements entered by the recipient organization with service centers, vendors, or contractors.
Paragraph (c) would outline procedures for developing performance goals and measurements, negotiating the goals and measurements, and consequences of not meeting those goals and measurements. Also, SBA loan goals would not be negotiated or incorporated into the cooperative agreement without the written approval of the AA/SBDC.
Paragraph (d) would outline contracting procedures and require SBDCs to follow the related guidelines set forth in 2 CFR part 200.
This section proposes to add new paragraphs (b) and (c) for clarification and transparency. Paragraph (b) proposes to codify 2 CFR part 200 requirements applicable to grant administration and cost principles for both the recipient organizations and service center organizations.
Paragraph (c) would codify SBA's authority to propose additional requirements, beyond those set forth in both the uniform grant administrative requirements and cost principles, where necessary to ensure the effective and efficient management of the SBDC Program.
This section proposes to revise paragraph (a) by outlining required prior approval requests by SBDCs for revisions to the cooperative agreement and add a new paragraph (b) for clarity and transparency. As is current practice, paragraph (b) would authorize the AA/SBDC to amend one or more cooperative agreements to authorize unanticipated out-of-state travel by SBDC personnel responding to a need for services in a Presidentially Declared Major Disaster Area and to address how travel costs are to be handled. Paragraph (b) would authorize SBA to provide financial assistance to SBDCs, or any proposed consortium of such individuals or entities, to spur disaster recovery and growth of small business concerns located in an area for which the President has declared a major disaster.
This section proposes to clarify the existing procedures for a financial dispute or a programmatic or non-financial dispute for clarity and transparency. The intent of this section remains the same.
This section proposes to revise and clarify the procedures for suspension, termination or non-renewal for clarity and transparency. Under this proposed rule, paragraphs (b)(11) through (15) would be added for efficiency and transparency.
Paragraph (a)(1) would clarify the current termination process of an SBDC. Under this proposed rule, the termination would be immediately enforced on of the date of the notice of termination. The recipient organization would not incur further obligations under the cooperative agreement after the date of termination, unless otherwise expressly stated to do so. The award funds would not be available for obligations incurred after the effective date of termination, unless expressly authorized under the notice of termination. The recipient organization would have 120 days to submit final closeout documents to SBA.
Paragraph (a)(2) would allow the recipient organization to continue to conduct project activities and incur allowable expenses until the end of the current budget period in instances when the SBA has elected to not to renew a cooperative agreement. Under this proposed rule, if a recipient organization does not seek to renew the grant, it must notify the District Office and send a letter of intent to withdraw to the AA/SBDC.
Paragraph (a)(3) would add the sentence, “A decision to suspend a cooperative agreement is effective immediately.” Under this proposed rule, the notice of suspension would recommend that the recipient organization cease work on the project immediately and would place SBA under no obligation to reimburse any expenses incurred by a recipient organization while it is under suspension.
Under this proposed rule, paragraph (b)(11) through (15) would be added for clarity and transparency on the causes for termination or suspension.
Currently the administrative procedure for suspension, termination, and non-renewal is found in the cooperative agreement. Under this proposed rule, the new administrative procedures are outlined under paragraph (c) as well as the responsibilities of the AA/SBDC in these circumstances.
Under this proposed rule, paragraph (d) is added to outline the administrative review of suspension, termination, and non-renewal actions as well as the required process for SBDCs to submit the request for administrative review.
This section would be revised to clarify the existing broad language used to outline program oversight requirements by adding three new paragraphs.
This rule proposes to revise paragraph (c) to reiterate 15 U.S.C. 648(k)(2) of the Small Business Act and proposes to state that SBA may not renew or extend any cooperative agreement with an SBDC unless the center has been approved under the accreditation program, except that the AA/SBDC may waive such accreditation requirement, at their discretion, upon showing that the center is making a good faith effort to obtain accreditation. This section proposes to clarify and provide more detail on the review authority provided to SBA regarding the SBDC Program.
This rule proposes to revise the existing broad instructions on records and recordkeeping requirements for an SBDC to provide clarity and transparency. The proposed revisions include more narrow instructions to clarify each required step in the current process.
This rule proposes to require SBDCs to submit performance and financial reports to SBA for review, as currently required by the notice of funding opportunity. The proposed revisions outline the frequency of the reporting, electronic data reporting which includes counseling and training records, and specific details for each of the performance reports and financial reports.
Current regulations provide general but outdated, compliance instructions to the SBDCs regarding audits and investigations performed by SBA's Office of Inspector General. This section would be updated and revised with more specific and clear instructions.
Current regulations do not include closeout procedures; rather, these are found in the cooperative agreement. Under this proposed rule, this new section would be added to outline closeout procedures for the recipient organization to ensure that program funds and property acquired or developed under the SBDC cooperative agreement are fully reconciled and transferred seamlessly between recipient organizations, service centers, or other Federal programs.
SBA invites interested persons to submit written comments on this proposed rule. Your written comments on the proposed rule should be specific, should be confined to issues pertinent to the proposed rule, and should explain the reason(s) for any change you recommend or proposal(s) you oppose. Where possible, you should reference the specific section or paragraph of the proposal you are addressing. We invite specific comments on various aspects of the rule as described in this preamble.
Readers are encouraged to closely review each section of the proposed rule in conjunction with current regulations to fully comprehend the extent of the rule and its changes. SBA invites comment on all aspects of this proposed rule, including the underlying policies. Submitted comments will be viewable on Regulations.Gov by searching under the Docket Number (SBA-2015-0005) or the Regulation Identifier Number (RIN 3245-AE05).
The Office of Management and Budget (OMB) has determined that this proposed rule is a ”significant” regulatory action for the purposes of Executive Order (E.O.) 12866. Accordingly, the next section contains SBA's Regulatory Impact Analysis.
The SBDC rules were last revised in 1995 (
SBA believes it is now necessary to revise the regulations to outline current policies and procedures for the SBDC Program for consistency. This proposed regulation also incorporates the changes required by the 2 CFR part 200 and other grant changes that have taken place over the last 25 years. Additionally, the America's Small Business Development Centers (ASBDC), the recognized association as established in section 21(a)(3)(A), has requested changes that are consistent with the revisions made in the notice of funding opportunity and cooperative agreement. Furthermore, the SBA received 133 comments to the ANPRM that was published on April 2, 2015, some of which are incorporated in this proposed rule.
In the absence of this rule, there would be inconsistency between the regulations and Program governing documents, including the notice of funding opportunity and the cooperative agreement. Currently, SBA and the SBDCs reference three or more documents to find guidance on the Program, and the annual notice of funding opportunity and cooperative agreement have become, for all practical purposes, documents which interpret the statute. Also, SBA has limited authority to hold SBDCs accountable for low or non-performance. While low or non-performance is a rare occurrence, SBA's only current recourse is to write conditions into the SBDC notice of award. The proposed rule would strengthen SBA's oversight and accountability, as intended by Congress, and reduce burden by consolidating programmatic guidance to one document.
The potential benefits of this proposed rule are based on incorporating all the changes that have been made with the publication 2 CFR part 200, other grant changes over the past 20 years, and a streamlining of both the notice of funding opportunity and the cooperative agreement. Specifically, the rule provides guidance on the determination of the official name of the SBDC; directs minimum reporting for, and hiring of, State Directors; applying for other grants/other sources of funds; clarifies Project Officer responsibilities; clarifies matching funds, such as in-kind funds; funding expenditures; eligible entities budget justification; provides guidance regarding the collection and use of individual SBDC client data; adds new sections regarding suspension, termination, and non-renewal, payments and reimbursements, property standards, confidential information—among others.
The new regulations will simplify and streamline notice of funding opportunity language to contain only that information that the applicant organization must submit and not all the other information that will now be written into the regulations. Moreover, having the regulations in one document would make administering the Program by the SBDCs much easier by not having to reference three or more different documents. The estimated reduction in burden to this consolidation is presented in the table below:
There are currently 62 SBDCs that would benefit from this new regulation. We estimate the changes to the rule will create a four-hour benefit per SBDC from better information leading to better SBDC choices because the revisions will clarify definitions and provide guidance on various issues. We estimate a two-hour increase in efficiency per SBDC from the clarity that the revisions to the rule will provide because the rule will be in agreement with the notice of funding opportunity and the cooperative agreement, leading to less confusion and streamlined processes due to consolidation of programmatic guidance. Using the average hourly wage of an SBDC State Director, the total annual benefit of these revisions comes to $44,722 for all the 62 SBDCs. We anticipate that these benefits will be realized over perpetuity in that SBDCs will continue to experience better decision-making from the clarification and additional guidance provided and increased efficiency from only having to reference one document.
There are also several benefits that cannot be quantified. One of these benefits is the increased security that the rule provides SBDCs through its requirements to protect the privacy of an individual or small business receiving assistance in the Program. Another benefit to revising and updating the regulations is that it would give SBA more authority to enforce the requirements as written in the regulations which is something currently lacking in the Program.
There are some costs incurred by the SBDCs in initially reading and interpreting the new regulation. There is an additional requirement for application procedures which currently only exists in the notice of funding opportunity. We estimate that this will add approximately two hours of burden for SBDCs. The SBDCs also must provide a certification of cash match and program income for which a requirement currently exists only in the notice of funding opportunity. Additionally, the rule would require SBDCs to submit performance and financial reports to SBA for review, as currently required by the notice of funding opportunity. These requirements are reflected in the most recent Information Collection Requests for the reporting requirements for SBDCs, so while reflected here, these requirements do not change the Paperwork Reduction Act cost burden. SBA staff must review these reporting requirements which we estimate will take SBA staff 30 minutes twice a year to review. These costs are summarized below:
The undiscounted schedule of benefits and costs over the first three years of the rule (with the values in year three to continue in perpetuity) are presented in the following table:
The annualized net savings of this proposed rule is $20,640 with a 7 percent discount rate, assuming annual savings of $44,722 in perpetuity and costs in the first year of $38,015 and afterwards costs of $23,107, in perpetuity.
SBA considered two alternatives to this rulemaking. First would be using internal SBA guidance, such as Standard Operating Procedures (SOPs), to interpret existing rules. SBA also considered continued interpretation of program requirements through the cooperative agreement negotiation process. However, under the applicable statute, SBA must consult with the ASBDC when developing “documents: (i) announcing the annual scope of activities pursuant to this section, (ii) requesting proposals to deliver assistance as provided by this section, and (iii) governing the general operations and administration of the Small Business Development Centers (SBDC) Program, specifically including the development of regulations and a uniform negotiated cooperative agreement for use on an annual basis when entering into individual negotiated agreements with small business development centers” (15 U.S.C. 648(a)(3)(A)).
In addition to this consolidation requirement, SBA values the input of the public. The rulemaking process would provide an opportunity for both the ASBDC and the public to comment on changes made to the Program. SBA also identified a need to streamline changes made to the notice of funding opportunity and cooperative agreement, and any changes in Federal grant procedures, since the Program regulations were last revised. Since this proposed rule is an all-encompassing revision of the current regulations, SBA does not believe that more extreme changes could be made at this time. Also, this statute specifically includes a direction for SBA to develop regulations for the SBDC Program with the ASBDC and SBDCs. For these reasons, SBA believes that proceeding with a rulemaking is the best approach to revise SBDC Program requirements at this time.
The changes proposed for this rule will not negatively affect access to the Program for small businesses or nascent entrepreneurs. All small business and nascent entrepreneurs will continue to have access to the full services provided by the SBDCs. In fact, there will be a de minimis cost savings realized by SBDCs because they will not have to reference multiple documents for guidance and the guidance in the rule will be more beneficial to SBDCs. There are also some non-quantifiable benefits such as increased privacy and the ability for SBA to enforce the requirements laid out in the rule. SBA invites comment from the public on the costs or savings assumed in this analysis.
The changes proposed for this rule will not negatively affect access to the Program for small businesses or nascent entrepreneurs. All small business and nascent entrepreneurs will continue to have access to the full services provided by the SBDCs. In fact, there will be a de minimis cost savings realized by SBDCs because they will not have to reference multiple documents for guidance and the guidance in the rule will be more beneficial to SBDCs. There are also some non-quantifiable benefits such as increased privacy and the ability for SBA to enforce the requirements laid out in the rule. SBA invites comment from the public on the costs or savings assumed in this analysis.
Executive Orders (E.O.s) 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). E.O. 13563 emphasizes the importance of quantifying both costs and benefits, of reducing costs, of harmonizing rules, and of promoting flexibility. It is anticipated that this rule will not be a significant regulatory action and, therefore, was not subject to review under Section 6(b) of E.O. 12866, Regulatory Planning and Review, dated September 30, 1993.
As required by the Congressional Review Act (5 U.S.C. 801-808) before an interim or final rule takes effect, Department of Defense (DoD), General Services Administration (GSA), and National Aeronautics and Space Administration (NASA) will send the rule and the “Submission of Federal Rules Under the Congressional Review Act” form to each House of the Congress and to the Comptroller General of the United States. A major rule cannot take effect until 60 days after it is published in the
This action meets applicable standards set forth in sections 3(a) and 3(b)(2) of Executive Order 12988, Civil Justice Reform, to minimize litigation, eliminate ambiguity, and reduce burden. The action does not have retroactive or preemptive effect.
There are seven recipients that are grantees of the SBDC Program that are hosted by state economic development organizations. They are Colorado, Illinois, Indiana, Minnesota, Montana, Ohio, and West Virginia. All other grantees are hosted by institutions of higher education. This rule imposes no additional or special burdens on the state-based SBDCs. As mentioned above the grantees are currently abiding by these proposed regulations and 2 CFR part 200 as the requirements are already in the notice of funding opportunity and cooperative agreement. The recipient organizations apply or volunteer to participate in the Program and can withdraw at any time.
SBA has determined that this proposed rule will not have substantial, direct effects on the states, on the relationship between the National Government and the states, or on the distribution of power and responsibilities among the various levels of government. Therefore, for the purposes of Executive Order 13132, SBA has determined that this proposed rule has no federalism implications warranting preparation of a federalism assessment. However, SBA invites comments on issues relating to the federalism aspects of this proposed rule.
SBA has determined that this proposed rule would not impose additional reporting and recordkeeping requirements under the Paperwork Reduction Act (PRA). Currently, there
When an agency issues a rulemaking proposal, the Regulatory Flexibility Act (RFA) requires the agency to prepare an Initial Regulatory Flexibility Analysis (IRFA) describing the economic impact that the proposed rulemaking may have on small entities. Section 605 of the RFA allows an agency to certify a rule, in lieu of preparing an analysis, if the rulemaking is not expected to have a significant economic impact on a substantial number of small entities.
The proposed rule revises regulations to outline current policies and procedures for the SBDC Program. Specifically, the proposed rule will clarify and define the role of the District Office regarding cooperative agreement oversight activities by adding definitions and procedures throughout the proposed regulations. Second, SBA proposes to add 23 definitions that refine and explain various roles, procedures, documents, and categories of funding and proposes to revise other definitions for clarification. Third, a section is proposed to be added to codify SBDC client confidentiality. Finally, the current process of hiring a State/Region Director is outlined in an SBA policy notice; however, the proposed regulation proposes to codify and refine this process. Most of these proposed changes are already implemented by the SBDCs, and these proposed regulations are codifying them.
The proposed rule will impact 62 SBDCs that primarily fall into the North American Industry Classification System (NAICS) codes 611210 (junior colleges) and 611310 (colleges, universities, and professional schools). In addition, seven SBDCs are hosted by state economic development organizations, such as state Departments of Trade or Commerce.
A junior college is considered small if its annual receipts are $28.5 million
The purpose of the rule is to codify existing practices and to provide consistency between regulations and the Program's governing documents and practices. The Regulatory Impact Analysis presented earlier describes the costs and savings of the rule and the small net savings relative to the number of entities. Accordingly, the Administrator of the SBA, hereby, certifies to the Chief Counsel of Advocacy of SBA that this rule will not have a significant economic impact on a substantial number of small entities. SBA invites comment from the public on this certification.
The Administrator may authorize an SBDC to provide advice, information, and assistance, as described in subsection (c) of the Small Business Act, to a small business concern located outside of the state, without regard to geographic proximity to the small business development center, if the small business concern is located in an area for which the President has declared a major disaster.
The Administrator may provide financial assistance to an SBDC, a Women's Business Center described in section 29 of the Small Business Act, SCORE, or any proposed consortium of such individuals or entities to spur disaster recovery and growth of small business concerns located in an area for which the President has declared a major disaster.
Grant programs—business, Small businesses, Technical assistance.
For the reasons stated in the preamble, the Small Business Administration proposes to amend 13 CFR part 130 as follows:
15 U.S.C. 634(b)(6), 648, and 648 note.
(a)
(b)
(c)
The additions and revisions read as follows:
(1) Is used to enter into a relationship the principal purpose of which is to transfer anything of value from the Federal awarding agency or pass-through entity to the non-Federal entity to carry out a public purpose authorized by a law of the United States (see 31 U.S.C. 6101(3)); and not to acquire property or services for the Federal Government or pass-through entity's direct benefit or use.
(2) Is distinguished from a grant in that it provides for substantial involvement between the Federal awarding agency or pass-through entity and the non-Federal entity in carrying out the activity contemplated by the Federal award.
(3) The term does not include:
(i) A cooperative research and development agreement as defined in 15 U.S.C. 3710a; or
(ii) An agreement that provides only:
(A) Direct United States Government cash assistance to an individual;
(B) A subsidy;
(C) A loan;
(D) A loan guarantee; or
(E) Insurance.
(4) Is a negotiated legal agreement between SBA and a recipient organization containing the terms and conditions under which SBA provides Federal funds for the performance of SBDC activities.
The additions and revision read as follows:
(e) A Women's Business Center operating pursuant to section 29 of the Small Business Act (15 U.S.C. 656);
(f) The Commonwealth of the Northern Mariana Islands SBDC must have its principal office located in the Commonwealth of the Northern Mariana Islands (CNMI) and must:
(1) Be a CNMI government or agency;
(2) Be a regional entity;
(3) Be a CNMI-chartered development, credit, or finance corporation;
(4) Be an institution of higher education (including but not limited to any land-grant college or university, any college or school of business, engineering, commerce, or agriculture, community college or junior college);
(5) Be a current SBA Women's Business Center (WBC); or
(6) Be any entity formed by two or more of the entities in paragraphs (f)(1) through (5) of this section;
(h) Any entity operating continually as a recipient organization on or before December 31, 1990.
The Small Business Development Center Program is established under the statutory authority of the Small Business Act (15 U.S.C. 648) and administered through cooperative agreements issued to recipient organizations.
(a) The AA/SBDC will designate, in the cooperative agreement, the geographic area of service of each recipient organization. Generally, no more than one recipient organization may be located in a state.
(1) The AA/SBDC may determine that making awards to multiple recipient organizations in a state is necessary to more effectively implement the Program and provide services to all interested small businesses.
(2) Once the Administration has entered into a cooperative agreement, a subsequent decision to change the recipient organization's area of service will be considered a non-renewal or termination. This decision will be subject to the procedures outlined in § 130.700.
(b) The recipient organization must locate its Lead Center and SBDC service centers in the designated area of service to ensure that services are readily accessible to all small businesses within the designated area of service.
(c) The recipient organization must ensure that any new SBDC service centers established within its area of service are primarily housed within institutions of higher education or a Women's Business Center (WBC) operating pursuant to section 29 of the Small Business Act (15 U.S.C. 656) as stated in section 21(a)(1) of the Small Business Act (15 U.S.C. 648(a)(1).
(d) The allocation of resources, including site locations of the Lead Center and the SBDC service centers, will be reviewed for adequacy of coverage by SBA as part of the application review process for each budget period.
The revisions and additions read as follows:
(a) The recipient organization has the contractual responsibility for performing the duties of the Lead Center in accordance with the cooperative agreement. The Lead Center must be an independent department within the recipient organization, having its own staff, including a full-time SBDC Director.
(b) * * * The Lead Center must conduct and document annual financial and programmatic reviews and evaluations of its SBDC service centers consistent with § 130.820(a).
(c) The Lead Center's and SBDC service center's services shall be available to the public throughout the year during the normal hours of the business community. In addition, every effort should be made to provide assistance, including during non-business hours, both in-person and virtually, as appropriate, to meet local community business demands and needs. Variations from these schedules or other anticipated closures will be included in the new or annual renewal application. Emergency closures will be reported to the SBA District Office as soon as is feasible.
(d) The specific identification “Small Business Development Center” must be a part of the official name of every SBDC Lead Center and SBDC service center within the SBDC network, unless waived by the AA/SBDC.
(e) Any entity operating as an SBDC service center, whether receiving Federal funding or not, is considered a part of the recipient organization's network and as such the recipient organization is required to report to the OSBDC each SBDC service center's performance as well as any funds or program income generated by the activities of that entity.
(f) An SBDC network may seek the designation as a Small Business Technology Development Center in accordance with the recognized association's accreditation program. An SBDC network proposing to use the identification “Small Business Technology Development Center” must follow the recognized association procedures, obtain the written
(g) Each SBDC must maintain a minimum number of export and trade certified counselors to assist clients develop export and international trade opportunities. The standard for establishing the number of counselors required to have this certification is based on the total number of full-time equivalent (FTE) counseling employees in an SBDC's network. The minimum number of certified counselors for an SBDC network is the
(1) Five counselors; or
(2) Ten percent of the total number of FTE counselors in the network.
(h) The Lead Center and all its SBDC service centers must implement and have in effect at all times, a uniform and enforceable conflict of interest policy applicable to all SBDC employees, contractors, consultants, and volunteers and signed annually. At a minimum, this policy must be consistent with the conflict of interest principles set forth in 2 CFR 2701.112.
(i) The SBDC network will comply with 13 CFR parts 112, 113, 117, and 136 requiring that no person, on the grounds of race, color, handicap, marital status, national origin, race, religion, or gender, be excluded from participation in, be denied the benefits of, or otherwise be subjected to discrimination under any program or activity conducted by the SBDC network.
The revisions and addition read as follows:
(a)
(b) * * *
(2) SBDCs may provide loan packaging services to SBDC clients free of charge as stated in § 130.470.
(3) SBDCs should prepare their clients to represent themselves to lending institutions. SBDCs may attend meetings with lenders to assist clients in preparing financial packages; however, neither SBDC staff nor their agents may take a direct or indirect role in representing clients in loan negotiations.
(4) SBDCs should disclose to their clients that financial counseling assistance, including loan packaging, will not guarantee receipt of or imply approval of a loan or loan guarantee.
(5) SBDCs may not make loans, intervene in loan decisions, service loans, make credit recommendations or influence decisions regarding the award of any loans or lines of credit on behalf of the SBDC's clients, including having SBDC personnel serve on panels or boards that review loan applications.
(6) With respect to SBA loan guaranty programs, SBDCs may accompany an applicant organization appearing before SBA or a lender but may not advocate, recommend approval or otherwise attempt in any manner to influence SBA or a lender to provide financial assistance to any of its clients.
(c)
(d)
(a)
(b)
(c)
(2) The SBDC Lead Center Director position must have direct reporting authority, at a minimum, equivalent to that of a college dean in a university setting or the third level of management or administration within a state agency.
(3) The Lead Center Director will direct and monitor program activities and financial affairs of the SBDC network to ensure effective delivery of services to the small business community, and compliance with applicable laws, regulations, 2 CFR part 200, and the terms and conditions of the cooperative agreement.
(4) The SBDC Lead Center Director must have the authority necessary to control all personnel, budgets, and expenditures under the cooperative agreement.
(5) The SBDC Lead Center Director will serve as the SBA's principal contact for all matters involving the SBDC network including, but not limited to, ensuring that state and local needs are
The revisions and additions read as follows:
(a) * * *
(2) This advisory board will be referred to as a State SBDC Advisory Board in a state/territory having only one recipient organization, and a Regional SBDC Advisory Board in a state having more than one recipient organization.
(3) These advisory boards must consist of representatives from small businesses or associations representing small businesses. Membership must be derived from the entire area of service.
(4) New Lead Centers must establish a State or Regional SBDC Advisory Board by the beginning of the second project period.
(6) The reasonable cost of travel of any Board member for official Board activities will be paid out of the SBDC's budgeted funds. Federal and program funds are not to be used to compensate advisory board members for non-travel related expenses such as time and effort.
(b) * * *
(1) The SBA will establish a National SBDC Advisory Board comprised of members who are not Federal employees, appointed by the SBA Administrator. The Board will elect a chairperson. Three members of the Board will be from universities, or their affiliates and the remainder will be from small businesses or associations representing small businesses. Board members will serve staggered 3-year terms. The SBA Administrator may appoint successors to fill unexpired terms.
(3) The reasonable cost of travel of any National SBDC Advisory Board member for official Board activities will be paid by SBA out of SBDC line-item program funds.
(4) Each member of the Board will be entitled to be compensated at the rate not in excess of pay for individuals occupying the position under GS-15 of the General Schedule for each day engaged in activities of the Board and shall be entitled to be reimbursed for expenses as a member of the Board.
(5) The Board will meet at least semiannually and at the call of the Chairman of the Board.
(a)
(b)
(i) Being notified by the incumbent SBDC Lead Center Director of their intent to vacate the position; or
(ii) Its formal decision to remove the incumbent SBDC Lead Center Director.
(2) If the position will be vacated prior to the selection of a replacement, the recipient organization must appoint an interim SBDC Lead Center Director, prior to the vacancy, who will serve in that capacity until a permanent SBDC Lead Center Director is in position.
(3) The recipient organization must inform the SBA District Director, Regional Administrator, and the AA/SBDC within 10 business days of the appointment of the interim SBDC Lead Center Director and provide that individual's contact information.
(4) An interim Lead Center Director must allocate at least 75 percent of their time and effort to the SBDC Program until a permanent SBDC Lead Center Director is in position. This must be documented in accordance with the policies of the recipient organization. An interim SBDC Lead Center Director must be knowledgeable about sponsored programs. The appointment period for such interim SBDC Lead Center Director will not exceed 120 days. Should more time be needed the recipient organization must obtain prior approval from the AA/SBDC for an extension.
(a) An SBDC Lead Center or SBDC service center organization may enter into a contract or grant with a Federal department or agency to provide specific assistance to small business concerns in accordance with paragraphs (b) and (c) of this section.
(b) Prior to bidding on a non-SBA Federal award or contract, the SBDC Lead Center or service center must obtain written consent from the AA/SBDC or designee regarding the subject and general scope of the award or contract to ensure that performance under the award or contract does not represent a conflict with the SBA's cooperative agreement.
(c) Federal funds from other Federal programs (except for certain Community Development Block Grant program funds) may not be counted as match for purposes of the SBDC Program. In addition, match expenditures reported to the SBA under the cooperative agreement may not be used or reported as match for another Federal program.
(a) SBDCs, including their contractors and other agents, are not permitted to disclose the Client's name, address, email address, or telephone number, hereafter referred to as “client contact data,” of individuals or small businesses that obtain any type of assistance from the Program to any person or entity other than the SBDC, without the consent of the client, except in instances where:
(1) Court orders require the SBA Administrator to do so in any civil or criminal enforcement action initiated by a Federal or state agency;
(2) The Administrator considers such a disclosure to be necessary for the purpose of conducting a financial audit of a center, not including those required under § 130.830, as determined on a case-by-case basis when formal requests are made by a Federal or state agency. Such formal requests must justify and document the need for individual client contact and/or program activity data to the satisfaction of the Administrator; or
(3) SBA requires client contact data to directly survey SBDC clients.
(b) SBDCs must provide an opportunity for a client to opt-in to allow the SBA to obtain client contact data. The SBA may use the permitted client contact data only to conduct surveys or studies that help stakeholders better understand how the services the client received affect their business outcomes over time. These surveys or studies would include, but not be limited to:
(1) Studying evaluation and performance management;
(2) Measuring the effect and economic or other impact of Agency programs;
(3) Assessing public and SBDC partner needs;
(4) Measuring customer satisfaction;
(5) Guiding program policy development;
(6) Improving grant-making processes; and
(7) Other areas SBA determines would be valuable to strengthen the SBDC Programs and/or enhance support for SBDC clients.
(c) SBDCs may not deny access to services to clients solely based on their refusal to provide consent as referenced in this section.
(d) Any reports or studies on program activity produced by SBDC and/or the Administrator, including their contractors and other agents, may not disseminate client contact data and must only report data in the aggregate. Individual client contact data will not be disclosed in any way that could individually identify a client.
(e) SBDCs and the Administrator, including their contractors and other agents, must obtain consent from the client prior to publishing media or reports that identify an individual client.
(f) This section does not restrict the Agency in any way from access and use of program performance data.
All SBDC applicants must comply with the annual notice of funding opportunity, including format, conditions, submission requirements, and due dates, for their new or renewal application to receive consideration.
(a)
(b)
(c)
(2) After completion of an objective review process, the AA/SBDC will make the final selection and notify the successful applicant.
(3) The newly selected recipient organization may, with prior written approval from the SBA, incur qualified pre-award matching expenditures for the establishment of the Lead Center office, to recruit Lead Center staff, and to cover other related start-up expenditures to the extent permitted under 2 CFR 215.25(e)(1).
(a) The recipient organization will submit the renewal application to OSBDC using the submission process outlined in the annual notice of funding opportunity.
(b) If the OSBDC chooses to not renew the award of an existing recipient organization or the recipient organization elects not to reapply, the OSBDC will award a cooperative agreement for the conduct of an SBDC project to a new recipient organization in the same area of service using a competitive process. If the OSBDC has initiated a non-renewal or termination action, the Agency will not issue the new award until all administrative remedies have been exhausted. For further information regarding the termination and non-renewal procedures, see § 130.700.
(c) Significant factors considered in the renewal application review will include:
(1) The applicant's ability to obtain matching funds;
(2) The quality of prior performance under the cooperative agreement;
(3) The results of any examination conducted pursuant to § 130.810(b);
(4) Corrective measures implemented as a result of examinations conducted; and
(5) The accreditation provisions of § 130.810(c) including any conditions, accreditation report recommendations, and corrective measures implemented, affecting the recipient organization and the SBDC network.
(d) The OSBDC will review the renewal application for conformity with the notice of funding opportunity. The AA/SBDC may request additional information and documentation prior to issuing the cooperative agreement.
(a) New applications will either be accepted or rejected in accordance with the evaluation criteria set forth in the applicable notice of funding opportunity. The AA/SBDC may approve, or conditionally approve, or deny any new application. The AA/SBDC may approve or conditionally approve or deny a renewal application. The AA/SBDC may also reject a renewal application after following due process in accordance with the procedures set forth in § 130.700. If a renewal application is conditionally approved, the requirements that the recipient organization must meet in order to obtain full and unconditional approval, will be specified as special terms and conditions in the cooperative agreement.
(b) In the event of a conditional approval, the SBA may fund a recipient organization for one or more specified periods of time up to a maximum of one budget period. If the recipient organization fails to comply with the special terms and conditions of the award to the satisfaction of the AA/SBDC within the allotted time period, the AA/SBDC may suspend, non-renew, or terminate the cooperative agreement with the SBDC, in accordance with the procedures set forth in § 130.700.
(a) No recipient organization will receive an SBDC grant, in any fiscal year under a cooperative agreement, exceeding the greater of the minimum statutory amount, or its pro rata share of all SBDC grants as determined by the statutory formula set forth in section 21(a)(4)(C) of the Small Business Act (15 U.S.C. 648(a)(4)(C)). This limit does not apply to the distribution of supplemental funds, or to grants provided pursuant to sections 21(a)(4)(C)(viii) and 21(a)(6) of the Small Business Act (15 U.S.C. 648(a)(6)).
(b) Additional grants are subject to the limitations set forth in section 21(a)(6) of the Small Business Act unless the statute providing for the additional grant states otherwise.
The additions and revisions read as follows:
(a) * * * Cash match must equal at least 50 percent of the SBA funds used by the SBDC. * * *
(b) * * * Any additional requirements, specifications, or deliverables must be clearly identified in the budget narrative. * * *
(c) Under the authority of 48 U.S.C. 1469a(d), the AA/SBDC may, at his/her discretion, waive any requirement of matching funds for an insular territory otherwise required by law to be provided. Notwithstanding any other provision of law, in the case of American Samoa, Guam, the Virgin
(d) All applicants must submit a certification of cash match and program income. This certification must be executed by an authorized official of the recipient organization and must identify any SBDC service center organization(s) providing cash match under a subcontract or other agreement.
(e) In addition to the Federal and program income funds, all matching funds must be under the direct management of either the SBDC Lead Center Director or an SBDC Service Center Director, when budgeted under an SBDC service center organization.
(f) The Grants Management Specialist will determine whether matching funds and cash match set forth in the budget proposal are sufficient to issue the cooperative agreement.
(g) Overmatched amounts are funds that are contributions of non-Federal cash and of non-cash resources for authorized SBDC activities in excess of the statutorily required match.
(1) Recipient organizations are encouraged to identify overmatched amounts as part of the cooperative agreement. The recipient organization must fully identify the amount and sources of claimed overmatched amounts. If overmatched amounts are reported, they are subject to the provisions of the cooperative agreement and SBA biennial programmatic and financial examinations.
(2) An overmatched amount can be applied as matching funds for any funding increase (
(3) Allowable overmatched amounts which have not been used in the manner described in this section may, with the approval of the AA/SBDC, be used as a credit to offset any confirmed audit disallowances applicable only to the budget period in which the overmatched amount exists and the two previous budget periods. Such offsetting funds shall be considered matching funds.
(h) The following sources cannot be used as matching funds for the SBDC network:
(1) Uncompensated student labor;
(2) SCORE, SBA, Women's Business Centers, or other SBA resource partners;
(3) Program income or fees collected from individuals or small businesses receiving assistance;
(4) Federal funds other than Community Development Block Grant (CDBG) funds;
(5) In-kind contributions, or indirect costs not solely dedicated to the SBDC Program, or under its control;
(6) Any resource allocated and claimed as a matching cost to another federally funded program; or
(7) Funds or other resources provided for an agreed upon scope of work inconsistent with the authorized activities of the SBDC Program.
(a)
(b)
(c)
(1) Twenty percent of Federal contribution; or
(2) The amount remaining after the waived portion of indirect costs is deducted from the total indirect costs allowed by the SBA.
(d)
(1) Negotiated with the SBA Project Officer; or
(2) Apply the OMB de minimis rate.
(e)
(f)
(g)
(2) Salaries for Lead Center Directors should be comparable to salaries paid Lead Center Directors in other states or regions with comparably sized programs, responsibilities, and authority.
(3) Salaries for all other positions within the SBDC should be based upon level of responsibility and be comparable to salaries for similar positions in the area served by the SBDC.
(h)
(i)
(2) The cost of all proposed travel must be equal to or less than the rate for coach class, apply directly to the specific work of the SBDC, be incurred in the normal course of program administration, and conform to the written travel policies, including per-diem rates, of the recipient organization or the sponsoring SBDC organization. (Per diem rates, including lodging, will not exceed those authorized by the recipient organization.)
(3) Transportation costs must be justified in writing, including the estimated cost, number of persons traveling, and the benefit to be derived by the small business community from the proposed travel.
(4) Any proposed unplanned out-of-state/region travel exceeding the approved amount budgeted for this category must be submitted to the SBA for approval on a case-by-case basis prior to traveling.
(5) All foreign travel requests must be submitted to the appropriate District Director and the SBDC Program Manager for review and provided to the AA/SBDC for final approval in accordance with the notice of funding opportunity. Foreign travel charged to the SBDC cooperative agreement or performed by SBDC staff, while on duty for the recipient organization, must be approved in advance.
(i) Planned foreign travel costs allocable to the SBDC cooperative agreement for SBDC network staff may be approved by AA/SBDC through the annual proposal process, but such planned costs must be fully disclosed and justified in the budget narrative for Agency review. Prior approval should be obtained from the AA/SBDC prior to travel in accordance with 2 CFR part 200.
(ii) Unanticipated foreign travel must be approved using the process set forth in this paragraph (i).
(j)
(a) SBA prohibitions are consistent with those outlined in 2 CFR part 200.
(b) An SBDC must not use project funds as collateral for a loan or other such monetary purpose.
(c) An SBDC must not use project funds for memorabilia, gifts, prizes, souvenirs, entertainment, alcoholic beverages, amusement, social activities, or any other such costs.
(d) Prior written approval from the AA/SBDC is need for SBDC project funds to be used for the purpose of fundraising activities and costs. SBDCs may include in initial applications and renewal applications proposed fundraising activities. After issuance of an approved cooperative agreement, an SBDC wishing to seek prior approval for new fundraising activities not already approved should follow the prior approval guidance in the cooperative agreement. Prohibited fundraising activities include, but are not limited to:
(1) Costs of organized fundraising, endowment drives;
(2) Financial or capital campaigns; or
(3) Solicitation of gifts and bequests.
(e) Project funds found to be used in violation of the restrictions in this section may be cause for termination, suspension, or non-renewal of the cooperative agreement.
(a) An SBDC may charge clients a reasonable fee to cover the costs of training (sponsored or cosponsored) by the SBDC, the sale of books, the rental of equipment or space, research work, hiring outside consultants for a particular client, or other specialized services.
(b) SBDC network entities, staff, consultants, or volunteers must not solicit or accept fees or other compensation for counseling services, including, but not limited to, business or marketing plan development, loan packaging or credit application assistance, or other advisory services described in section 21 of the Small Business Act.
(a) Program income and interest earned on program income, may only be used for authorized purposes and in accordance with 2 CFR 200.307 and the cooperative agreement, such as to expand the quantity or quality of services, resources or outreach provided by the SBDC network.
(b) Program income may not be reported or used as a matching resource. Unused program income must be carried over to the subsequent budget period by the SBDC network; however, the aggregate amount of network program income cannot exceed 25 percent of the total SBDC budget (Federal and matching expenditures).
(c) Program income exceeding 25 percent of the total approved SBDC budget must be expended by the SBDC network prior to the end of the budget/project period in which the excess occurs.
(d) The Lead Center must report the consolidated program income sources and uses as an attachment to the financial status report for the SBDC network during the budget period. The SBDC must provide a narrative describing how program income was used to further program objectives.
(e) For SBDC sponsored activities in which revenue will be shared with a third party, the SBDC must document the reason for the shared revenue and provide a reasonable basis for the shared amount. The basis should include an analysis of actual costs of the activity(ies).
The SBDC Program regulations adopt and implement guidelines in 2 CFR part 200. Additionally, the SBA interest in material property extends to capital equipment and supplies (with an aggregate value of at least $5,000) obtained with resources budgeted and reported under the cooperative agreement. This includes acquisitions made using Federal, matching (including in-kind), or program income sources.
(a) SBA reimbursement of grant funds to recipient organizations is via electronic transfer. Detailed instructions for the recipient organizations are included in the cooperative agreement. Reimbursement requests must be complete, accurate, and reported to the SBA using the proper forms to ensure timely payment by the Agency.
(b) Reimbursement requests may be for the estimated or actual Federal share of SBDC network expenses. Recipient organizations will submit semi-annual and annual financial reports as instructed in the cooperative agreement.
(c) The management of advanced Federal funds by recipient organizations must be in accordance with 2 CFR part 200 and the Agency must be notified of and paid all amounts due from interest accrued on advances.
(d) When the Agency determines that an overpayment of Federal funds has
(a)
(b)
(c)
(2) The AA/SBDC or designee will negotiate with the designated association and Lead Center to establish the annual goals, milestones, and activities for the cooperative agreement.
(3) Failure to meet the goals and milestones of the cooperative agreement may result in suspension, termination, or non-renewal in accordance with the dispute resolution procedures set forth in § 130.630.
(4) Agency loan goals may not be negotiated or incorporated into the cooperative agreement without the prior written approval of the AA/SBDC.
(d)
(2) Contracts and sub-agreements supported with funds provided under the cooperative agreement must comply with the procurement procedures of the recipient organization.
(3) Contracting procedures must encourage open competition among qualified vendors and promote the effective, efficient, and responsible use of program resources and OMB guidance.
(4) Contracting procedures should provide for domestic sourcing preferences to the greatest extent practicable, showing preference for the purchase, acquisition, or use of goods, products, or materials produced in the United States.
(a) Upon approval of the initial or renewal application, SBA will enter into a cooperative agreement with the recipient organization, setting forth the programmatic and fiscal responsibilities of the recipient organization and SBA, the scope of the project to be funded, and the budget of the program year covered by the cooperative agreement.
(b) The SBDC Program adopts and implements OMB guidelines as published at 2 CFR parts 200 and 2701. The guidelines and principles apply to both recipient organizations and SBDC service center organizations. Additional guidance may be promulgated through the notice of funding opportunity.
(c) The AA/SBDC reserves the right to propose additional requirements beyond those set forth in both the uniform grant administrative requirements and cost principles where necessary to ensure the effective and efficient management of the SBDC Program. See 2 CFR part 200, subpart E.
(a)
(1) Any change in project scope or objectives that will substantially change outcomes described in the cooperative agreement;
(2) The addition or deletion of any contracts;
(3) Budget revisions exceeding the limit established in the cooperative agreement; and
(4) Any proposed sole-source or one-bid contracts exceeding the limits established by applicable administrative regulations or OMB.
(b)
(2) Proposed and actual travel costs incurred under an emergency authorization must comply with the requirements of § 130.460(h), as well as the relevant notice of funding opportunity and OMB guidelines.
(a)
(2) If the recipient organization receives an unfavorable decision from the SBA, it may file an appeal with the AA/SBDC within 30 calendar days of the date of receipt of the unfavorable decision.
(3) The AA/SBDC may request additional information or documentation from the recipient organization at any stage of the proceedings. The response to the request for additional information must be provided in writing to the AA/SBDC within 15 calendar days of receipt of the request. The AA/SBDC will transmit a written decision to the recipient organization within 15 calendar days of receipt of the appeal or within 15 calendar days of receipt of additional information requested.
(4) If the recipient organization receives an unfavorable decision from the AA/SBDC, it may make a final appeal to the SBA Grants and cooperative agreements Appeals Committee (the “Committee”). The final appeal to the Committee must be filed within 30 calendar days of the date of receipt of the AA/SBDC's written decision. Copies of the appeal must also be sent to the Grants Management Specialist and the Program Manager. If the recipient organization elects not to file an appeal with the Committee, the decision of the AA/SBDC becomes the final Agency decision on the matter.
(5) A recipient organization may request a hearing before the Committee, but such requests will not be granted, unless material facts are substantially in dispute. Legal briefs and other technical forms of pleading are not required. However, appeals to the Committee must be in writing and contain at least the following information and supporting documentation:
(i) Name and address of the recipient organization;
(ii) Name and address of the appropriate SBA District Office(s);
(iii) A copy of the underlying cooperative agreement, including all amendments;
(iv) A statement of the grounds for appeal, with reasons why the appeal should be sustained;
(v) A statement of the specific relief desired on appeal; and
(vi) If a hearing is requested, a statement of the material facts the recipient organization believes are substantially in dispute. In the event a recipient organization fails to provide any of the information specified above, the Committee may dismiss the appeal.
(6) The Committee may request additional information or documentation from the recipient organization at any stage in the proceedings. The recipient organization's response to the Committee must be submitted, in writing, within 15 calendar days of receipt of the request.
(7) If a request for a hearing is granted, the Committee will provide the recipient organization with written instructions and will afford the parties the opportunity to present their respective positions to the Committee.
(8) The Chairperson of the Committee, with the advice of the SBA's Office of General Counsel (OGC), will issue a final written decision within 30 calendar days of receipt of all information or within 30 calendar days of the completion of the hearing. Copies of the decision will be provided to the recipient organization, the AA/SBDC, the Grants Management Specialist, and the SBA Project Officer.
(9) Where a recipient organization's appeal to the Committee commences or is pending within 120 days of the end of the current budget period, the recipient organization has the right to request, in writing, that the matter be handled under an expedited appeal process. In such circumstances, the Committee, by an affirmative vote of its membership, may expedite the appeals process to attain final resolution of a dispute before the anticipated issuance date of a new cooperative agreement.
(b)
(2) The AA/SBDC will transmit a final, written decision to the recipient organization, the Lead Center Director, the SBA project officer, and the SBA District Office within 30 calendar days of the receipt of such documentation, unless the recipient organization agrees to an extension of time.
(a)
(1)
(i) The SBA may make funds remaining under the cooperative agreement available to satisfy valid financial obligations incurred by the recipient organization prior to the date of termination. Award funds will not be available for obligations incurred after the effective date of termination, unless expressly authorized under the notice of termination. When a cooperative agreement has been terminated, the recipient organization has 120 days to submit final closeout documents to the SBA.
(ii) [Reserved]
(2)
(3)
(ii) The notice of suspension will recommend that the recipient organization cease work on the project immediately. The SBA is under no obligation to reimburse any expenses incurred by a recipient organization while its cooperative agreement is under suspension. Where AA/SBDC decides to lift a suspension and reinstate a recipient organization's cooperative agreement, the Agency may, at its discretion, choose to reimburse a recipient organization for some or all of the expenses it incurred in furtherance of project objectives during the period of suspension. However, there is no guarantee that the Agency will elect to accept such expenses, and recipient organizations incurring expenses while under suspension do so at their own risk.
(b)
(1) Non-performance;
(2) Poor performance;
(3) Unwillingness or inability to implement changes to improve performance;
(4) Disregard or material violation of regulations;
(5) Willful or material failure to comply with the terms of the cooperative agreement, including relevant OMB Circulars;
(6) Conduct of the SBDC Lead Center Director or other key personnel, reflecting a lack of business integrity or honesty, which is not properly addressed on the part of the recipient organization or sponsoring SBDC organizations;
(7) A conflict of interest on the part of the recipient organization, the SBDC service centers, the SBDC Lead Center Director, other key personnel, contractors or volunteers that causes a real or perceived detriment to a small business concern, a contractor, the SBDC network, including but not limited to, SBDC service centers, or SBA;
(8) Improper use of Federal funds;
(9) Failure of a Lead Center or its service centers to consent to audits, examinations, certification reviews, or to maintain required documents or records;
(10) Failure to implement recommendations from the audits or examinations within one year of notification of deficiencies;
(11) Failure to implement recommendations from accreditation reviews within the time frame recommended by the accreditation committee and established by the AA/SBDC;
(12) Failure of the SBDC Lead Center Director to work at the SBDC Lead Center on a full-time basis;
(13) Failure to promptly suspend or terminate the employment of an SBDC Lead Center Director, Service Center Director, or other key personnel, contractors, or volunteers upon receipt of knowledge or written information by the recipient organization and/or SBA indicating that such individual has engaged in conduct which may result or has resulted in a criminal conviction or civil judgment that would cause the public to question the SBDC's integrity. The SBDC Lead Center Director (or other appropriate official in the SBDC network), when making the decision to suspend or terminate such an employee, must consider the magnitude of the behavior, the repetitiveness of the conduct, and the remoteness in time of the behavior underlying any conviction or judgment;
(14) Failure to maintain adequate client service facilities or service hours; and
(15) Any other action that materially and adversely affects the operation or integrity of an SBDC or the SBDC Program.
(c)
(1)
(2)
(3)
(d)
(1)
(i) Name and address of the recipient organization;
(ii) Identification of the relevant SBA office/program (
(iii) Cooperative agreement number;
(iv) Copy of the notice of suspension, termination, or non-renewal;
(v) Statement discussing why the recipient organization believes the SBA's actions were arbitrary, capricious, an abuse of discretion, and/or otherwise not in accordance with the law or governing regulations;
(vi) Identification of the specific relief being sought (
(vii) Statement as to whether the recipient organization is requesting a hearing, and if so, the reasons why it believes a hearing is necessary; and
(viii) Copies of any documents or other evidence the recipient organization believes support its position.
(2)
(i) AA/SBDC; and
(ii) the Associate General Counsel for Procurement Law.
(3)
(i) In addition, if the AA/ED does not receive a request for an administrative review within the 30-day deadline, then the decision by the AA/SBDC to suspend, terminate, or non-renew a recipient organization's cooperative agreement will become the final Agency decision on the matter.
(ii) [Reserved]
(4)
(5)
(i) Notify the parties whether the AA/ED has decided to grant a request for a hearing.
(ii) Direct the parties to submit further arguments and/or evidence on any issues, that she/he believes require clarification.
(iii) Notify the parties that the AA/ED has declared the record to be closed and therefore will refuse to admit any further evidence or argument.
(iv) Within 10 calendar days of declaring the record to be closed, provide all parties with a copy of the AA/ED's written decision on the merits of the administrative review.
(6)
(7)
(8)
(i) Where an enforcement action has been reversed on administrative review, the SBA will have no more than 10 calendar days to implement the AA/ED's decision. However, to the extent permitted under the applicable OMB Circulars, the SBA reserves the right to impose such special conditions in the recipient organization's cooperative agreement as it deems necessary to protect the Government's interests.
(ii) [Reserved]
(a) The AA/SBDC and designees will monitor the SBDC's performance and its ongoing operations under the cooperative agreement to determine if the SBDC is making effective and efficient use of program funds for the benefit of the small business community.
(b) The District Office is the primary contact for the coordination of the delivery of services to the small businesses in each area of service.
(c) The AA/SBDC may change the primary contact for coordination at any time and will notify the recipient organization of such a change in a timely manner.
(a)
(b)
(c)
(i) The Small Business Act provides that the Administration may provide financial support, by contract or otherwise, to the association for the purpose of developing a SBDCs accreditation program. See 15 U.S.C. 648(k)(2).
(ii) SBDC networks must be reviewed for accreditation purposes and receive accreditation periodically, as negotiated between the AA/SBDC and the accreditation committee of the recognized association.
(iii) If an SBDC does not receive accreditation, the SBA may initiate the non-renewal or termination procedure pursuant to § 130.700.
(iv) The statue at 15 U.S.C. 648(k)(3)(B) states the SBA may not renew or extend any cooperative agreement with a SBDC unless the center has been approved under the accreditation program conducted pursuant to this section, except that the AA/SBDC may waive such accreditation requirement, at his or her discretion, upon a showing that the center is making a good faith effort to obtain accreditation.
(2) The AA/SBDC and/or designee will participate in the deliberations of the accreditation committee.
(d)
(a)
(2) The recipient organization will ensure complete and accurate detailed financial and programmatic documentation by all SBDC service center organizations and service centers. The recipient organization will monitor and oversee its SBDC service center organizations and SBDC service centers each budget period to ensure compliance with the OMB guidelines and regulations. See 2 CFR part 200, subpart D.
(i) The recipient organization and Lead Center will ensure that:
(A) All funds received throughout the SBDC network, both Federal and non-Federal, including program income, are properly accounted for, adequately safeguarded, accurately reported, and properly used to further program objectives.
(B) Each SBDC service center organization has reviewed all charges made to its SBDC accounts, including program income, to ensure that they are allowable.
(ii) The recipient organization's Lead Center monitoring and oversight activities must include annual site visits to all its SBDC service center organizations. The Lead Center will document its review procedures. These review procedures must ensure that SBDCs are in compliance with the terms and conditions of the cooperative agreement. The Lead Center will also document the results of annual reviews of the financial and program records of its SBDC service center organizations.
(3) The recipient organization must keep records on the amount, source, and purpose of all funding under the overall management of the SBDC network, including Federal programs.
(b)
(2) All SBDC network records, financial and programmatic, must be maintained for a period of three years following the date SBA accepted the annual performance report and final financial status report from the recipient organization.
(3) The recipient organization will maintain sufficiently detailed program and financial documentation to facilitate transition and provide continuous SBDC services when changes occur in SBDC service center organizations, as well as to support reviews and audits authorized by the SBA.
(a)
(b)
(2) recipient organizations that have been in the Program for fewer than three years must submit financial and programmatic performance reports 30 calendar days after completion of each quarter for the first three years.
(3) The final report from recipient organizations must be submitted in accordance with the notice of funding opportunity and terms and conditions.
(c)
(d)
(2) Final performance reports should include an overall summary of effort expended to deliver the core services described in the cooperative agreement for the full budget period. A discussion of performance measurements achieved and an explanation of those objectives or measurements not met should be included. Performance reports should be a summary of the activities, events or achievements by reportable category with an accompanying management analysis.
(e)
(a)
(2)
(i) Recipient organization must comply with the Single Audit Act (31 U.S.C. 7501) and applicable OMB Circulars (2 CFR part 200).
(ii) The SBA Office of Inspector General (OIG) or its agents may conduct, supervise, or coordinate the SBA's audits, which may, at SBA OIG's discretion, be audits of the SBDC network. In such instances, the SBA will conduct audits in compliance with Government Auditing Standards (GAS) (GAO-18-568G) and applicable OMB Circulars (2 CFR part 200).
(b)
(a)
(b)
(c)
(2) Inventory and documentation of intellectual property must be collected by the Lead Center for close out. In circumstances where SBA is not renewing the cooperative agreement, the recipient organization must provide an intellectual property inventory and the support documentation to the SBDC clearinghouse and to the District Office for disposition instructions.
(d)
(i) An inventory of the SBDC property must be compiled and evaluated. An asset evaluation final report accounting for the property, equipment, and the aggregate of usable supplies and materials must be provided to the Program Manager.
(ii) Program income balances must be reconciled, and unused program income transferred to the Lead Center from SBDC service center organization accounts.
(iii) Client counseling and training records, paper and electronic, must be compiled to facilitate an SBA program closeout review.
(iv) Financial records will be compiled to facilitate an SBA closeout financial examination.
(2)
(3)
(e)
(2) The AA/SBDC will issue written disposition instructions to the recipient organization providing:
(i) The name and address of the entity or agency to which property and program income must be transferred;
(ii) A date by which the transfer must be completed;
(iii) Actions to be taken regarding property and program income;
(iv) Actions to be taken regarding program records such as client and training files; and
(v) Authorization to incur costs for accomplishing the transfer. Such costs may, when authorized, be applied to residual program income or Federal or matching funds.
Federal Aviation Administration (FAA), DOT.
Supplemental notice of proposed rulemaking (SNPRM).
The FAA is revising a notice of proposed rulemaking (NPRM) that would have applied to certain Gulfstream Aerospace LP Model Gulfstream 200 airplanes. This action revises the NPRM by adding Model Galaxy airplanes to the applicability. The FAA is proposing this airworthiness directive (AD) to address the unsafe condition on these products. Since these actions would impose an additional burden over those in the NPRM, the FAA is requesting comments on this SNPRM.
The FAA must receive comments on this SNPRM by January 27, 2023.
You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:
•
•
•
•
• For material that is proposed for incorporation by reference in this SNPRM, contact Civil Aviation Authority of Israel (CAAI), P.O. Box 1101, Golan Street, Airport City, 70100, Israel; telephone 972-3-9774665; fax 972-3-9774592; email
• You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
Dan Rodina, Aerospace Engineer, Large Aircraft Section, FAA, International Validation Branch, FAA, 2200 South 216th Street, Des Moines, WA 98198; telephone 206-231-3225; email
The FAA invites you to send any written relevant data, views, or arguments about this proposal. Send your comments to an address listed under
Except for Confidential Business Information (CBI) as described in the following paragraph, and other information as described in 14 CFR 11.35, the FAA will post all comments received, without change, to
CBI is commercial or financial information that is both customarily and actually treated as private by its owner. Under the Freedom of Information Act (FOIA) (5 U.S.C. 552), CBI is exempt from public disclosure. If your comments responsive to this SNPRM contain commercial or financial information that is customarily treated as private, that you actually treat as private, and that is relevant or responsive to this SNPRM, it is important that you clearly designate the submitted comments as CBI. Please mark each page of your submission containing CBI as “PROPIN.” The FAA will treat such marked submissions as confidential under the FOIA, and they will not be placed in the public docket of this SNPRM. Submissions containing CBI should be sent to Dan Rodina, Aerospace Engineer, Large Aircraft Section, FAA, International Validation Branch, FAA, 2200 South 216th Street, Des Moines, WA 98198; telephone 206-231-3225; email
The FAA issued an NPRM to amend 14 CFR part 39 by adding an AD that would apply to certain Gulfstream Aerospace LP Model Gulfstream 200 airplanes. The NPRM published in the
In the NPRM, the FAA proposed to require an inspection for corrosion in certain areas of the wing skin fairings, additional inspections if necessary, resealing the fairings with new fillet seal, and applicable corrective actions.
You may examine the MCAI in the AD docket at
Since the FAA issued the NPRM, the FAA determined that Model Galaxy airplanes must be added to the applicability. The FAA is proposing this AD to address flap fairing debonding and moisture intrusion that might lead to lower wing skin corrosion and cracking on both wings, and reduced structural integrity of the wings.
The FAA received comments from an anonymous commenter. The following presents the comments received on the NPRM and the FAA's response to each comment.
The commenter requested that the FAA add Model Galaxy airplanes to the applicability. The commenter stated that Model Galaxy airplane serial numbers are included in the applicability of the NPRM, but the model designation (Galaxy) is not mentioned. The commenter concluded that owners/operators for Model Galaxy airplanes might not be aware of the proposed AD and might not address the unsafe condition.
The FAA agrees with the request. The FAA has revised this AD to add Model Galaxy airplanes to the applicability.
The commenter requested that the FAA change Model Gulfstream G200 airplanes to Model Gulfstream 200 airplanes in the applicability. The commenter noted that in the FAA type certificate data sheet (TCDS) A53NM, the model designation is Gulfstream 200. The commented stated that the correction brings the intended model designation in line with the FAA TCDS.
The FAA agrees with the request. The FAA has revised this AD to change the model designation from Gulfstream G200 to Gulfstream 200.
CAAI AD ISR I-57-2021-12-4, dated January 1, 2022, describes procedures for an inspection for corrosion in the area of the wing skin (or doubler if installed) under the rib 3 and rib 11 fairings, a penetration or eddy current inspection for cracks if corrosion was found, a measurement of the thickness of remaining wing skin (or doubler) if no cracks were found, resealing of rib 3 and rib 11 fairings with new fillet seal, and applicable corrective actions. Corrective actions include cleaning and removing corrosion, crack repair, and repair of fairing installation locations with a certain thickness reduction.
This material is reasonably available because the interested parties have access to it through their normal course of business or by the means identified in
This product has been approved by the aviation authority of another country and is approved for operation in the United States. Pursuant to the FAA's bilateral agreement with the State of Design Authority, it has notified the FAA of the unsafe condition described in the MCAI described above. The FAA is issuing this SNPRM after determining that the unsafe condition described previously is likely to exist or develop in other products of the same type design.
Certain changes described above expand the scope of the NPRM. As a result, it is necessary to reopen the comment period to provide additional opportunity for the public to comment on this SNPRM.
This proposed AD would require accomplishing the actions specified in CAAI AD ISR I-57-2021-12-4, dated January 1, 2022, described previously, except for any differences identified as exceptions in the regulatory text of this proposed AD.
In the FAA's ongoing efforts to improve the efficiency of the AD process, the FAA developed a process to use some civil aviation authority (CAA) ADs as the primary source of information for compliance with requirements for corresponding FAA ADs. The FAA has been coordinating this process with manufacturers and CAAs. As a result, the FAA proposes to incorporate CAAI AD ISR I-57-2021-12-4, dated January 1, 2022, by reference in the FAA final rule. This AD would, therefore, require compliance with CAAI AD ISR I-57-2021-12-4, dated January 1, 2022, in its entirety through that incorporation, except for any differences identified as exceptions in the regulatory text of this AD. Service information required by CAAI AD ISR I-57-2021-12-4, dated January 1, 2022, for compliance will be available at
The FAA estimates that this AD, if adopted as proposed, would affect 168 airplanes of U.S. registry. The FAA estimates the following costs to comply with this proposed AD:
The FAA estimates the following costs to do any necessary on-condition action that would be required based on the results of any required actions. The FAA has no way of determining the number of aircraft that might need these on-condition actions:
The FAA has included all known costs in its cost estimate. According to the manufacturer, however, some or all of the costs of this proposed AD may be covered under warranty, thereby reducing the cost impact on affected operators.
Title 49 of the United States Code specifies the FAA's authority to issue rules on aviation safety. Subtitle I, section 106, describes the authority of the FAA Administrator. Subtitle VII: Aviation Programs, describes in more detail the scope of the Agency's authority.
The FAA is issuing this rulemaking under the authority described in Subtitle VII, Part A, Subpart III, Section 44701: General requirements. Under that section, Congress charges the FAA with promoting safe flight of civil aircraft in air commerce by prescribing regulations for practices, methods, and procedures the Administrator finds necessary for safety in air commerce. This regulation is within the scope of that authority because it addresses an unsafe condition that is likely to exist or develop on products identified in this rulemaking action.
The FAA determined that this proposed AD would not have federalism implications under Executive Order 13132. This proposed AD would not have a substantial direct effect on the States, on the relationship between the national Government and the States, or on the distribution of power and responsibilities among the various levels of government.
For the reasons discussed above, I certify this proposed regulation:
(1) Is not a “significant regulatory action” under Executive Order 12866,
(2) Would not affect intrastate aviation in Alaska, and
(3) Would not have a significant economic impact, positive or negative, on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.
Air transportation, Aircraft, Aviation safety, Incorporation by reference, Safety.
Accordingly, under the authority delegated to me by the Administrator, the FAA proposes to amend 14 CFR part 39 as follows:
49 U.S.C. 106(g), 40113, 44701.
The FAA must receive comments on this airworthiness directive (AD) by January 27, 2023.
None.
This AD applies to Gulfstream Aerospace LP Model Galaxy airplanes and Model Gulfstream 200 airplanes, certificated in any category, serial numbers 004 through 250 inclusive.
Air Transport Association (ATA) of America Code 57, Wings.
This AD was prompted by reports that wing flap fairing debonding and corrosion were discovered at lower skin of rib 3 and rib 11 on both wings. The FAA is issuing this AD to address flap fairing debonding and moisture intrusion that might lead to lower wing skin corrosion and cracking on both wings, and reduced structural integrity of the wings.
Comply with this AD within the compliance times specified, unless already done.
Except as specified in paragraphs (h) and (i) of this AD: Comply with all required actions and compliance times specified in, and in accordance with, Civil Aviation Authority of Israel (CAAI) AD ISR I-57-2021-12-4, dated January 1, 2022 (CAAI AD ISR I-57-2021-12-4).
(1) Where CAAI AD ISR I-57-2021-12-4 refers to its effective date, this AD requires using the effective date of this AD.
(2) Where the Compliance paragraph of CAAI AD ISR I-57-2021-12-4 requires compliance at a certain time, replace the text “at the next suitable planned maintenance inspection within the next 24 months from the effective date of this AD” with “within 24 months after the effective date of this AD.”
(3) Where the Action paragraph of CAAI AD ISR I-57-2021-12-4 refers to certain service information, replace the text “Gulfstream Service Bulletin No. 200-57-426, dated January 01, 2022, or later approved revision,” with “Gulfstream Service Bulletin No. 200-57-426, Revision 1, dated June 16, 2022, or later approved revision.”
(4) Where the service information specified in CAAI AD ISR I-57-2021-12-4 specifies to report to Gulfstream if “cracks were discovered” and “for any fairing installation location with one or more grid squares with thickness reduction of greater than 10%,” for this AD, cracks and fairing installation locations with one or more grid squares with thickness reduction of greater than 10% must be repaired before further flight using a method approved by the Manager, International Validation Branch, FAA; or CAAI; or CAAI's authorized Designee. If approved by the authorized Designee, the approval must include the Designee's authorized signature.
Although the service information referenced in CAAI AD ISR I-57-2021-12-4 specifies to submit certain information to the manufacturer, this AD does not include that requirement.
The following provisions also apply to this AD:
(1)
(2)
For more information about this AD, contact Dan Rodina, Aerospace Engineer, Large Aircraft Section, FAA, International Validation Branch, FAA, 2200 South 216th Street, Des Moines, WA 98198; telephone 206-231-3225; email
(1) The Director of the Federal Register approved the incorporation by reference of the service information listed in this paragraph under 5 U.S.C. 552(a) and 1 CFR part 51.
(2) You must use this service information as applicable to do the actions required by this AD, unless this AD specifies otherwise.
(i) Civil Aviation Authority of Israel (CAAI) AD ISR I-57-2021-12-4, dated January 1, 2022.
(ii) [Reserved]
(3) For CAAI AD ISR I-57-2021-12-4, contact Civil Aviation Authority of Israel (CAAI), P.O. Box 1101, Golan Street, Airport City, 70100, Israel; telephone 972-3-9774665; fax 972-3-9774592; email
(4) You may view this material at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
(5) You may view this material that is incorporated by reference at the National Archives and Records Administration (NARA). For information on the availability of this material at NARA, email
Federal Aviation Administration (FAA), DOT.
Notice of proposed rulemaking (NPRM).
The FAA proposes to supersede Airworthiness Directive (AD) 2021-09-12, which applies to certain Dassault Aviation Model FALCON 7X airplanes. AD 2021-09-12 requires revising the existing maintenance or inspection program, as applicable, to incorporate new or more restrictive airworthiness limitations. Since the FAA issued AD 2021-09-12, the FAA has determined that new or more restrictive airworthiness limitations are necessary. This proposed AD would continue to require the actions in AD 2021-09-12 and require revising the existing maintenance or inspection program, as applicable, to incorporate additional new or more restrictive airworthiness limitations, as specified in a European Union Aviation Safety Agency (EASA) AD, which is proposed for incorporation by reference (IBR). The FAA is proposing this AD to address the unsafe condition on these products.
The FAA must receive comments on this proposed AD by January 27, 2023.
You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:
•
•
•
•
• For material that is proposed for IBR in this NPRM, contact EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; telephone +49 221 8999 000; email
• You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
Tom Rodriguez, Aerospace Engineer, Large Aircraft Section, International Validation Branch, FAA, 2200 South 216th St., Des Moines, WA 98198; telephone and fax 206-231-3226; email
The FAA invites you to send any written relevant data, views, or arguments about this proposal. Send
Except for Confidential Business Information (CBI) as described in the following paragraph, and other information as described in 14 CFR 11.35, the FAA will post all comments received, without change, to
CBI is commercial or financial information that is both customarily and actually treated as private by its owner. Under the Freedom of Information Act (FOIA) (5 U.S.C. 552), CBI is exempt from public disclosure. If your comments responsive to this NPRM contain commercial or financial information that is customarily treated as private, that you actually treat as private, and that is relevant or responsive to this NPRM, it is important that you clearly designate the submitted comments as CBI. Please mark each page of your submission containing CBI as “PROPIN.” The FAA will treat such marked submissions as confidential under the FOIA, and they will not be placed in the public docket of this NPRM. Submissions containing CBI should be sent to Tom Rodriguez, Aerospace Engineer, Large Aircraft Section, International Validation Branch, FAA, 2200 South 216th St., Des Moines, WA 98198; telephone and fax 206-231-3226; email
The FAA issued AD 2021-09-12, Amendment 39-21526 (86 FR 23593, May 4, 2021) (AD 2021-09-12), for certain Dassault Aviation Model FALCON 7X airplanes. AD 2021-09-12 was prompted by MCAI originated by EASA, which is the Technical Agent for the Member States of the European Union. EASA issued AD 2020-0214, dated October 6, 2020 (EASA AD 2020-0214) (which corresponds to FAA AD 2021-09-12), to correct an unsafe condition.
AD 2021-09-12 requires revising the existing maintenance or inspection program, as applicable, to incorporate new or more restrictive airworthiness limitations. The FAA issued AD 2021-09-12 to address reduced structural integrity and reduced control of airplanes due to the failure of system components. AD 2021-09-12 specifies that accomplishing the revision required by that AD terminates certain requirements of AD 2014-16-23, Amendment 39-17947 (79 FR 52545, September 4, 2014) (AD 2014-16-23).
Since the FAA issued AD 2021-09-12, EASA superseded EASA AD 2020-0214 and issued EASA AD 2022-0142, dated July 7, 2022 (EASA AD 2022-0142) (referred to after this as the MCAI), for all Dassault Aviation Model FALCON 7X airplanes. The MCAI states that new or more restrictive airworthiness limitations have been issued.
Airplanes with an original airworthiness certificate or original export certificate of airworthiness issued after June 7, 2021 must comply with the airworthiness limitations specified as part of the approved type design and referenced on the type certificate data sheet; this proposed AD therefore does not include those airplanes in the applicability.
The FAA is proposing this AD to address reduced structural integrity and reduced control of airplanes due to the failure of system components. You may examine the MCAI in the AD docket at
The FAA reviewed EASA AD 2022-0142. This service information specifies new or more restrictive airworthiness limitations for airplane structures and safe life limits.
This proposed AD would also require EASA AD 2020-0214, dated October 6, 2020, which the Director of the Federal Register approved for incorporation by reference as of June 8, 2021 (86 FR 23593, May 4, 2021).
This material is reasonably available because the interested parties have access to it through their normal course of business or by the means identified in
This product has been approved by the aviation authority of another country and is approved for operation in the United States. Pursuant to the FAA's bilateral agreement with the State of Design Authority, it has notified the FAA of the unsafe condition described in the MCAI described above. The FAA is issuing this NPRM after determining that the unsafe condition described previously is likely to exist or develop in other products of the same type design.
This proposed AD would retain certain requirements of AD 2021-09-12. This proposed AD would also require revising the existing maintenance or inspection program, as applicable, to incorporate additional new or more restrictive airworthiness limitations, which are specified in EASA AD 2022-0142 already described, as proposed for incorporation by reference. Any differences with EASA AD 2022-0142 are identified as exceptions in the regulatory text of this AD.
This proposed AD would require revisions to certain operator maintenance documents to include new actions (
In the FAA's ongoing efforts to improve the efficiency of the AD process, the FAA developed a process to use some civil aviation authority (CAA) ADs as the primary source of information for compliance with requirements for corresponding FAA ADs. The FAA has been coordinating this process with manufacturers and CAAs. As a result, the FAA proposes to retain the IBR of EASA AD 2020-0214 and incorporate EASA AD 2022-0142 by reference in the FAA final rule. This proposed AD would, therefore, require compliance with EASA AD 2022-0142 and EASA AD 2020-0214 through that incorporation, except for any differences identified as exceptions in the regulatory text of this proposed AD. Using common terms that are the same as the heading of a particular section in
The FAA's process of incorporating by reference MCAI ADs as the primary source of information for compliance with corresponding FAA ADs has been limited to certain MCAI ADs (primarily those with service bulletins as the primary source of information for accomplishing the actions required by the FAA AD). However, the FAA is now expanding the process to include MCAI ADs that require a change to airworthiness limitation documents, such as airworthiness limitation sections.
For these ADs that incorporate by reference an MCAI AD that changes airworthiness limitations, the FAA requirements are unchanged. Operators must revise the existing maintenance or inspection program, as applicable, to incorporate the information specified in the new airworthiness limitation document. The airworthiness limitations must be followed according to 14 CFR 91.403(c) and 91.409(e).
The previous format of the airworthiness limitation ADs included a paragraph that specified that no alternative actions (
The FAA estimates that this AD, if adopted as proposed, would affect 122 airplanes of U.S. registry. The FAA estimates the following costs to comply with this proposed AD:
The FAA estimates the total cost per operator for the retained actions from AD 2021-09-12 to be $7,650 (90 work-hours × $85 per work-hour).
The FAA has determined that revising the existing maintenance or inspection program takes an average of 90 work-hours per operator, although the agency recognizes that this number may vary from operator to operator. Since operators incorporate maintenance or inspection program changes for their affected fleet(s), the FAA has determined that a per-operator estimate is more accurate than a per-airplane estimate.
The FAA estimates the total cost per operator for the new proposed actions to be $7,650 (90 work-hours × $85 per work-hour).
Title 49 of the United States Code specifies the FAA's authority to issue rules on aviation safety. Subtitle I, section 106, describes the authority of the FAA Administrator. Subtitle VII: Aviation Programs, describes in more detail the scope of the Agency's authority.
The FAA is issuing this rulemaking under the authority described in Subtitle VII, Part A, Subpart III, Section 44701: General requirements. Under that section, Congress charges the FAA with promoting safe flight of civil aircraft in air commerce by prescribing regulations for practices, methods, and procedures the Administrator finds necessary for safety in air commerce. This regulation is within the scope of that authority because it addresses an unsafe condition that is likely to exist or develop on products identified in this rulemaking action.
The FAA determined that this proposed AD would not have federalism implications under Executive Order 13132. This proposed AD would not have a substantial direct effect on the States, on the relationship between the national Government and the States, or on the distribution of power and responsibilities among the various levels of government.
For the reasons discussed above, I certify this proposed regulation:
(1) Is not a “significant regulatory action” under Executive Order 12866,
(2) Would not affect intrastate aviation in Alaska, and
(3) Would not have a significant economic impact, positive or negative, on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.
Air transportation, Aircraft, Aviation safety, Incorporation by reference, Safety.
Accordingly, under the authority delegated to me by the Administrator, the FAA proposes to amend 14 CFR part 39 as follows:
49 U.S.C. 106(g), 40113, 44701.
The FAA must receive comments on this airworthiness directive (AD) by January 27, 2023.
(1) This AD replaces AD 2021-09-12, Amendment 39-21526 (86 FR 23593, May 4, 2021) (AD 2021-09-12).
(2) This AD affects AD 2014-16-23, Amendment 39-17947 (79 FR 52545, September 4, 2014) (AD 2014-16-23).
This AD applies to Dassault Aviation Model FALCON 7X airplanes, certificated in any category, with an original airworthiness certificate or original export certificate of airworthiness issued on or before June 7, 2021.
Air Transport Association (ATA) of America Code 05, Time Limits/Maintenance Checks.
This AD was prompted by a determination that new or more restrictive airworthiness limitations are necessary. The FAA is issuing this AD to address reduced structural integrity and reduced control of airplanes due to the failure of system components.
Comply with this AD within the compliance times specified, unless already done.
This paragraph restates the requirements of paragraph (j) of AD 2021-09-12, with no changes. For airplanes with an original airworthiness certificate or original export certificate of airworthiness issued on or before June 1, 2020, except as specified in paragraph (h) of this AD: Comply with all required actions and compliance times specified in, and in accordance with, European Union Aviation Safety Agency (EASA) AD 2020-0214, dated October 6, 2020 (EASA AD 2020-0214). Accomplishing the revision of the existing maintenance or inspection program required by paragraph (j) of this AD terminates the requirements of this paragraph.
This paragraph restates the exceptions specified in paragraph (k) of AD 2021-09-12, With no changes.
(1) The requirements specified in paragraphs (1) and (2) of EASA AD 2020-0214 do not apply to this AD.
(2) Paragraph (3) of EASA AD 2020-0214 specifies revising “the approved AMP” within 12 months after its effective date, but this AD requires revising the existing maintenance or inspection program, as applicable, to incorporate the “limitations, tasks and associated thresholds and intervals” specified in paragraph (3) of EASA AD 2020-0214 within 90 days after June 8, 2021 (the effective date of this AD 2021-09-12).
(3) The initial compliance time for doing the tasks specified in paragraph (3) of EASA AD 2020-0214 is at the applicable “associated thresholds” specified in paragraph (3) of EASA AD 2020-0214, or within 90 days after June 8, 2021 (the effective date of this AD 2021-09-12), whichever occurs later.
(4) The provisions specified in paragraphs (4) and (5) of EASA AD 2019-0257 do not apply to this AD.
(5) The “Remarks” section of EASA AD 2020-0214 does not apply to this AD.
This paragraph restates the requirements of paragraph (l) of AD 2021-09-12, with a new exception. Except as required by paragraph (j) of this AD, after the maintenance or inspection program has been revised as required by paragraph (g) of this AD, no alternative actions (
Except as specified in paragraph (k) of this AD: Comply with all required actions and compliance times specified in, and in accordance with, EASA AD 2022-0142, dated July 7, 2022 (EASA AD 2022-0142). Accomplishing the revision of the existing maintenance or inspection program required by this paragraph terminates the requirements of paragraph (g) of this AD.
(1) The requirements specified in paragraphs (1) and (2) of EASA AD 2022-0142 do not apply to this AD.
(2) Paragraph (3) of EASA AD 2022-0142 specifies revising “the approved AMP” within 12 months after its effective date, but this AD requires revising the existing maintenance or inspection program, as applicable, within 90 days after the effective date of this AD.
(3) The initial compliance time for doing the tasks specified in paragraph (3) of EASA AD 2022-0142 is at the applicable “limitations” and “associated thresholds” as incorporated by the requirements of paragraph (3) of EASA AD 2022-0142, or within 90 days after the effective date of this AD, whichever occurs later.
(4) The provisions specified in paragraphs (4) and (5) of EASA AD 2022-0142 do not apply to this AD.
(5) The “Remarks” section of EASA AD 2022-0142 does not apply to this AD.
After the existing maintenance or inspection program has been revised as required by paragraph (j) of this AD, no alternative actions (
Accomplishing the actions required by paragraphs (g) or (j) of this AD terminates the requirements of paragraph (q) of AD 2014-16-23.
The following provisions also apply to this AD:
(1)
(2)
For more information about this AD, contact Tom Rodriguez, Aerospace Engineer, Large Aircraft Section, International Validation Branch, FAA, 2200 South 216th St., Des Moines, WA 98198; telephone and fax 206-231-3226; email
(1) The Director of the Federal Register approved the incorporation by reference of the service information listed in this paragraph under 5 U.S.C. 552(a) and 1 CFR part 51.
(2) You must use this service information as applicable to do the actions required by this AD, unless this AD specifies otherwise.
(3) The following service information was approved for IBR on [DATE 35 DAYS AFTER PUBLICATION OF THE FINAL RULE].
(i) European Union Aviation Safety Agency (EASA) AD 2022-0142, dated July 7, 2022.
(ii) [Reserved]
(4) The following service information was approved for IBR on June 8, 2021 (86 FR 23593, May 4, 2021).
(i) European Union Aviation Safety Agency (EASA) AD 2020-0214, dated October 6, 2020.
(ii) [Reserved]
(5) For EASA ADs 2022-0142 and 2020-0214, contact EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; telephone +49 221 8999 000; email
(6) You may view this material at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
(7) You may view this material that is incorporated by reference at the National Archives and Records Administration (NARA). For information on the availability of this material at NARA, email
Federal Aviation Administration (FAA), DOT.
Notice of proposed rulemaking (NPRM).
The FAA proposes to supersede Airworthiness Directive (AD) 2019-18-07, which applies to certain Airbus SAS Model A319-111, -112, -113, -114, -115, -131, -132, and -133 airplanes; Model A320-211, -212, -214, -216, -231, -232, and -233 airplanes; and Model A321-111, -112, -131, -211, -212, -213, -231, and -232 airplanes. AD 2019-18-07 requires repetitive rototest inspections of the open tack holes and rivet holes at the cargo floor support fittings of the fuselage, including doing all applicable related investigative actions and repair if necessary. AD 2019-18-07 also adds actions (modification) for certain airplanes. Since the FAA issued AD 2019-18-07, it was determined that certain airplanes need to do additional work. This proposed AD would continue to require the actions in AD 2019-18-07 and would require additional work for certain airplanes, as specified in a European Union Aviation Safety Agency (EASA) AD, which is proposed for incorporation by reference (IBR). The FAA is proposing this AD to address the unsafe condition on these products.
The FAA must receive comments on this proposed AD by January 27, 2023.
You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:
•
•
•
•
• For material that is proposed for IBR in this NPRM, contact EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; telephone +49 221 8999 000; email
• You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
Hye Yoon Jang, Aerospace Engineer, Large Aircraft Section, FAA, International Validation Branch, 2200 South 216th St., Des Moines, WA 98198; telephone 817-222-5584; email
The FAA invites you to send any written relevant data, views, or arguments about this proposal. Send your comments to an address listed under
Except for Confidential Business Information (CBI) as described in the following paragraph, and other information as described in 14 CFR 11.35, the FAA will post all comments received, without change, to
CBI is commercial or financial information that is both customarily and actually treated as private by its owner. Under the Freedom of Information Act (FOIA) (5 U.S.C. 552), CBI is exempt from public disclosure. If your comments responsive to this NPRM contain commercial or financial information that is customarily treated as private, that you actually treat as private, and that is relevant or responsive to this NPRM, it is important that you clearly designate the submitted comments as CBI. Please mark each page of your submission containing CBI as “PROPIN.” The FAA will treat such marked submissions as confidential under the FOIA, and they will not be placed in the public docket of this NPRM. Submissions containing CBI should be sent to Hye Yoon Jang, Aerospace Engineer, Large Aircraft Section, FAA, International Validation Branch, 2200 South 216th St., Des Moines, WA 98198; telephone 817-222-5584; email
The FAA issued AD 2019-18-07, Amendment 39-19734 (84 FR 50721, September 26, 2019) (AD 2019-18-07), for certain Airbus SAS Model A319-111, -112, -113, -114, -115, -131, -132, and -133 airplanes; Model A320-211, -212, -214, -216, -231, -232, and -233 airplanes; and Model A321-111, -112, -131, -211, -212, -213, -231, and -232 airplanes. AD 2019-18-07 was prompted by MCAI originated by EASA, which is the Technical Agent for the Member States of the European Union. EASA issued AD 2018-0233R1, dated November 28, 2018 (EASA AD 2018-0233R1), to correct an unsafe condition.
AD 2019-18-07 requires repetitive rototest inspections of the open tack holes and rivet holes at the cargo floor support fittings of the fuselage, including doing all applicable related investigative actions, and repair if necessary. AD 2019-18-07 also adds actions (modification) for certain airplanes The FAA issued AD 2019-18-07 to address cracking in the open tack holes and rivet holes at the cargo floor support fittings of the fuselage. This condition, if not addressed, could affect the structural integrity of the airplane.
AD 2019-18-07 superseded AD 2015-17-14, Amendment 39-18247 (80 FR 52182, August 28, 2015) (AD 2015-17-14). AD 2019-18-07 was based on further analysis and widespread fatigue damage (WFD) evaluations which identified the need to reduce the initial compliance times and repetitive intervals specified in AD 2015-17-14
Since the FAA issued AD 2019-18-07, EASA superseded EASA AD 2018-0233R1, and issued EASA AD 2022-0115, dated June 20, 2022 (EASA AD 2022-0115) (also referred to as the MCAI), to correct an unsafe condition for certain A319-111, -112, -113, -114, -115, -131, -132, and -133 airplanes; Model A320-211, -212, -214, -215, -216, -231, -232, and -233 airplanes; and Model A321-111, -112, -131, -211, -212, -213, -231, and -232 airplanes. Model A320-215 airplanes are not certificated by the FAA and are not included on the U.S. type certificate data sheet; this AD therefore does not include those airplanes in the applicability. The MCAI states that new technical considerations identified the need to introduce additional work for certain airplanes previously modified as specified in AD 2019-18-07. The MCAI also states that cracking in the open tack holes and rivet holes at the cargo floor support fittings of the fuselage, if not addressed, could affect the structural integrity of the airplane.
You may examine the MCAI in the AD docket at
Although this proposed AD does not explicitly restate the requirements of AD 2019-18-07, this proposed AD would retain all of the requirements of AD 2019-18-07. Those requirements are referenced in EASA AD 2022-0115, which, in turn, is referenced in paragraph (g) of this proposed AD.
EASA AD 2022-0115 specifies repetitive inspections of the open tack holes and rivet holes of the fuselage frames below the cargo floor support fittings for cracking, including doing all applicable related investigative actions (inspections of the related frame layer (vertical web/horizontal flange) for cracking) and repair. EASA AD 2022-0115 also specifies procedures for modification of the fuselage (including replacing the shear webs and certain frame clips, adding additional support angles, and cold expanding one tack hole and one tooling home in each frame). EASA AD 2022-0115 also specifies procedures for additional work for certain Model A321 airplanes previously modified as specified AD 2019-18-07. The additional work includes replacing affected fasteners on frames 62 and 63 after doing a rototest for cracking, cold working the fastener holes, and repair.
This material is reasonably available because the interested parties have access to it through their normal course of business or by the means identified in the
This product has been approved by the aviation authority of another country and is approved for operation in the United States. Pursuant to the FAA's bilateral agreement with the State of Design Authority, it has notified the FAA of the unsafe condition described in the MCAI referenced above. The FAA is issuing this NPRM after determining that the unsafe condition described previously is likely to exist or develop in other products of the same type design.
This proposed AD would require accomplishing the actions specified in EASA AD 2022-0115 described previously, except for any differences identified as exceptions in the regulatory text of this proposed AD.
In the FAA's ongoing efforts to improve the efficiency of the AD process, the FAA developed a process to use some civil aviation authority (CAA) ADs as the primary source of information for compliance with requirements for corresponding FAA ADs. The FAA has been coordinating this process with manufacturers and CAAs. As a result, the FAA proposes to incorporate EASA AD 2022-0115 by reference in the FAA final rule. This proposed AD would, therefore, require compliance with EASA AD 2022-0115 in its entirety through that incorporation, except for any differences identified as exceptions in the regulatory text of this proposed AD. Using common terms that are the same as the heading of a particular section in EASA AD 2022-0115 does not mean that operators need comply only with that section. For example, where the AD requirement refers to “all required actions and compliance times,” compliance with this AD requirement is not limited to the section titled “Required Action(s) and Compliance Time(s)” in EASA AD 2022-0115. Service information required by EASA AD 2022-0115 for compliance will be available at
The FAA estimates that this AD, if adopted as proposed, would affect 1,267 airplanes of U.S. registry. The FAA estimates the following costs to comply with this proposed AD:
The FAA has received no definitive data that would enable the agency to provide cost estimates for the on-condition actions specified in this proposed AD.
Title 49 of the United States Code specifies the FAA's authority to issue rules on aviation safety. Subtitle I, section 106, describes the authority of the FAA Administrator. Subtitle VII: Aviation Programs, describes in more detail the scope of the Agency's authority.
The FAA is issuing this rulemaking under the authority described in Subtitle VII, Part A, Subpart III, Section 44701: General requirements. Under that section, Congress charges the FAA with promoting safe flight of civil aircraft in air commerce by prescribing regulations for practices, methods, and procedures the Administrator finds necessary for safety in air commerce. This regulation is within the scope of that authority because it addresses an
The FAA determined that this proposed AD would not have federalism implications under Executive Order 13132. This proposed AD would not have a substantial direct effect on the States, on the relationship between the national Government and the States, or on the distribution of power and responsibilities among the various levels of government.
For the reasons discussed above, I certify this proposed regulation:
(1) Is not a “significant regulatory action” under Executive Order 12866,
(2) Would not affect intrastate aviation in Alaska, and
(3) Would not have a significant economic impact, positive or negative, on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.
Air transportation, Aircraft, Aviation safety, Incorporation by reference, Safety.
Accordingly, under the authority delegated to me by the Administrator, the FAA proposes to amend 14 CFR part 39 as follows:
49 U.S.C. 106(g), 40113, 44701.
The FAA must receive comments on this airworthiness directive (AD) by January 27, 2023.
This AD replaces AD 2019-18-07, Amendment 39-19734 (84 FR 50721, September 26, 2019) (AD 2019-18-07).
This AD applies to Airbus SAS Model A319-111, -112, -113, -114, -115, -131, -132, and -133 airplanes; Model A320-211, -212, -214, -216, -231, -232, and -233 airplanes; and Model A321-111, -112, -131, -211, -212, -213, -231, and -232 airplanes; certificated in any category, as identified in European Aviation Safety Agency (EASA) AD 2022-0115, dated June 20, 2022 (EASA AD 2022-0115).
Air Transport Association (ATA) of America Code 53, Fuselage.
This AD was prompted by widespread fatigue damage (WFD) evaluations and full-scale fatigue testing that revealed several broken frames in certain areas of the cargo compartment, and by the determination that additional work is needed for certain airplanes. The FAA is issuing this AD to address cracking in the open tack holes and rivet holes at the cargo floor support fittings of the fuselage. The unsafe condition, if not addressed, could affect the structural integrity of the airplane.
Comply with this AD within the compliance times specified, unless already done.
Except as specified in paragraph (h) of this AD: Comply with all required actions and compliance times specified in, and in accordance with, EASA AD 2022-0115.
(1) Where EASA AD 2022-0115 refers to January 3, 2014 (the effective date of EASA AD 2013-0310), this AD requires using October 2, 2015 (the effective date of AD 2015-17-14, Amendment 39-18247 (80 FR 52182, August 28, 2015)).
(2) Where EASA AD 2022-0115 refers to November 9, 2018 (the effective date of EASA AD 2018-0233 at original issue), this AD requires using October 31, 2019 (the effective date of AD 2019-18-07).
(3) Where EASA AD 2022-0115 refers to its effective date, this AD requires using the effective date of this AD.
(4) Where paragraph (2) of EASA AD 2022-0115 specifies “contact Airbus for approved repair instructions and, within the compliance time identified therein, accomplish those instructions accordingly” if a crack is detected, for this AD if any cracking is detected, the cracking must be repaired before further flight using a method approved by the Manager, International Validation Branch, FAA; or EASA; or Airbus SAS's EASA Design Organization Approval (DOA). If approved by the DOA, the approval must include the DOA-authorized signature.
(5) The “Remarks” section of EASA AD 2022-0115 does not apply to this AD.
The following provisions also apply to this AD:
(1)
(2)
(3)
For more information about this AD, contact Hye Yoon Jang, Aerospace Engineer, Large Aircraft Section, FAA, International Validation Branch, 2200 South 216th St., Des Moines, WA 98198; telephone 817-222-5584; email
(1) The Director of the Federal Register approved the incorporation by reference (IBR) of the service information listed in this paragraph under 5 U.S.C. 552(a) and 1 CFR part 51.
(2) You must use this service information as applicable to do the actions required by this AD, unless this AD specifies otherwise.
(i) European Union Aviation Safety Agency (EASA) AD 2022-0115, dated June 20, 2022.
(ii) [Reserved]
(3) For EASA AD 2022-0115, contact EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; telephone +49 221 8999 000; email
(4) You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
(5) You may view this service information that is incorporated by reference at the National Archives and Records Administration (NARA). For information on the availability of this material at NARA, email
Federal Aviation Administration (FAA), DOT.
Notice of proposed rulemaking (NPRM).
The FAA proposes to adopt a new airworthiness directive (AD) for all The Boeing Company Model 787-8, 787-9, and 787-10 airplanes. This proposed AD was prompted by reports of a loss of water pressure during flight and water leaks that affected multiple pieces of electronic equipment. This proposed AD would require a detailed visual inspection of all door 1 and door 3 lavatory and galley potable water systems for any missing or incorrectly installed clamshell couplings and applicable on-condition actions. The FAA is proposing this AD to address the unsafe condition on these products.
The FAA must receive comments on this proposed AD by January 27, 2023.
You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:
•
•
•
•
• For service information identified in this NPRM, contact Boeing Commercial Airplanes, Attention: Contractual & Data Services (C&DS), 2600 Westminster Blvd., MC 110-SK57, Seal Beach, CA 90740-5600; telephone 562-797-1717; website
• You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
Courtney Tuck, Aerospace Engineer, Cabin Safety and Environmental Systems Section, FAA, Seattle ACO Branch, 2200 South 216th St., Des Moines, WA 98198; phone and fax: 206-231-3986; email:
The FAA invites you to send any written relevant data, views, or arguments about this proposal. Send your comments to an address listed under
Except for Confidential Business Information (CBI) as described in the following paragraph, and other information as described in 14 CFR 11.35, the FAA will post all comments received, without change, to
CBI is commercial or financial information that is both customarily and actually treated as private by its owner. Under the Freedom of Information Act (FOIA) (5 U.S.C. 552), CBI is exempt from public disclosure. If your comments responsive to this NPRM contain commercial or financial information that is customarily treated as private, that you actually treat as private, and that is relevant or responsive to this NPRM, it is important that you clearly designate the submitted comments as CBI. Please mark each page of your submission containing CBI as “PROPIN.” The FAA will treat such marked submissions as confidential under the FOIA, and they will not be placed in the public docket of this NPRM. Submissions containing CBI should be sent to Courtney Tuck, Aerospace Engineer, Cabin Safety and Environmental Systems Section, FAA, Seattle ACO Branch, 2200 South 216th St., Des Moines, WA 98198; phone and fax: 206-231-3986; email:
The FAA has received reports of a loss of water pressure during flight and water leaks that affected multiple pieces of electronic equipment. One operator reported a significant water leak due to a loose potable water system hose caused by an incorrectly installed clamshell coupling within the lavatory. Another operator reported a water leak due to a detached clamshell coupling below the Door 1 forward center galley countertop adjacent to the gray water interface valve (GWIV) maintenance access compartment. The findings include a loss of water pressure during flight and a potable water system leak, discovered after landing, that caused water to migrate into the forward electronic equipment (EE) bay and affect multiple pieces of electronic equipment. In addition, water pressure was lost during flight. Incorrectly installed or missing lavatory and galley clamshell couplings, if not addressed, could result in water leaks and water migration to critical flight equipment, which may affect the continued safe flight and landing of the airplane.
The FAA is issuing this NPRM after determining that the unsafe condition described previously is likely to exist or develop on other products of the same type design.
The FAA reviewed Boeing Alert Requirements Bulletin B787-81205-SB380021-00 RB, Issue 001, dated August 12, 2022. This service information specifies procedures for a detailed visual inspection of all door 1
This service information is reasonably available because the interested parties have access to it through their normal course of business or by the means identified in
This proposed AD would require accomplishing the actions specified in the service information already described except for any differences identified as exceptions in the regulatory text of this proposed AD. For information on the procedures and compliance times, see this service information at regulations.gov by searching for and locating Docket No. FAA-2022-1417.
The FAA considers that this proposed AD would be an interim action. If a final action is later identified, the FAA might consider further rulemaking.
The FAA estimates that this AD, if adopted as proposed, would affect 134 airplanes of U.S. registry. The FAA estimates the following costs to comply with this proposed AD:
The FAA has received no definitive data on which to base the cost estimates for the on-condition actions specified in this proposed AD.
Title 49 of the United States Code specifies the FAA's authority to issue rules on aviation safety. Subtitle I, section 106, describes the authority of the FAA Administrator. Subtitle VII: Aviation Programs, describes in more detail the scope of the Agency's authority.
The FAA is issuing this rulemaking under the authority described in Subtitle VII, Part A, Subpart III, Section 44701: General requirements. Under that section, Congress charges the FAA with promoting safe flight of civil aircraft in air commerce by prescribing regulations for practices, methods, and procedures the Administrator finds necessary for safety in air commerce. This regulation is within the scope of that authority because it addresses an unsafe condition that is likely to exist or develop on products identified in this rulemaking action.
The FAA determined that this proposed AD would not have federalism implications under Executive Order 13132. This proposed AD would not have a substantial direct effect on the States, on the relationship between the national Government and the States, or on the distribution of power and responsibilities among the various levels of government.
For the reasons discussed above, I certify this proposed regulation:
(1) Is not a “significant regulatory action” under Executive Order 12866,
(2) Would not affect intrastate aviation in Alaska, and
(3) Would not have a significant economic impact, positive or negative, on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.
Air transportation, Aircraft, Aviation safety, Incorporation by reference, Safety.
Accordingly, under the authority delegated to me by the Administrator, the FAA proposes to amend 14 CFR part 39 as follows:
49 U.S.C. 106(g), 40113, 44701.
The FAA must receive comments on this airworthiness directive (AD) by January 27, 2023.
None.
This AD applies to all The Boeing Company Model 787-8, 787-9, and 787-10 airplanes, certificated in any category.
Air Transport Association (ATA) of America Code 38, Water/waste.
This AD was prompted by reports of a loss of water pressure during flight and water leaks that affected multiple pieces of electronic equipment. The FAA is issuing this AD to address incorrectly installed or missing lavatory and galley clamshell couplings that could lead to water leaks and water migration to critical flight equipment, which may affect the continued safe flight and landing of the airplane.
Comply with this AD within the compliance times specified, unless already done.
Except as specified by paragraph (h) of this AD: At the applicable times specified in the “Compliance” paragraph of Boeing Alert Requirements Bulletin B787-81205-SB380021-00 RB, Issue 001, dated August 12, 2022, do all applicable actions identified in, and in accordance with, the Accomplishment Instructions of Boeing Alert Requirements Bulletin B787-81205-SB380021-00 RB, Issue 001, dated August 12, 2022.
Where the Compliance Time columns of the table in the “Compliance” paragraph of Boeing Alert Requirements Bulletin B787-81205-SB380021-00 RB, Issue 001, dated August 12, 2022, uses the phrase “the Issue 001 date of Requirements Bulletin B787-81205-SB380021-00 RB,” this AD requires using “the effective date of this AD.”
(1) The Manager, Seattle ACO Branch, FAA, has the authority to approve AMOCs
(2) Before using any approved AMOC, notify your appropriate principal inspector, or lacking a principal inspector, the manager of the responsible Flight Standards Office.
(3) An AMOC that provides an acceptable level of safety may be used for any repair, modification, or alteration required by this AD if it is approved by The Boeing Company Organization Designation Authorization (ODA) that has been authorized by the Manager, Seattle ACO Branch, FAA, to make those findings. To be approved, the repair method, modification deviation, or alteration deviation must meet the certification basis of the airplane, and the approval must specifically refer to this AD.
For more information about this AD, contact Courtney Tuck, Aerospace Engineer, Cabin Safety and Environmental Systems Section, FAA, Seattle ACO Branch, 2200 South 216th St., Des Moines, WA 98198; phone and fax: 206-231-3986; email:
(1) The Director of the Federal Register approved the incorporation by reference (IBR) of the service information listed in this paragraph under 5 U.S.C. 552(a) and 1 CFR part 51.
(2) You must use this service information as applicable to do the actions required by this AD, unless the AD specifies otherwise.
(i) Boeing Alert Requirements Bulletin B787-81205-SB380021-00 RB, Issue 001, dated August 12, 2022.
(ii) [Reserved]
(3) For service information identified in this AD, contact Boeing Commercial Airplanes, Attention: Contractual & Data Services (C&DS), 2600 Westminster Blvd., MC 110-SK57, Seal Beach, CA 90740-5600; telephone 562-797-1717; website
(4) You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
(5) You may view this service information that is incorporated by reference at the National Archives and Records Administration (NARA). For information on the availability of this material at NARA,
Federal Aviation Administration (FAA), DOT.
Notice of proposed rulemaking (NPRM).
The FAA proposes to adopt a new airworthiness directive (AD) for certain Airbus SAS Model A350-941 and -1041 airplanes. This proposed AD was prompted by a determination that the surface protection is missing between certain aluminum brackets and the struts to which they are attached in the flight deck air distribution system. This proposed AD would require applying surface protection to the affected aluminum brackets and struts, as specified in a European Union Aviation Safety Agency (EASA) AD, which is proposed for incorporation by reference (IBR). This proposed AD would also prohibit modifying an airplane using certain service information. The FAA is proposing this AD to address the unsafe condition on these products.
The FAA must receive comments on this proposed AD by January 27, 2023.
You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:
•
•
•
•
• For material that is proposed for IBR in this NPRM, contact EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; telephone +49 221 8999 000; email
• You may view this material at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195. It is also available in the AD docket at
Dan Rodina, Aerospace Engineer, Large Aircraft Section, FAA, International Validation Branch, 2200 South 216th St., Des Moines, WA 98198; telephone 206-231-3225; email
The FAA invites you to send any written relevant data, views, or arguments about this proposal. Send your comments to an address listed under
Except for Confidential Business Information (CBI) as described in the following paragraph, and other information as described in 14 CFR 11.35, the FAA will post all comments received, without change, to
CBI is commercial or financial information that is both customarily and actually treated as private by its owner. Under the Freedom of Information Act (FOIA) (5 U.S.C. 552), CBI is exempt from public disclosure. If your comments responsive to this NPRM contain commercial or financial information that is customarily treated as private, that you actually treat as
EASA, which is the Technical Agent for the Member States of the European Union, has issued EASA AD 2022-0119, dated June 21, 2022 (EASA AD 2022-0119) (also referred to as the MCAI), to correct an unsafe condition for certain Airbus SAS Model A350-941 and -1041 airplanes.
This proposed AD was prompted by a determination that the surface protection is missing between certain aluminum brackets and the struts to which they are attached in the flight deck air distribution system. The affected parts were installed either in production through Airbus modification 109229 or 109230, or in-service through accomplishing the original issue of Airbus Service Bulletin A350-21-P031; or the original issue of Airbus Service Bulletin A350-21-P032. The FAA is proposing this AD to address missing aluminum bracket surface protection. This condition, if not corrected, could lead to rupture of the associated ducting, reducing the efficiency of the flight deck air distribution system, which, in combination with smoke in the flight deck, could result in impaired flightcrew capability to control the airplane. See the MCAI for additional background information.
EASA AD 2022-0119 specifies procedures for applying surface protection to aluminum brackets and struts at frame (FR) 22 and FR 24, as applicable, in zone C2-2 forward section. EASA AD 2020-0119 also prohibits modifying an airplane using certain service information. This material is reasonably available because the interested parties have access to it through their normal course of business or by the means identified in the
These products have been approved by the aviation authority of another country and are approved for operation in the United States. Pursuant to the FAA's bilateral agreement with the State of Design Authority, it has notified the FAA of the unsafe condition described in the MCAI referenced above. The FAA is issuing this NPRM after determining that the unsafe condition described previously is likely to exist or develop in other products of the same type design.
This proposed AD would require accomplishing the actions specified in EASA AD 2022-0119 described previously, except for any differences identified as exceptions in the regulatory text of this proposed AD.
In the FAA's ongoing efforts to improve the efficiency of the AD process, the FAA developed a process to use some civil aviation authority (CAA) ADs as the primary source of information for compliance with requirements for corresponding FAA ADs. The FAA has been coordinating this process with manufacturers and CAAs. As a result, the FAA proposes to incorporate EASA AD 2022-0119 by reference in the FAA final rule. This proposed AD would, therefore, require compliance with EASA AD 2022-0119 in its entirety through that incorporation, except for any differences identified as exceptions in the regulatory text of this proposed AD. Using common terms that are the same as the heading of a particular section in EASA AD 2022-0119 does not mean that operators need comply only with that section. For example, where the AD requirement refers to “all required actions and compliance times,” compliance with this AD requirement is not limited to the section titled “Required Action(s) and Compliance Time(s)” in EASA AD 2022-0119. Service information required by EASA AD 2022-0119 for compliance will be available at
The FAA estimates that this proposed AD would affect 30 airplanes of U.S. registry. The FAA estimates the following costs to comply with this proposed AD:
Title 49 of the United States Code specifies the FAA's authority to issue rules on aviation safety. Subtitle I, section 106, describes the authority of the FAA Administrator. Subtitle VII: Aviation Programs, describes in more detail the scope of the Agency's authority.
The FAA is issuing this rulemaking under the authority described in Subtitle VII, Part A, Subpart III, Section 44701: General requirements. Under that section, Congress charges the FAA with promoting safe flight of civil aircraft in air commerce by prescribing regulations for practices, methods, and procedures the Administrator finds necessary for safety in air commerce. This regulation is within the scope of that authority because it addresses an unsafe condition that is likely to exist or develop on products identified in this rulemaking action.
The FAA determined that this proposed AD would not have federalism implications under Executive Order 13132. This proposed AD would not have a substantial direct effect on the States, on the relationship between the national Government and the States, or on the distribution of power and responsibilities among the various levels of government.
For the reasons discussed above, I certify this proposed regulation:
(1) Is not a “significant regulatory action” under Executive Order 12866,
(2) Would not affect intrastate aviation in Alaska, and
(3) Would not have a significant economic impact, positive or negative, on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.
Air transportation, Aircraft, Aviation safety, Incorporation by reference, Safety.
Accordingly, under the authority delegated to me by the Administrator, the FAA proposes to amend 14 CFR part 39 as follows:
49 U.S.C. 106(g), 40113, 44701.
The FAA must receive comments on this airworthiness directive (AD) by January 27, 2023.
None.
This AD applies to Airbus SAS Model A350-941 and -1041 airplanes, certificated in any category, as identified in European Union Aviation Safety Agency (EASA) AD 2022-0119, dated June 21, 2022 (EASA AD 2022-0119).
Air Transport Association (ATA) of America Code 21, Air conditioning.
This AD was prompted by a determination that the surface protection is missing between certain aluminum brackets and the struts to which they are attached in the flight deck air distribution system. The FAA is issuing this AD to address missing aluminum bracket surface protection. This condition, if not corrected, could lead to rupture of the associated ducting, reducing the efficiency of the flight deck air distribution system, which, in combination with smoke in the flight deck, could result in impaired flightcrew capability to control the airplane.
Comply with this AD within the compliance times specified, unless already done.
Except as specified in paragraph (h) of this AD: Comply with all required actions and compliance times specified in, and in accordance with, EASA AD 2022-0119.
(1) Where EASA AD 2022-0119 refers to its effective date, this AD requires using the effective date of this AD.
(2) The “Remarks” section of EASA AD 2022-0119 does not apply to this AD.
The following provisions also apply to this AD:
(1)
(2)
(3)
For more information about this AD, contact Dan Rodina, Aerospace Engineer, Large Aircraft Section, FAA, International Validation Branch, 2200 South 216th St., Des Moines, WA 98198; telephone 206-231-3225; email
(1) The Director of the Federal Register approved the incorporation by reference (IBR) of the service information listed in this paragraph under 5 U.S.C. 552(a) and 1 CFR part 51.
(2) You must use this service information as applicable to do the actions required by this AD, unless this AD specifies otherwise.
(i) European Union Aviation Safety Agency (EASA) AD 2022-0119, dated June 21, 2022.
(ii) [Reserved]
(3) For EASA AD 2022-0119, contact EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; telephone +49 221 8999 000; email
(4) You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
(5) You may view this service information that is incorporated by reference at the National Archives and Records Administration (NARA). For information on the availability of this material at NARA, email
Federal Aviation Administration (FAA), DOT.
Notice of proposed rulemaking (NPRM).
The FAA proposes to supersede Airworthiness Directive (AD) 2022-09-11, which applies to certain Airbus SAS Model A350-941 and -1041 airplanes. AD 2022-09-11 requires revising the existing maintenance or inspection program, as applicable, to incorporate new or more restrictive airworthiness limitations. Since the FAA issued AD 2022-09-11, the FAA has determined that new or more restrictive airworthiness limitations are necessary. This proposed AD would continue to require the actions in AD 2022-09-11 and require revising the existing maintenance or inspection program, as applicable, to incorporate new or more restrictive airworthiness limitations, as specified in a European Union Aviation Safety Agency (EASA) AD, which is proposed for incorporation by reference. The FAA is proposing this
The FAA must receive comments on this proposed AD by January 27, 2023.
You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:
•
•
•
•
• For material that is proposed for incorporation by reference (IBR) in this NPRM, contact EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; telephone +49 221 8999 000; email
• You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
Dat Le, Aerospace Engineer, Large Aircraft Section, FAA, International Validation Branch, 2200 South 216th St., Des Moines, WA 98198; telephone 516-228-7317; email
The FAA invites you to send any written relevant data, views, or arguments about this proposal. Send your comments to an address listed under
Except for Confidential Business Information (CBI) as described in the following paragraph, and other information as described in 14 CFR 11.35, the FAA will post all comments received, without change, to
CBI is commercial or financial information that is both customarily and actually treated as private by its owner. Under the Freedom of Information Act (FOIA) (5 U.S.C. 552), CBI is exempt from public disclosure. If your comments responsive to this NPRM contain commercial or financial information that is customarily treated as private, that you actually treat as private, and that is relevant or responsive to this NPRM, it is important that you clearly designate the submitted comments as CBI. Please mark each page of your submission containing CBI as “PROPIN.” The FAA will treat such marked submissions as confidential under the FOIA, and they will not be placed in the public docket of this NPRM. Submissions containing CBI should be sent to Dat Le, Aerospace Engineer, Large Aircraft Section, FAA, International Validation Branch, 2200 South 216th St., Des Moines, WA 98198; telephone 516-228-7317; email
The FAA issued AD 2022-09-11, Amendment 39-22031 (87 FR 29819, May 17, 2022) (AD 2022-09-11), which applies to certain Airbus SAS Model A350-941 and -1041 airplanes. AD 2022-09-11 requires revising the existing maintenance or inspection program, as applicable, to incorporate new or more restrictive airworthiness limitations. The FAA issued AD 2022-09-11 to address reduced structural integrity of the airplane.
Since the FAA issued AD 2022-09-11, the FAA has determined that new or more restrictive airworthiness limitations are necessary.
EASA, which is the Technical Agent for the Member States of the European Union, has issued EASA AD 2022-0125, dated June 28, 2022 (EASA AD 2022-0125) (also referred to as the MCAI), to correct an unsafe condition for all Airbus SAS Model A350-941 and -1041 airplanes. EASA AD 2022-0125 superseded EASA AD 2021-0207, dated September 15, 2021 (EASA AD 2021-0207) (which corresponds to FAA AD 2022-09-11).
Airplanes with an original airworthiness certificate or original export certificate of airworthiness issued after May 2, 2022 must comply with the airworthiness limitations specified as part of the approved type design and referenced on the type certificate data sheet; this proposed AD therefore does not include those airplanes in the applicability.
This proposed AD was prompted by a determination that new or more restrictive airworthiness limitations are necessary. The FAA is proposing this AD to address reduced structural integrity of the airplane. See the MCAI for additional background information.
EASA AD 2022-0125 specifies new or more restrictive airworthiness limitations for airplane structures and safe life limits.
This proposed AD would also require EASA AD 2021-0207, dated September 15, 2021, which the Director of the Federal Register approved for incorporation by reference as of June 21, 2022 (87 FR 29819, May 17, 2022).
This material is reasonably available because the interested parties have access to it through their normal course of business or by the means identified in the
These products have been approved by the aviation authority of another country and are approved for operation in the United States. Pursuant to the FAA's bilateral agreement with the State of Design Authority, it has notified the FAA of the unsafe condition described in the MCAI described above. The FAA is issuing this NPRM after determining that the unsafe condition described previously is likely to exist or develop in other products of these same type designs.
This proposed AD would retain the requirements of AD 2022-09-11. This proposed AD would also require revising the existing maintenance or inspection program, as applicable, to incorporate additional new or more restrictive airworthiness limitations, which are specified in EASA AD 2022-0125 described previously, as proposed for incorporation by reference. Any differences with EASA AD 2022-0125 are identified as exceptions in the regulatory text of this AD.
This proposed AD would require revisions to certain operator maintenance documents to include new actions (
In the FAA's ongoing efforts to improve the efficiency of the AD process, the FAA developed a process to use some civil aviation authority (CAA) ADs as the primary source of information for compliance with requirements for corresponding FAA ADs. The FAA has been coordinating this process with manufacturers and CAAs. As a result, the FAA proposes to retain the IBR of EASA AD 2021-0207 and incorporate EASA AD 2022-0125 by reference in the FAA final rule. This proposed AD would, therefore, require compliance with EASA AD 2021-0207 and EASA AD 2022-0125 in their entirety through that incorporation, except for any differences identified as exceptions in the regulatory text of this proposed AD. Using common terms that are the same as the heading of a particular section in EASA AD 2021-0207 or EASA AD 2022-0125 does not mean that operators need comply only with that section. For example, where the AD requirement refers to “all required actions and compliance times,” compliance with this AD requirement is not limited to the section titled “Required Action(s) and Compliance Time(s)” in EASA AD 2021-0207 or EASA AD 2022-0125. Service information required by EASA AD 2021-0207 and EASA AD 2022-0125 for compliance will be available at
The FAA's process of incorporating by reference MCAI ADs as the primary source of information for compliance with corresponding FAA ADs has been limited to certain MCAI ADs (primarily those with service bulletins as the primary source of information for accomplishing the actions required by the FAA AD). However, the FAA is now expanding the process to include MCAI ADs that require a change to airworthiness limitation documents, such as airworthiness limitation sections.
For these ADs that incorporate by reference an MCAI AD that changes airworthiness limitations, the FAA requirements are unchanged. Operators must revise the existing maintenance or inspection program, as applicable, to incorporate the information specified in the new airworthiness limitation document. The airworthiness limitations must be followed according to 14 CFR 91.403(c) and 91.409(e).
The previous format of the airworthiness limitation ADs included a paragraph that specified that no alternative actions (
The FAA estimates that this proposed AD affects 30 airplanes of U.S. registry. The FAA estimates the following costs to comply with this proposed AD:
The FAA estimates the total cost per operator for the retained actions from AD 2022-09-11 to be $7,650 (90 work-hours × $85 per work-hour).
The FAA has determined that revising the existing maintenance or inspection program takes an average of 90 work-hours per operator, although the agency recognizes that this number may vary from operator to operator. Since operators incorporate maintenance or inspection program changes for their affected fleet(s), the FAA has determined that a per-operator estimate is more accurate than a per-airplane estimate.
The FAA estimates the total cost per operator for the new proposed actions to be $7,650 (90 work-hours × $85 per work-hour).
Title 49 of the United States Code specifies the FAA's authority to issue rules on aviation safety. Subtitle I, section 106, describes the authority of the FAA Administrator. Subtitle VII: Aviation Programs, describes in more detail the scope of the Agency's authority.
The FAA is issuing this rulemaking under the authority described in Subtitle VII, Part A, Subpart III, Section 44701: General requirements. Under that section, Congress charges the FAA with promoting safe flight of civil aircraft in air commerce by prescribing regulations for practices, methods, and procedures the Administrator finds necessary for safety in air commerce. This regulation is within the scope of that authority because it addresses an unsafe condition that is likely to exist or develop on products identified in this rulemaking action.
The FAA determined that this proposed AD would not have federalism implications under Executive Order 13132. This proposed AD would not have a substantial direct effect on the States, on the relationship between the national Government and the States, or on the distribution of power and responsibilities among the various levels of government.
For the reasons discussed above, I certify this proposed regulation:
(1) Is not a “significant regulatory action” under Executive Order 12866,
(2) Would not affect intrastate aviation in Alaska, and
(3) Would not have a significant economic impact, positive or negative, on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.
Air transportation, Aircraft, Aviation safety, Incorporation by reference, Safety.
Accordingly, under the authority delegated to me by the Administrator, the FAA proposes to amend 14 CFR part 39 as follows:
49 U.S.C. 106(g), 40113, 44701.
The FAA must receive comments on this airworthiness directive (AD) by January 27, 2023.
This AD replaces AD 2022-09-11, Amendment 39-22031 (87 FR 29819, May 17, 2022) (AD 2022-09-11).
This AD applies to Airbus SAS Model A350-941 and -1041 airplanes, certificated in any category, with an original airworthiness certificate or original export certificate of airworthiness issued on or before May 2, 2022.
Air Transport Association (ATA) of America Code 05, Time Limits/Maintenance Checks.
This AD was prompted by a determination that new or more restrictive airworthiness limitations are necessary. The FAA is issuing this AD to address reduced structural integrity of the airplane.
Comply with this AD within the compliance times specified, unless already done.
This paragraph restates the requirements of paragraph (j) of AD 2022-09-11, with no changes. For airplanes with an original airworthiness certificate or original export certificate of airworthiness issued on or before June 30, 2021: Except as specified in paragraph (h) of this AD, comply with all required actions and compliance times specified in, and in accordance with, European Union Aviation Safety Agency (EASA) AD 2021-0207, dated September 15, 2021 (EASA AD 2021-0207). Accomplishing the revision of the existing maintenance or inspection program required by paragraph (j) of this AD terminates the requirements of this paragraph.
This paragraph restates the requirements of paragraph (k) of AD 2022-09-11, with no changes.
(1) Where EASA AD 2021-0207 refers to its effective date, this AD requires using June 21, 2022 (the effective date of AD 2022-09-11).
(2) The requirements specified in paragraphs (1) and (2) of EASA AD 2021-0207 do not apply to this AD.
(3) Paragraph (3) of EASA AD 2021-0207 specifies revising “the approved AMP” within 12 months after its effective date, but this AD requires revising the existing maintenance or inspection program, as applicable, within 90 days after June 21, 2022 (the effective date of AD 2022-09-11).
(4) The initial compliance time for doing the tasks specified in paragraph (3) of EASA 2021-0207 is at the “applicable thresholds” as incorporated by the requirements of paragraph (3) of EASA AD 2021-0207, or within 90 days after June 21, 2022 (the effective date of AD 2022-09-11), whichever occurs later.
(5) The provisions specified in paragraphs (4) and (5) of EASA AD 2021-0207 do not apply to this AD.
(6) The “Remarks” section of EASA AD 2021-0207 does not apply to this AD.
This paragraph restates the requirements of paragraph (l) of AD 2022-09-11, with a new exception. Except as required by paragraph (j) of this AD, after the existing maintenance or inspection program has been revised as required by paragraph (g) of this AD, no alternative actions (
Except as specified in paragraph (k) of this AD: Comply with all required actions and compliance times specified in, and in accordance with, EASA AD 2022-0125, dated June 28, 2022 (EASA AD 2022-0125). Accomplishing the revision of the existing maintenance or inspection program required by this paragraph terminates the requirements of paragraph (g) of this AD.
(1) Where EASA AD 2022-0125 refers to its effective date, this AD requires using the effective date of this AD.
(2) The requirements specified in paragraphs (1) and (2) of EASA AD 2022-0125 do not apply to this AD.
(3) Paragraph (3) of EASA AD 2022-0125 specifies revising “the approved AMP” within 12 months after its effective date, but this AD requires revising the existing maintenance or inspection program, as applicable, within 90 days after the effective date of this AD.
(4) The initial compliance time for doing the tasks specified in paragraph (3) of EASA AD 2022-0125 is at the applicable “thresholds” as incorporated by the requirements of paragraph (3) of EASA AD 2022-0125, or within 90 days after the effective date of this AD, whichever occurs later.
(5) The provisions specified in paragraphs (4) and (5) of EASA AD 2022-0125 do not apply to this AD.
(6) The “Remarks” section of EASA AD 2022-0125 does not apply to this AD.
After the existing maintenance or inspection program has been revised as required by paragraph (j) of this AD, no alternative actions (
The following provisions also apply to this AD:
(1)
(2)
For more information about this AD, contact Dat Le, Aerospace Engineer, Large Aircraft Section, FAA, International Validation Branch, 2200 South 216th St., Des Moines, WA 98198; telephone 516-228-7317; email
(1) The Director of the Federal Register approved the incorporation by reference (IBR) of the service information listed in this paragraph under 5 U.S.C. 552(a) and 1 CFR part 51.
(2) You must use this service information as applicable to do the actions required by this AD, unless this AD specifies otherwise.
(3) The following service information was approved for IBR on [DATE 35 DAYS AFTER PUBLICATION OF THE FINAL RULE].
(i) European Union Aviation Safety Agency (EASA) AD 2022-0125, dated June 28, 2022.
(ii) [Reserved]
(4) The following service information was approved for IBR on June 21, 2022 (87 FR 29819, May 17, 2022).
(i) European Union Aviation Safety Agency AD 2021-0207, dated September 15, 2021.
(ii) [Reserved]
(5) For EASA AD 2022-0125 and AD 2021-0207, contact EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; telephone +49 221 8999 000; email
(6) You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
(7) You may view this service information that is incorporated by reference at the National Archives and Records Administration (NARA). For information on the availability of this material at NARA, email
Federal Aviation Administration (FAA), DOT.
Notice of proposed rulemaking (NPRM).
The FAA proposes to supersede Airworthiness Directive (AD) 2015-09-04 R1, which applies to DG Flugzeugbau GmbH Model DG-1000T gliders equipped with a Solo Kleinmotoren GmbH (currently Solo Vertriebs-und Entwicklungs-GmbH) (Solo) Model 2350 C engine. AD 2015-09-04 R1 prohibits operation of the engine and requires performing a magnetic particle or dye penetrant inspection of the propeller shaft and reporting the results of the inspection to Solo. This proposed AD is prompted by mandatory continuing airworthiness information (MCAI) originated by an aviation authority of another country to identify and correct an unsafe condition on an aviation product. The MCAI identifies the unsafe condition as occurrences of rupture of the eccentric axle on Solo Model 2350 C engines (installed on DG Flugzeugbau GmbH Model DG-1000T gliders in the United States) and an occurrence on a Solo Model 2350 D engine (installed on Schempp-Hirth Flugzeugbau GmbH (Schempp-Hirth) Model Duo Discus T gliders in the United States). This proposed AD would require repetitive replacement of the eccentric axle, would add the Schempp-Hirth Model Duo Discus T gliders to the applicability, and would retain from AD 2015-09-04 R1 the option of operating the glider with the engine non-operative instead of replacing the eccentric axle. The FAA is proposing this AD to address the unsafe condition on these products.
The FAA must receive comments on this NPRM by January 27, 2023.
You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:
•
•
•
•
• For service information identified in this NPRM, contact Solo Kleinmotoren GmbH, Postfach 600152, D71050 Sindelfingen, Germany; phone: +49 703 1301-0; fax: +49 703 1301-136; email:
• You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 901 Locust, Kansas City, MO 64106. For information on the availability of this material at the FAA, call (817) 222-5110.
Jim Rutherford, Aviation Safety Engineer, General Aviation & Rotorcraft Section, International Validation Branch, FAA, 901 Locust, Room 301, Kansas City, MO 64106; phone: (816) 329-4165; email:
The FAA invites you to send any written relevant data, views, or arguments about this proposal. Send your comments to an address listed under
Except for Confidential Business Information (CBI) as described in the following paragraph, and other information as described in 14 CFR 11.35, the FAA will post all comments received, without change, to regulations.gov, including any personal information you provide. The agency will also post a report summarizing each substantive verbal contact received about this NPRM.
CBI is commercial or financial information that is both customarily and actually treated as private by its owner. Under the Freedom of Information Act (FOIA) (5 U.S.C. 552), CBI is exempt from public disclosure. If your comments responsive to this NPRM contain commercial or financial information that is customarily treated as private, that you actually treat as private, and that is relevant or responsive to this NPRM, it is important that you clearly designate the submitted comments as CBI. Please mark each page of your submission containing CBI as “PROPIN.” The FAA will treat such marked submissions as confidential under the FOIA, and they will not be placed in the public docket of this NPRM. Submissions containing CBI should be sent to Jim Rutherford, Aviation Safety Engineer, General Aviation & Rotorcraft Section, International Validation Branch, FAA, 901 Locust, Room 301, Kansas City, MO 64106. Any commentary that the FAA receives which is not specifically designated as CBI will be placed in the public docket for this rulemaking.
The FAA issued AD 2015-09-04 R1, Amendment 39-18492 (81 FR 26124, May 2, 2016) (AD 2015-09-04 R1), for DG Flugzeugbau GmbH Model DG-1000T gliders equipped with a Solo Model 2350 C engine. AD 2015-09-04 R1 was prompted by MCAI originated by the European Aviation Safety Agency (now European Union Aviation Safety Agency) (EASA), which is the Technical Agent for the Member States of the European Union. EASA issued AD 2015-0052R1, dated November 19, 2015 (EASA AD 2015-0052R1), to correct an
AD 2015-09-04 R1 prohibits operation of the engine and requires performing a magnetic particle or dye penetrant inspection of the propeller shaft and reporting the results of the inspection to Solo. The FAA issued AD 2015-09-04 R1 to prevent failure of the engine shaft with consequent propeller detachment that could result in damage to the glider or injury of persons on the ground.
Since the FAA issued AD 2015-09-04 R1, EASA superseded AD 2015-0052R1 and issued EASA AD 2022-0044R1, dated April 29, 2022 (referred to hereafter as “the MCAI”). The MCAI states an occurrence of rupture of the eccentric axle on a Solo Model 2350 D engine (installed on Schempp-Hirth Model Duo Discus T gliders in the United States). The MCAI specifies replacing the eccentric axle with a new part and establishing a life limit for this part. You may examine the MCAI in the AD docket at regulations.gov under Docket No. FAA-2022-1406.
The FAA reviewed Solo Kleinmotoren GmbH Technische Mitteilung (English translation: Service Bulletin), Nr. 4603-19, Ausgabe (English translation: dated) January 31, 2022, which specifies procedures for replacing the eccentric axle with eccentric axle part number (P/N) 2031211V2 for Solo Model 2350 D engines, which are installed on Schempp-Hirth Model Duo Discus T gliders in the United States.
This material is reasonably available because the interested parties have access to it through their normal course of business or by the means identified in
These products have been approved by the aviation authority of another country and are approved for operation in the United States. Pursuant to the FAA's bilateral agreement with this State of Design Authority, it has notified the FAA of the unsafe condition described in the MCAI described above. The FAA is issuing this NPRM after determining that the unsafe condition described previously is likely to exist or develop on other products of these same type designs.
This proposed AD would retain a certain action from AD 2015-09-04 R1. The operating limitation for the DG Flugzeugbau GmbH Model DG-1000T gliders equipped with a Solo Model 2350 C would continue to be allowed by the proposed AD instead of replacing the eccentric axle. This proposed AD would also add the Schempp-Hirth Model Duo Discus T gliders equipped with a Solo Model 2350 D engine to the applicability, and require repetitive replacement of the eccentric axle. This proposed AD would also require incorporation of the final rule into the Limitations section of the existing aircraft flight manual for your glider if the operator chooses to operate the glider with the engine inoperative. The proposed incorporation of the operating limitation into the flight manual of the glider and removal of the operating limitation may be performed by the owner/operator (pilot) holding at least a private pilot certificate and must be entered into the aircraft records showing compliance in accordance with 14 CFR 43.9(a) and 14 CFR 91.417(a)(2)(v). The record must be maintained as required by 14 CFR 91.417, 121.380, or 135.439. The proposed incorporation of the operating limitation into the flight manual of the glider and removal of the operating limitation are not considered maintenance actions and may be done equally by a pilot or a mechanic and are exceptions to the FAA's standard practice.
The MCAI, for the DG Flugzeugbau GmbH Model DG-1000T gliders equipped with a Solo Model 2350 C engine, has a compliance time for the initial eccentric axle replacement based on the effective date of superseded EASA AD 2015-0052-E, dated March 27, 2015. This proposed AD would have a compliance time for these gliders based on the effective date of the final rule because there was not a requirement in AD 2015-09-04 R1 to replace the eccentric axle.
The FAA estimates that this AD, if adopted as proposed, would affect 8 gliders of U.S. registry. The FAA estimates the following costs to comply with this proposed AD:
If any operator chooses to not replace the eccentric axle and instead operates the glider with the engine inoperative, the proposed operating limitation incorporation would take .5 work-hour at $85 per hour for a total of $42.50 per airplane. If at any time after, the operator chooses to remove the operating limitation, this proposed action would also take .5 work-hour at $85 per hour for a total of $42.50 per airplane.
Title 49 of the United States Code specifies the FAA's authority to issue rules on aviation safety. Subtitle I, section 106, describes the authority of the FAA Administrator. Subtitle VII, Aviation Programs, describes in more detail the scope of the Agency's authority.
The FAA is issuing this rulemaking under the authority described in Subtitle VII, Part A, Subpart III, Section 44701: General requirements. Under that section, Congress charges the FAA with promoting safe flight of civil aircraft in air commerce by prescribing regulations for practices, methods, and procedures the Administrator finds necessary for safety in air commerce. This regulation is within the scope of that authority because it addresses an unsafe condition that is likely to exist or develop on products identified in this rulemaking action.
The FAA determined that this proposed AD would not have federalism implications under Executive Order 13132. This proposed AD would not have a substantial direct effect on the States, on the relationship between the national Government and the States, or on the distribution of power and responsibilities among the various levels of government.
For the reasons discussed above, I certify that the proposed regulation:
(1) Is not a “significant regulatory action” under Executive Order 12866,
(2) Would not affect intrastate aviation in Alaska, and
(3) Would not have a significant economic impact, positive or negative, on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.
Air transportation, Aircraft, Aviation safety, Incorporation by reference, Safety.
Accordingly, under the authority delegated to me by the Administrator, the FAA proposes to amend 14 CFR part 39 as follows:
49 U.S.C. 106(g), 40113, 44701.
a. Removing Airworthiness Directive 2015-09-04 R1, Amendment 39-18492 (81 FR 26124, May 2, 2016); and
b. Adding the following new airworthiness directive:
The FAA must receive comments on this airworthiness directive (AD) by January 27, 2023.
This AD replaces AD 2015-09-04 R1, Amendment 39-18492 (81 FR 26124, May 2, 2016).
This AD applies to DG Flugzeugbau GmbH Model DG-1000T gliders and Schempp-Hirth Flugzeugbau GmbH (Schempp-Hirth) Model Duo Discus T gliders, all serial numbers, certificated in any category, with a Solo Vertriebs- und Entwicklungs-GmbH (previously Solo Kleinmotoren GmbH) (Solo) Model 2350 C or Model 2350 D engine installed.
Joint Aircraft System Component (JASC) Code 7200, Engine (Turbine/Turboprop).
This AD was prompted by occurrences of rupture of the eccentric axle on Solo Model 2350 C engines (installed on DG Flugzeugbau GmbH Model DG-1000T gliders in the United States) and an occurrence on a Solo Model 2350 D engine (installed on Schempp-Hirth Model Duo Discus T gliders in the United States). The FAA is issuing this AD to prevent failure of the engine shaft with consequent propeller detachment. The unsafe condition, if not addressed, could result in damage to the glider or injury of persons on the ground.
Comply with this AD within the compliance times specified, unless already done.
(1) For DG Flugzeugbau GmbH Model DG-1000T gliders equipped with a Solo Model 2350 C engine, before further flight after the effective date of this AD, replace each eccentric axle that is not part number (P/N) 2031211V2 with an eccentric axle that is P/N 2031211V2 that has zero hours time-in-service (TIS).
DG Flugzeugbau Technical Note 1000/26, dated September 23, 2015, contains information related to replacing the eccentric axle specific for the DG Flugzeugbau GmbH Model DG-1000T gliders. Solo Kleinmotoren GmbH Technische Mitteilung (English translation: Service Bulletin), Nr. 4603-17, Ausgabe (English translation: dated) July 15, 2015, contains information related to replacing the eccentric axle for the Solo Model 2350 C engine, but is not specific to the DG Flugzeugbau GmbH Model DG-1000T gliders.
(2) For Schempp-Hirth Model Duo Discus T gliders equipped with a Solo Model 2350 D engine, within 30 hours TIS of engine operation after the effective date of this AD, replace each eccentric axle that is not P/N 2031211V2 with an eccentric axle that is P/N 2031211V2 that has zero hours TIS in accordance with Action 1, Note 2, and Pictures 1 through 6 of Solo Kleinmotoren GmbH Technische Mitteilung (English translation: Service Bulletin), Nr. 4603-19, Ausgabe (English translation: dated) January 31, 2022.
This service information contains German to English translation. The European Union Aviation Safety Agency (EASA) used the English translation in referencing the document. For enforceability purposes, the FAA will refer to the Solo Kleinmotoren service information in English as it appears on the document.
(3) For all gliders, after the initial replacement required by paragraph (g)(1) or (2) of this AD, as applicable, or if an eccentric axle P/N 2031211V2 was installed as of the effective date of this AD, within intervals not to exceed 50 hours TIS of engine operation, replace each eccentric axle P/N 2031211V2 with an eccentric axle P/N 2031211V2 that has zero hours TIS as specified in paragraph (g)(1) or (2) of this AD, as applicable.
(4) It is allowed to operate a glider having a Solo Model 2350 C or Model 2350 D engine installed with the engine inoperative instead of replacing the eccentric axle. To operate with the engine inoperative, place a copy of this AD into the Limitations section of the existing aircraft flight manual for your glider and do not operate the engine.
(i) Remove this operating limitation after replacing the eccentric axle as required by paragraphs (g)(1) or (2) and (3) of this AD.
(ii) Both the incorporation and removal of the operating limitation may be performed by the owner/operator (pilot) holding at least a private pilot certificate and must be entered into the aircraft records showing compliance with this AD in accordance with §§ 43.9(a) and 91.417(a)(2)(v). The record must be maintained as required by § 91.417, 121.380, or 135.439.
The Manager, International Validation Branch, FAA, has the authority to approve AMOCs for this AD, if requested using the procedures found in § 39.19. In accordance with § 39.19, send your request to your principal inspector or local Flight Standards District Office, as appropriate. If sending information directly to the manager of the International Validation Branch, mail it to the address identified in paragraph (i)(2) of this AD or email to:
(1) Refer to EASA AD 2022-0044R1, dated April 29, 2022, for related information. This EASA AD may be found in the AD docket at regulations under Docket No. FAA-2022-1406.
(2) For more information about this AD, contact Jim Rutherford, Aviation Safety Engineer, General Aviation & Rotorcraft Section, International Validation Branch, FAA, 901 Locust, Room 301, Kansas City, MO 64106; phone: (816) 329-4165; email:
(3) For DG Flugzeugbau service information identified in this AD that is not incorporated by reference, contact DG Flugzeugbau GmbH, Otto-Lilienthal Weg 2, D-76646 Bruchsal, Germany; phone: +49 (0)7251 3202-0; email:
(4) Solo service information identified in this AD that is not incorporated by reference is available at the addresses specified in paragraphs (j)(3) and (4) of this AD.
(1) The Director of the Federal Register approved the incorporation by reference (IBR) of the service information listed in this paragraph under 5 U.S.C. 552(a) and 1 CFR part 51.
(2) You must use this service information as applicable to do the actions required by this AD, unless the AD specifies otherwise.
(i) Solo Kleinmotoren GmbH Technische Mitteilung (English translation: Service Bulletin), Nr. 4603-19, Ausgabe (English translation: dated) January 31, 2022.
This service information contains German to English
(ii) [Reserved]
(3) For Solo service information identified in this AD, contact Solo Kleinmotoren GmbH, Postfach 600152, D71050 Sindelfingen, Germany; phone: +49 703 1301-0; fax: +49 703 1301-136; email:
(4) You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 901 Locust, Kansas City, MO 64106. For information on the availability of this material at the FAA, call (817) 222-5110.
(5) You may view this service information that is incorporated by reference at the National Archives and Records Administration (NARA). For information on the availability of this material at NARA, email:
Federal Aviation Administration (FAA), Department of Transportation (DOT).
Notice of proposed rulemaking (NPRM).
This action proposes to modify the Class E airspace designated as a surface area and modify the Class E airspace extending upward from 700 feet above the surface at Visalia Municipal Airport, Visalia, CA. This proposal would add and remove extensions of the Class E airspace extending from 700 feet above the surface at the airport. Additionally, this action proposes several administrative amendments to update the airport's existing Class E airspace legal descriptions. These actions will support the safety and management of instrument flight rules (IFR) operations at the airport.
Comments must be received on or before January 27, 2023.
Send comments on this proposal to the U.S. DOT, Docket Operations, 1200 New Jersey Avenue SE, West Building Ground Floor, Room W12-140, Washington, DC 20590; telephone: (800) 647-5527, or (202) 366-9826. You must identify “FAA Docket No. FAA-2022-1445; Airspace Docket No. 21-AWP-55,” at the beginning of your comments. You may also submit comments through the internet at
FAA Order JO 7400.11G, Airspace Designations and Reporting Points, and subsequent amendments can be viewed online at
Raphell P. Taylor, Federal Aviation Administration, Western Service Center, Operations Support Group, 2200 S 216th Street, Des Moines, WA 98198; telephone (405) 666-1176.
The FAA's authority to issue rules regarding aviation safety is found in Title 49 of the United States Code Subtitle I, Section 106 describes the authority of the FAA Administrator. Subtitle VII, Aviation Programs, describes in more detail the scope of the agency's authority. This rulemaking is promulgated under the authority described in Subtitle VII, Part A, Subpart I, Section 40103. Under that section, the FAA is charged with prescribing regulations to assign the use of airspace necessary to ensure the safety of aircraft and the efficient use of airspace. This regulation is within the scope of that authority, as it would modify Class E airspace at Visalia Municipal Airport, Visalia, CA, to support IFR operations at the airport.
Interested parties are invited to participate in this proposed rulemaking by submitting such written data, views, or arguments, as they may desire. Comments that provide the factual basis supporting the views and suggestions presented are particularly helpful in developing reasoned regulatory decisions on the proposal. Comments are specifically invited on the overall regulatory, aeronautical, economic, environmental, and energy-related aspects of the proposal. Communications should identify both docket numbers and be submitted in triplicate to the address listed above. Persons wishing the FAA to acknowledge receipt of their comments on this notice must submit with those comments a self-addressed, stamped postcard on which the following statement is made: “Comments to Docket No. FAA-2022-1445; Airspace Docket No. 21-AWP-55.” The postcard will be date/time stamped and returned to the commenter.
All communications received before the specified closing date for comments will be considered before taking action on the proposed rule. The proposal contained in this notice may be changed in light of the comments received. A report summarizing each substantive public contact with FAA personnel concerned with this rulemaking will be filed in the docket.
An electronic copy of this document may be downloaded through the internet at
You may review the public docket containing the proposal, any comments received, and any final disposition in person in the Dockets Office (see the
This document proposes to amend FAA Order JO 7400.11G, dated August 19, 2022, and effective September 15, 2022. FAA Order JO 7400.11G is publicly available as listed in the
The FAA is proposing an amendment to 14 CFR part 71 by modifying the Class E airspace designated as a surface area and modifying the Class E airspace extending upward from 700 feet above
The Class E airspace designated as a surface area should be expanded from 3.5 nautical miles (NM) to 4 (NM), to properly contain aircraft conducting circling maneuvers. Additionally, the Class E2 extension northwest of the airport is not required and should be removed.
The Class E airspace encircling the airport within a 5-mile radius is excessive and should be reduced. Class E airspace beginning at 700 feet above the surface is designed to contain departing IFR operations until they reach 1,200 feet above the surface, and a 4.5-mile radius encircling the airport is more appropriate. The two existing Class E5 extensions are currently described in relation to the now decommissioned Visalia very high frequency omnidirectional range (VOR) and require modifications. The first extension is within 2.1 miles each side of the 138° bearing from the airport extending from the 4.5-mile radius to 6.6 miles southeast of the airport. The second extension is within 1.8 miles each side of the 314° bearing, from the 4.5-mile radius to 6.6 miles northwest of the airport.
Finally, this action proposes administrative modifications to the airport's legal descriptions. The current Class E5 airspace description includes airspace for Mefford Field Airport, Tulare, CA. The FAA is establishing independent airspace for Mefford Field Airport and the additional airspace should be removed from Visalia Municipal Airport's airspace description. The Visalia VOR/distance measuring equipment (DME) navigational aid should be removed from the Class E2 text header and airspace description. It was decommissioned on March 25th, 2022 and is not needed to describe airspace. The Class E2 legal description should also be updated to replace the outdated use of the phrases “Notice to Airmen” and “Airport/Facility Directory.” These phrases should be amended to read “Notice to Air Missions” and “Chart Supplement,” respectively, to match the FAA's current nomenclature. Finally, Swanson Ranch NR1 Airport should be removed from the Class E5 text header and airspace description, as the airport no longer exists.
Class E2 and E5 airspace designations are published in paragraphs 6002 and 6005, respectively, of FAA Order 7400.11G, dated August 19, 2022, and effective September 15, 2022, which is incorporated by reference in 14 CFR 71.1. The Class E airspace designations listed in this document will be published subsequently in FAA Order JO 7400.11, which is published annually and becomes effective on September 15.
The FAA has determined that this regulation only involves an established body of technical regulations for which frequent and routine amendments are necessary to keep them operationally current, is non-controversial, and unlikely to result in adverse or negative comments. It therefore: (1) is not a “significant regulatory action” under Executive Order 12866; (2) is not a “significant rule” under DOT regulatory policies and procedures (44 FR 11034; February 26, 1979); and (3) does not warrant preparation of a regulatory evaluation as the anticipated impact is so minimal. Since this is a routine matter that will only affect air traffic procedures and air navigation, it is certified that this rule—when promulgated—would not have a significant economic impact on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.
This proposal will be subject to an environmental analysis in accordance with FAA Order 1050.1F, Environmental Impacts: Policies and Procedures, prior to any FAA final regulatory action.
Airspace, Incorporation by reference, Navigation (air).
Accordingly, pursuant to the authority delegated to me, the Federal Aviation Administration proposes to amend 14 CFR part 71 as follows:
49 U.S.C. 106(f), 106(g), 40103, 40113, 40120; E.O. 10854, 24 FR 9565, 3 CFR, 1959-1963 Comp., p. 389.
That airspace extending upward from the surface within a 4-mile radius of the airport. This Class E airspace area is effective during the specific dates and times established in advance by a Notice to Air Missions. The effective date and time will thereafter be continuously published in the Chart Supplement.
That airspace extending upward from 700 feet above the surface within a 4.5-mile radius of the airport, and within 2.1 miles each side of the 138° bearing from the airport extending from the 4.5-mile radius to 6.6 miles southeast of the airport, and within 1.8 miles each side of the 314° bearing from the 4.5-mile radius to 6.6 miles northwest of the airport.
Postal Service
Proposed rule.
The Postal Service is proposing to amend
Submit comments on or before January 12, 2023.
Mail or deliver written comments to the Director, Product Classification, U.S. Postal Service, 475 L'Enfant Plaza SW, Room 4446, Washington, DC 20260-5015. If sending comments by email, include the name and address of the commenter and send to
All submitted comments and attachments are part of the public record and subject to disclosure. Do not enclose any material in your comments that you consider to be confidential or inappropriate for public disclosure.
You may inspect and photocopy all written comments, by appointment only, at USPS® Headquarters Library, 475 L'Enfant Plaza SW, 11th Floor North, Washington, DC, 20260. These records are available for review on Monday through Friday, 9 a.m.-4 p.m., by calling 202-268-2906.
Phong T. Quang at (202) 268-2857 or Garry Rodriguez at (202) 268-7281.
Currently, the Postal Service has no provision for providing a refund to customers who were eligible for Group E (free) P.O. Box
To ensure uniform treatment of customers who were not provided Group E P.O. Box service, the Postal Service is proposing to provide a refund policy if it has been determined that a customer paying for P.O. Box service is entitled to Group E P.O. Box service. A refund of prorated fees may be issued for each full consecutive month preceding the determination, up to a maximum of 24 months. Interest will not be paid on the amount refunded.
The Postal Service is also proposing to make a minor revision to the text in 508.4.5.2c for clarity in the standard.
We believe the proposed revisions will provide customers with a more efficient mailing experience.
Although exempt from the notice and comment requirements of the Administrative Procedure Act (5 U.S.C. 553(b), (c)) regarding proposed rulemaking by 39 U.S.C. 410(a), the Postal Service invites public comment on the following proposed revisions to
We will publish an appropriate amendment to 39 CFR part 111 to reflect these changes.
Administrative practice and procedure, Postal Service.
Accordingly, 39 CFR part 111 is proposed to be amended as follows:
5 U.S.C. 552(a); 13 U.S.C. 301-307; 18 U.S.C. 1692-1737; 39 U.S.C. 101, 401-404, 414, 416, 3001-3018, 3201-3220, 3401-3406, 3621, 3622, 3626, 3629, 3631-3633, 3641, 3681-3685, and 5001.
Customers may qualify for Group E (free) P.O. Box service at a Post Office if their physical address location meets all of the following criteria:
[Revise the first sentence of item c to read as follows:]
c. USPS does not provide carrier delivery to a mail receptacle at or near a physical address for reasons other than those in 4.5.3b. * * *
[Add new 4.6.3 to read as follows:]
If a postmaster determines that a customer paying for P.O. Box service was entitled to Group E (free) P.O. Box service under 4.5.2, a refund of prorated fees may be issued for each full consecutive month preceding the determination, up to a maximum of 24 months. Interest is not paid on the amount refunded.
Environmental Protection Agency (EPA).
Proposed rule.
The Environmental Protection Agency (EPA) is proposing an approval of a revision to the Yolo-Solano Air Quality Management District (YSAQMD) portion of the California State Implementation Plan (SIP). This revision concerns emissions of volatile organic compounds (VOCs) from solvent cleaning and degreasing operations. We are proposing action on a local rule that regulates these emission sources under the Clean Air Act (CAA or the Act). We are taking comments on this proposal and plan to follow with a final action.
Comments must be received on or before January 12, 2023.
Submit your comments, identified by Docket ID No. EPA-R09-OAR-2022-0795 at
Arnold Lazarus, EPA Region IX, (415) 972-3024,
Throughout this document, “we,” “us” and “our” refer to the EPA.
Table 1 lists the rule addressed by this proposal with the date that it was adopted by the local air agency and submitted by the California Air Resources Board (CARB).
There is a previous version of Rule 2.31 in the SIP, revised on April 12, 2017, submitted to us by CARB on August 9, 2017, and finalized with a limited approval and limited disapproval into the SIP on July 30, 2021 (86 FR 40959). If we take final action to approve the July 18, 2022 version of Rule 2.31, this version will replace the previously approved version of this rule in the SIP.
VOCs contribute to the production of ground-level ozone, smog, and particulate matter, which harm human health and the environment. Section 110(a) of the CAA requires states to submit regulations that control emissions of VOCs. The purpose of Rule 2.31 is to limit the emissions of VOCs from solvent cleaning operations and solvent degreasing operations, and from the storage and disposal of materials used for such operations. The EPA's technical support document (TSD) has more information about this rule.
Rules in the SIP must be enforceable (see CAA section 110(a)(2)), must not interfere with applicable requirements concerning attainment and reasonable further progress or other CAA requirements (see CAA section 110(l)), and must not modify certain SIP control requirements in nonattainment areas without ensuring equivalent or greater emissions reductions (see CAA section 193).
Generally, SIP rules must require reasonably available control technology (RACT) for each category of sources covered by a Control Techniques Guidelines (CTG) document as well as each major source of VOCs in ozone nonattainment areas classified as Moderate or above (see CAA section 182(b)(2)). The YSAQMD regulates an ozone nonattainment area classified as Severe nonattainment for the 2008 and 1997 8-hour ozone National Ambient Air Quality Standards (NAAQS);
Guidance and policy documents that we use to evaluate enforceability, revision/relaxation and rule stringency requirements for the applicable criteria pollutants include the following:
1. “State Implementation Plans; General Preamble for the Implementation of Title I of the Clean Air Act Amendments of 1990,” 57 FR 13498 (April 16, 1992); 57 FR 18070 (April 28, 1992).
2. “Issues Relating to VOC Regulation Cutpoints, Deficiencies, and Deviations,” EPA, May 25, 1988 (the Bluebook, revised January 11, 1990).
3. “Guidance Document for Correcting Common VOC & Other Rule Deficiencies,” EPA Region 9, August 21, 2001 (the Little Bluebook).
4. “Control of Volatile Organic Emissions from Solvent Metal Cleaning,” EPA-450/2-77-022, November 1977.
5. “Control Technique Guidelines for Industrial Cleaning Solvents” EPA-453/R-06-001, September 2006.
6. “Control of Volatile Organic Compound Emissions from Coating Operations at Aerospace manufacturing and Rework Operations” EPA-453/R-97-004, December 1997.
7. “Control Technique Guidelines for Flexible Package Printing” EPA 453/R-06-003, September 2006.
Rule 2.31 improves the SIP by eliminating an exemption that was not approvable. The rule is largely consistent with CAA requirements and with relevant guidance regarding enforceability and SIP revisions. The EPA's TSD has more information regarding the EPA's analysis of this rule.
As authorized in sections 110(k)(3) and 301(a) of the Act, the EPA is proposing a full approval of the submitted rule. We will accept comments from the public on this proposal until January 12, 2023. If finalized, this action would incorporate the submitted rule into the SIP.
In this rule, the EPA is proposing to include in a final EPA rule regulatory text that includes incorporation by reference. In accordance with requirements of 1 CFR 51.5, the EPA is proposing to incorporate by reference the YSAQMD Rule 2.31, which regulates VOC emissions from solvent cleaning and degreasing operations. The EPA has made, and will continue to make, these materials available through
Under the CAA, the Administrator is required to approve a SIP submission that complies with the provisions of the Act and applicable Federal regulations. 42 U.S.C. 7410(k); 40 CFR 52.02(a).
• Is not a “significant regulatory action” subject to review by the Office of Management and Budget under Executive Orders 12866 (58 FR 51735, October 4, 1993) and 13563 (76 FR 3821, January 21, 2011);
• Does not impose an information collection burden under the provisions of the Paperwork Reduction Act (44 U.S.C. 3501
• Is certified as not having a significant economic impact on a substantial number of small entities under the Regulatory Flexibility Act (5 U.S.C. 601
• Does not contain any unfunded mandate or significantly or uniquely affect small governments, as described in the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4);
• Does not have federalism implications as specified in Executive Order 13132 (64 FR 43255, August 10, 1999);
• Is not an economically significant regulatory action based on health or safety risks subject to Executive Order 13045 (62 FR 19885, April 23, 1997);
• Is not a significant regulatory action subject to Executive Order 13211 (66 FR 28355, May 22, 2001);
• Is not subject to requirements of Section 12(d) of the National Technology Transfer and Advancement Act of 1995 (15 U.S.C. 272 note) because application of those requirements would be inconsistent with the CAA; and
• The State did not evaluate environmental justice considerations as part of its SIP submittal. There is no information in the record inconsistent with the stated goals of E.O. 12898 of achieving environmental justice for people of color, low-income populations, and indigenous peoples.
In addition, the SIP is not approved to apply on any Indian reservation land or in any other area where the EPA or an Indian tribe has demonstrated that a tribe has jurisdiction. In those areas of Indian country, the proposed rule does not have tribal implications and will not impose substantial direct costs on tribal governments or preempt tribal law as specified by Executive Order 13175 (65 FR 67249, November 9, 2000).
Environmental protection, Air pollution control, Incorporation by reference, Intergovernmental relations, Ozone, Particulate matter, Reporting and recordkeeping requirements, Volatile organic compounds.
42 U.S.C. 7401
Animal and Plant Health Inspection Service, USDA.
Notice of availability; extension of comment period.
We are extending the comment period for a notice of availability of a pest risk assessment and a commodity import evaluation document that we have prepared relative to the importation into the United States of fresh table grapes from regions of Chile where European grapevine moth (
The comment period for the notice published on October 17, 2022 (87 FR 62783-62784) is extended. We will consider all comments that we receive on or before January 17, 2023.
You may submit comments by either of the following methods:
•
•
Supporting documents and any comments we receive on this docket may be viewed at
Ms. Claudia Ferguson, Senior Regulatory Policy Specialist, RCC, IRM, PPQ, APHIS, 4700 River Road, Unit 133, Riverdale, MD 20737-1236; (301) 851-2353;
On October 17, 2022, we published in the
Comments on the notice were required to be received on or before December 16, 2022. We are extending the comment period on Docket No. APHIS-2021-0078 until January 17, 2023. This action will allow interested persons additional time to prepare and submit comments.
Forest Service, (Agriculture) USDA.
Notice of meeting.
The Florida National Forests Resource Advisory Committee (RAC) will hold a public meeting according to the details shown below. The committee is authorized under the Secure Rural Schools and Community Self-Determination Act (the Act) and operates in compliance with the Federal Advisory Committee Act (FACA). The purpose of the committee is to improve collaborative relationships and to provide advice and recommendations to the Forest Service concerning projects and funding consistent with title II of the Act, as well as make recommendations on recreation fee proposals for sites on the National Forests in Florida, consistent with the Federal Lands Recreation Enhancement Act. General information and meeting details can be found at the following website: National Forests in Florida—Advisory Committees (
The meeting will be held on January 17, 2023, 11 a.m.-3 p.m., Eastern Standard Time.
All RAC meetings are subject to cancellation. For status of the meeting prior to attendance, please contact the person listed under
The meeting is open to the public and will be held virtually via telephone and/or video conference. Virtual meeting participation details can be found on the website listed under
Written comments may be submitted as described under
Kelly Russell, Designated Federal Officer (DFO), by phone at 850-523-8500 or email at
The purpose of the meeting is to:
1. Elect a Chairperson;
2. Hear from Title II project proponents and discuss title II project proposals;
3. Make funding recommendations on title II projects;
The meeting is open to the public. The agenda will include time for individuals to make oral statements of three minutes or less. Individuals wishing to make an oral statement should make a request in writing at least three days prior to the meeting date to be scheduled on the agenda. Anyone who would like to bring related matters to the attention of the committee may file written statements with the committee staff before or after the meeting. Written comments and requests for time for oral comments must be sent to Philip Marley, 325 John Knox Rd., Ste. F-210 Tallahassee, FL 32303; or by email
USDA programs are prohibited from discriminating based on race, color, national origin, religion, sex, gender identity (including gender expression), sexual orientation, disability, age, marital status, family/parental status, income derived from a public assistance program, political beliefs, or reprisal or retaliation for prior civil rights activity, in any program or activity conducted or funded by USDA (not all bases apply to all programs). Remedies and complaint filing deadlines vary by program or incident.
Equal opportunity practices in accordance with USDA's policies will be followed in all appointments to the Committee. To ensure that the recommendations of the Committee have taken in account the needs of the diverse groups served by USDA, membership shall include to the extent possible, individuals with demonstrated ability to represent minorities, women, and person with disabilities. USDA is an equal opportunity provider, employer, and lender.
Forest Service, Agriculture (USDA).
Notice of meeting.
The Central Montana Resource Advisory Committee (RAC) will hold a public meeting according to the details shown below. The committee is authorized under the Secure Rural Schools and Community Self-Determination Act (the Act) and operates in compliance with the Federal Advisory Committee Act (FACA). The purpose of the committee is to improve collaborative relationships and to provide advice and recommendations to the Forest Service concerning projects and funding consistent with Title II of the Act, as well as make recommendations on recreation fee proposals for sites on the Helena-Lewis and Clark National Forest, consistent with the Federal Lands Recreation Enhancement Act. General information and meeting details can be found at the following website:
The meeting will be held on January 25, 2023, 1 p.m.-3 p.m., Mountain Standard Time. All RAC meetings are subject to cancellation. For status of the meeting prior to attendance, please contact the person listed under
This meeting is open to the public and will be held at the Judith-Musselshell Ranger District located at 109 Central Ave., Stanford, MT 59479. The public may also join virtually via telephone and/or video conference. Virtual meeting participation details can be found on the website listed under
Written comments may be submitted as described under
Molly Ryan, Designated Federal Officer (DFO), by phone at 406-949-9766 or email at
The purpose of the meeting is to:
1. Hear from Title II project proponents and discuss Title II project proposals;
2. Make funding recommendations on Title II projects;
3. Cover RAC membership planning
The meeting is open to the public. The agenda will include time for individuals to make oral statements of three minutes or less. Individuals wishing to make an oral statement should make a request in writing at least three days prior to the meeting date to be scheduled on the agenda. Anyone who would like to bring related matters to the attention of the committee may file written statements with the committee staff before or after the meeting. Written comments and requests for time for oral comments must be sent to Elizabeth Casselli, 1220 38th Street North, Great Falls, MT 59405; or by email to
USDA programs are prohibited from discriminating based on race, color, national origin, religion, sex, gender identity (including gender expression), sexual orientation, disability, age, marital status, family/parental status, income derived from a public assistance program, political beliefs, or reprisal or retaliation for prior civil rights activity, in any program or activity conducted or funded by USDA (not all bases apply to all programs). Remedies and complaint filing deadlines vary by program or incident.
Equal opportunity practices in accordance with USDA's policies will be followed in all appointments to the Committee. To ensure that the recommendations of the Committee have taken in account the needs of the diverse groups served by USDA, membership shall include to the extent possible, individuals with demonstrated ability to represent minorities, women, and person with disabilities. USDA is an equal opportunity provider, employer, and lender.
Forest Service, Agriculture (USDA).
Notice of meeting.
The Black Hills National Forest Advisory Board (NFAB) will hold a public meeting according to the details shown below. The committee is authorized under the Forest and Rangeland Renewable Resources Planning Act of 1974, the National Forest Management Act of 1976, the Federal Public Lands Recreation Enhancement Act, and operates in compliance with the Federal Advisory Committee Act (FACA). The purpose of the committee is to to provide advice and recommendations on a broad range of forest issues such as forest plan revisions or amendments, forest health including fire, insect and disease, travel management, forest monitoring and evaluation, recreation fees, and site specific projects having forest-wide immplications. General information can be found at the following website:
The meeting will be held on January 18, 2023, 1 p.m.-4:30 p.m., Mountain Standard Time. All commmittee meetings are subject to cancellation. For status of the meeting prior to attendance, please contact the person listed under
This meeting is open to the public and will be held at the U.S. Forest Service, Mystic Ranger District Office, 8221 Mount Rushmore Road, Rapid City, South Dakota 57702. The public may also join virtually via telephone and/or video conference. Virtual meeting participation details can be found on the website listed under
Written comments may be submitted as described under
Scott Jacobson, Committee Coordinator, by phone at 605-440-1409 or email at
The meeting agenda will include:
1. Forest Plan Revision;
2. Recreation Residence Program;
3. Lands Program;
4. Potential Operational Dilineations (PODs); and
5. Long Eared Bat Reclassified as Endangered.
The meeting is open to the public. The agenda will include time for people to make oral statements of three minutes or less. Individuals wishing to make an oral statement should make a request in writing by at least three days before the meeting to be scheduled on the agenda. Anyone who would like to bring related matters to the attention of the committee may file written statements with the committee staff before or after the meeting. Written comments and requests for time for oral comments must be sent to Scott Jacobson, NFAB Committee Coordinator, Mystic Ranger District Office, 8221 Mount Rushmore Road, Rapid City, South Dakota 57702; or by email to
USDA programs are prohibited from discriminating based on race, color, national origin, religion, sex, gender identity (including gender expression), sexual orientation, disability, age, marital status, family/parental status, income derived from a public assistance program, political beliefs, or reprisal or retaliation for prior civil rights activity, in any program or activity conducted or funded by USDA (not all bases apply to all programs). Remedies and complaint filing deadlines vary by program or incident.
Equal opportunity practices in accordance with USDA's policies will be followed in all appointments to the Committee. To ensure that the recommendations of the Committee have taken in account the needs of the diverse groups served by USDA, membership shall include to the extent possible, individuals with demonstrated ability to represent minorities, women, and person with disabilities. USDA is an equal opportunity provider, employer, and lender.
Forest Service, USDA.
Solicitation for members.
The United States Department of Agriculture (USDA), Forest Service is seeking nominations for the Secure Rural School Resource Advisory Committees (SRS RACs) pursuant to the Secure Rural Schools and Community Self-Determination Act (the Act) and the Federal Advisory Committee Act (FACA). Additional information on the SRS RACs can be found by visiting the SRS RACs website at:
Written nominations must be received by February 10, 2023. A completed application packet includes the nominee's name, resume, and completed AD-755 Form (Advisory Committee or Research and Promotion Background Information). All completed application packets must be sent to the addresses below.
See
Brianna Gallegos, National Partnership
Individuals who use telecommunication devices for the deaf and hard-of-hearing (TDD) may call the Federal Relay Service (FRS) at 1-800-877-8339 between 8 a.m. and 5 p.m., 24 hours per day, every day of the week, including holidays.
In accordance with the provisions of FACA, the Secretary of Agriculture is seeking nominations for the purpose of improving collaborative relationships among people who use and care for National Forests and provide advice and recommendations to the Forest Service concerning projects and funding consistent with Title II. The duties of SRS RACs include monitoring projects, advising the Secretary on the progress and results of monitoring efforts, and making recommendations to the Forest Service for any appropriate changes or adjustments to the projects being monitored by the SRS RACs.
The SRS RACs will be comprised of 15 members approved by the Secretary of Agriculture (or designee) where each will serve a 4-year term. SRS RACs memberships will be balanced in terms of the points of view represented and functions to be performed. The SRS RACs shall include representation from the following interest areas:
(1) Five persons who represent:
(a) Organized Labor or Non-Timber Forest Product Harvester Groups;
(b) Developed Outdoor Recreation, Off-Highway Vehicle Users, or Commercial Recreation Activities;
(c) Energy and Mineral Development, or Commercial or Recreational Fishing Groups;
(d) Commercial Timber Industry; and
(e) Federal Grazing Permit or Other Land Use Permit Holders, or Representative of Non-Industrial Private Forest Land Owners, within the area for which the committee is organized.
(2) Five persons who represent:
(a) Nationally or Regionally Recognized Environmental Organizations;
(b) Regionally or Locally Recognized Environmental Organizations;
(c) Dispersed Recreational Activities;
(d) Archaeology and History; and
(e) Nationally or Regionally Recognized Wild Horse and Burro Interest, Wildlife Hunting Organizations, or Watershed Associations.
(3) Five persons who represent:
(a) State Elected Office holder;
(b) County or Local Elected Office holder;
(c) American Indian Tribes within or adjacent to the area for which the committee is organized;
(d) Area School Officials or Teachers; and
(e) Affected Public-at-Large.
If a vacancy arises, the Designated Federal Officer (DFO) may consider recommending to the Secretary (or designee) to fill the vacancy as soon as it occurs with a candidate from the applicant pool provided an appropriate candidate is available. In accordance with the Act, members of the SRS RAC shall serve without compensation. SRS RAC members and replacements may be allowed travel expenses and per diem for attendance at committee meetings, subject to approval of the DFO responsible for administrative support to the SRS RAC.
The appointment of members to the SRS RACs will be made by the Secretary of Agriculture (or designee). The public is invited to submit nominations for membership on the SRS RACs, either as a self-nomination or a nomination of any qualified and interested person. Any individual or organization may nominate one or more qualified persons to represent the interest areas listed above. To be considered for membership, nominees must:
1. Be a resident of the State in which the SRS RAC has jurisdiction,
2. Identify what interest group they would represent and how they are qualified to represent that interest group,
3. Provide a cover letter stating why they want to serve on the SRS RAC and what they can contribute,
4. Provide a resume showing their past experience in working successfully as part of a group working on forest management activities,
5. Complete Form AD-755, Advisory Committee or Research and Promotion Background Information. The Form AD-755 may be obtained from the Regional Coordinators listed below or from the following SRS RACs website:
Nominations and completed applications for SRS RACs should be sent to the appropriate Forest Service Regional Offices listed below:
For Central Montana RAC, Flathead RAC, Gallatin RAC, Idaho Panhandle RAC, Lincoln RAC, Mineral County RAC, Missoula RAC, Missouri River RAC, North Central Idaho RAC, Ravalli RAC, Sanders RAC, Southern Montana RAC, Southwest Montana RAC, and Tri-County RAC send to: Jeffery Miller, Northern Regional Coordinator, Forest Service, 26 Fort Missoula Road, Missoula, Montana 59804, at 406-329-3576.
Black Hills RAC and Greater Rocky Mountain RAC send to: Jace Ratzlaff, Rocky Mountain Regional Coordinator, Forest Service, 1617 Cole Blvd. Building 17, Lakewood, Colorado 80401, at 719-469-1254.
Coconino County RAC, Eastern Arizona RAC, Northern New Mexico RAC, Southern Arizona RAC, Southern New Mexico RAC, Yavapai RAC send to: Jonathan Word, Southwestern Regional Coordinator, Forest Service, 333 Broadway SE, Albuquerque, New Mexico 87102, at 505-842-3241.
Alpine RAC, Bridger-Teton RAC, Central Idaho RAC, Dixie RAC, Eastern Idaho RAC, Fishlake RAC, Lyon-Mineral RAC, Manti-La Sal RAC, Northern Utah, South Central Idaho RAC, Southwest Idaho RAC, Rural Nevada RAC send to: Don Jaques, Intermountain Regional Coordinator (Idaho/Utah/Nevada), Forest Service, 355 North Vernal Avenue, Vernal, UT 84078, at 435-781-5119.
Butte County RAC, Del Norte County RAC, El Dorado County RAC, Fresno County RAC, Glenn and Colusa Counties RAC, Humboldt County RAC, Kern and Tulare Counties RAC, Lassen County RAC, Mendo-Lake County RAC, Modoc County RAC, Nevada and Placer Counties RAC,
Plumas County RAC, Shasta County RAC, Sierra County RAC, Siskiyou County RAC, Tehama RAC, Trinity County RAC, Tuolumne and Mariposa Counties RAC send to: Paul Wade, Pacific Southwest Regional Coordinator, Forest Service, 1323 Club Drive, Vallejo, California 94592, at 707-562-9010.
Columbia County RAC, Colville RAC, Deschutes and Ochoco RAC, Fremont
Alabama RAC, Cherokee RAC, Daniel Boone RAC, Davy Crockett RAC, Florida National Forests RAC, Francis Marion-Sumter RAC, Kisatchie RAC, Ozark-Ouachita RAC, Sabine-Angelina RAC, National Forest in Mississippi RAC, Virginia RAC send to: Sheila Holified, Southern Regional Coordinator, Forest Service, 1720 Peachtree Road, Northwest, Atlanta, Georgia 30309, at 205-517-9033.
Allegheny RAC, Chippewa National Forest RAC, Eleven Point RAC, Hiawatha RAC, Huron-Manistee RAC, North Wisconsin RAC, Ottawa, Superior RAC, West Virginia RAC send to:
David Scozzafave, Eastern Regional Coordinator, Forest Service, 626 East Wisconsin Avenue, Milwaukee, Wisconsin 53202, at 414-297-3602.
Kenai Peninsula-Anchorage Borough RAC, North Tongass RAC, Prince William Sound RAC, South Tongass RAC send to: Nicole Olsen, Alaska Regional Coordinator, Forest Service, 709 West 9th Street, Room 561C, Juneau, Alaska 99801-1807, 907-586-7836.
Equal opportunity practices in accordance with USDA's policies will be followed in all appointments to the Committee. To ensure that the recommendations of the Committee have taken in account the needs of the diverse groups served by USDA, membership shall include to the extent possible, individuals with demonstrated ability to represent minorities, women, and person with disabilities. USDA is an equal opportunity provider, employer, and lender.
USDA programs are prohibited from discriminating based on race, color, national origin, religion, sex, gender identity (including gender expression), sexual orientation, disability, age, marital status, family/parental status, income derived from a public assistance program, political beliefs, or reprisal or retaliation for prior civil rights activity, in any program or activity conducted or funded by USDA (not all bases apply to all programs). Remedies and complaint filing deadlines vary by program or incident.
An application has been submitted to the Foreign-Trade Zones (FTZ) Board by the City of San Jose, grantee of FTZ 18, requesting an expansion of Subzone 18G on behalf of Tesla, Inc., located in Oakland, California. The application was submitted pursuant to the provisions of the Foreign-Trade Zones Act, as amended (19 U.S.C. 81a-81u), and the regulations of the FTZ Board (15 CFR part 400). It was formally docketed on December 7, 2022.
The applicant is now requesting to expand Subzone 18G to include an additional site: Site 25 (8.79 acres)—8350 Pardee Drive, Oakland, Alameda County. The expanded subzone would be subject to the existing activation limit of FTZ 18.
In accordance with the FTZ Board's regulations, Qahira El-Amin of the FTZ Staff is designated examiner to review the application and make recommendations to the Executive Secretary.
Public comment is invited from interested parties. Submissions shall be addressed to the FTZ Board's Executive Secretary and sent to:
A copy of the application will be available for public inspection in the “Online FTZ Information Section” section of the FTZ Board's website, which is accessible via
For further information, contact Qahira El-Amin at
Enforcement and Compliance, International Trade Administration, Department of Commerce.
The U.S Department of Commerce (Commerce) is conducting the administrative review of the antidumping duty order on certain large vertical shaft engines between 225cc and 999cc, and parts thereof (large vertical shaft engines) from the People's Republic of China (China). The period of review (POR) is August 19, 2020, through February 28, 2022. Commerce preliminarily determines that Honda Power Products (China) Co., Ltd. (Honda) failed to establish its eligibility for a separate rate and, therefore, is part of the China-wide entity. We are also rescinding this review with respect to Chongqing Rato Technology Co., Ltd. (Chongqing Rato) and Loncin Motor Co., Ltd (Loncin). We invite interested parties to comment on these preliminary results.
Applicable December 13, 2022.
Leo Ayala or Jacob Saude, AD/CVD Operations, Office VII, Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce, 1401 Constitution Avenue NW, Washington, DC 20230; telephone: (202) 482-3945 or (202) 482-0981, respectively.
On March 3, 2022, Commerce published in the
On June 17, 2022, we placed on the record U.S. Customs and Border Protection (CBP) entry data under administrative protective order (APO) for all interested parties having APO access and provided interested parties the opportunity to comment on the CBP data and respondent selection.
On July 18, 2022, Chonqqing Rato timely withdrew its request for an administrative review.
The scope of the
Engines covered by this scope normally must comply with and be certified under Environmental Protection Agency (EPA) air pollution controls title 40, chapter I, subchapter U, part 1054 of the Code of Federal Regulations standards for small non-road spark-ignition engines and equipment. Engines that otherwise meet the physical description of the scope but are not certified under 40 CFR part 1054 and are not certified under other parts of subchapter U of the EPA air pollution controls are not excluded from the scope of the
For purposes of the
The engines subject to the
Pursuant to 19 CFR 351.213(d)(1), Commerce will rescind an administrative review, in whole or in part, if all parties that requested a review withdraw their requests within 90 days of the publication date of the notice of initiation of the requested review in the
Commerce is conducting this administrative review in accordance with section 751(a)(1)(B) of the Tariff Act of 1930, as amended (the Act), and 19 CFR 351.213.
The deadline for Honda to submit a no-shipment certification, separate rate application (SRA), or separate rate certification (SRC) was July 11, 2022.
Commerce no longer considers the non-market economy (NME) entity as an exporter conditionally subject to an antidumping duty administrative review.
Interested parties are invited to comment on the preliminary results and may submit case briefs or written comments, filed electronically via Enforcement and Compliance's Antidumping Duty and Countervailing Duty Centralized Electronic Service System (ACCESS), within 30 days after the date of publication of these preliminary results of review.
Interested parties who wish to request a hearing, or to participate if one is requested, must submit a written request to the Assistant Secretary for Enforcement and Compliance within 30 days of the date of publication of this notice.
Upon issuance of the final results of this review, Commerce will determine, and CBP will assess, antidumping duties on all appropriate entries covered by this review.
For Chongqing Rato and Loncin, for which this review is rescinded, antidumping duties shall be assessed at rates equal to the cash deposit of estimated antidumping duties required at the time of entry, or withdrawal from warehouse, for consumption, during the period August 19, 2020, through February 28, 2022, in accordance with 19 CFR 351.212(c)(1)(i).
Commerce intends to issue assessment instructions to CBP no earlier than 35 days after the date of publication of the final rescission of this review in the
The following cash deposit requirements will be effective upon publication of the final results of this administrative review for all shipments of the subject merchandise entered, or withdrawn from warehouse, for consumption on or after the publication date of the final results of review, as provided for by section 751(a)(2)(C) of the Act: (1) for Honda, if it is found to not be eligible for a separate rate in the final results of review, then its cash deposit rate will be the rate applicable for the China-wide entity; (2) for previously investigated or reviewed Chinese and non-Chinese exporters who are not under review in this segment of the proceeding but who have separate rates, the cash deposit rate will continue to be the exporter specific rate published for the most recent period; (3) for all Chinese exporters of subject merchandise that have not been found to be entitled to a separate rate, the cash deposit rate will be the China-wide rate of 456.10 percent; and (4) for all non-Chinese exporters of subject merchandise which have not received their own rate, the cash deposit rate will be the rate applicable to Chinese exporter(s) that supplied that non-Chinese exporter. These deposit requirements, when imposed, shall remain in effect until further notice.
This notice also serves as a preliminary reminder to importers of their responsibility under 19 CFR 351.402(f)(2) to file a certificate regarding the reimbursement of antidumping and/or countervailing duties prior to liquidation of the relevant entries during this review period. Failure to comply with this requirement could result in Commerce's presumption that reimbursement of antidumping and/or countervailing duties occurred and the subsequent assessment of double antidumping duties, and/or an increase in the amount of antidumping duties by the amount of the countervailing duties.
This determination is issued and published in accordance with sections 751(a)(1) and 777(i)(1) of the Act and 19 CFR 351.213(d) and 19 CFR 351.221(b)(4).
Enforcement and Compliance, International Trade Administration, Department of Commerce.
On December 6, 2022, the U.S. Court of International Trade (CIT) issued its final judgment in
Applicable December 16, 2022.
Alice Maldonado, AD/CVD Operations Office II, Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce, 1401 Constitution Avenue NW, Washington, DC, 20230; telephone: (202) 482-4682.
On December 29, 2020, Commerce published its final results in the 2018-2019 AD administrative review of shrimp from India.
ZA Sea Foods and the other Indian shrimp respondents appealed Commerce's
In its final remand redetermination, issued in July 2022, Commerce determined that there was insufficient record evidence to find that ZA Sea Foods' third country Vietnamese sales were unrepresentative and unsuitable for use in the calculation of NV and recalculated the weighted-average dumping margin for ZA Sea Foods by relying on ZA Sea Foods' third country Vietnamese sales during the period of review.
In its decision in
Because there is now a final court judgment, Commerce is amending its
Commerce will issue revised cash deposit instruction to U.S. Customs and Border Protection (CBP).
Because Hari Marine Private Limited, HN Indigos Private Limited, Megaa Moda Pvt. Ltd., Milsha Agro Exports Private Limited, RSA Marines, Shimpo Exports Private Limited, and Zeal Aqua Limited have a superseding cash deposit rate,
At this time, Commerce remains enjoined by CIT order from liquidating entries that were produced and exported
In the event that the CIT's final judgment is not appealed or, if appealed, is upheld by a final and conclusive court decision, Commerce will instruct CBP to assess antidumping duties on unliquidated entries of subject merchandise produced and exported by Z.A. Sea Foods, B-One Business House Pvt. Ltd., Hari Marine Private Limited, Magnum Export, Megaa Moda Pvt. Ltd., Milsha Agro Exports Private Limited, Sea Foods Private Limited, Shimpo Exports Private Limited, Five Star Marine Exports Private Limited, HN Indigos Private Limited, RSA Marines, and Zeal Aqua Limited, in accordance with 19 CFR 351.212(b). We will instruct CBP to assess antidumping duties on all appropriate entries covered by this review when the importer-specific
This notice is issued and published in accordance with sections 516A(c) and (e) and 777(i)(1) of the Act.
National Telecommunications and Information Administration, Department of Commerce.
Notice, request for comment.
The National Telecommunications and Information Administration (NTIA) is requesting comment on the implementation of the Public Wireless Supply Chain Innovation Fund, as directed by the
Submit written comments on or before 5 p.m. Eastern Standard Time on January 27, 2023.
All electronic public comments on this action, identified by
In addition to inviting written submissions through this Notice, NTIA is hosting a public virtual listening session. More information about the listening session can be found at
Please direct questions regarding this Notice to
On August 9, 2022, President Biden signed the
With the passage of the
Today's fifth generation wireless technology (known as “5G”) infrastructure market is highly consolidated, with a small group of vendors making up the majority of the marketplace. This lack of competition can reduce supply chain resilience and security, contribute to higher prices, make it challenging for new, innovative U.S. companies to break into the market, and ultimately will exacerbate the digital divide. Additionally, certain equipment and services produced or provided by particular vendors in this marketplace have been deemed to pose an unacceptable risk to the national security of the United States.
In line with the Executive Branch's policy to promote the development of Open Radio Access Networks (or Open RAN), alongside other policies, technologies, and architectures that support 5G vendor diversity and foster market competition, the
More specifically, the Innovation Fund will support the following activities, as defined in 47 U.S.C. 906(a)(1)(C):
1. Promoting and deploying technology, including software, hardware, and microprocessing technology, that will enhance competitiveness in 5G and successor wireless technology supply chains that use open and interoperable interface radio access networks.
2. Accelerating commercial deployments of open interface, standards-based, interoperable equipment, such as equipment developed pursuant to the standards set forth by organizations such as the O-RAN Alliance, the Telecom Infra Project, [3rd Generation Partnership Project (3GPP)], the Open-RAN Software Community, or any successor organizations.
3. Promoting and deploying compatibility of new 5G equipment with future open standards-based, interoperable equipment.
4. Managing integration of multi-vendor network environments.
5. Identifying objective criteria to define equipment as compliant with open standards for multi-vendor network equipment interoperability.
6. Promoting and deploying security features enhancing the integrity and availability of equipment in multi-vendor networks.
7. Promoting and deploying network function virtualization to facilitate multi-vendor interoperability and a more diverse vendor market.
NTIA, in consultation with the Federal Communications Commission, the National Institute of Standards and Technology, the Department of Homeland Security, the Department of Defense, and the Intelligence Advanced Research Projects Activity of the Office of the Director of National Intelligence, is responsible for establishing the grant criteria and administering the program. As such, NTIA has established multiple avenues for the public to offer input to inform program design and implementation. This includes a public virtual listening session (see
As the Executive Branch agency statutorily responsible for advising the President on telecommunications policy issues and managing federal spectrum, this investment will leverage NTIA's leadership in the areas of 5G and future generation telecommunications, supplier diversity, and spectrum management, among others. The program will also build upon the Department's grantmaking expertise, as NTIA continues to advance the $65 billion internet for All program to connect every American to high-speed, affordable internet service.
This critical investment will help drive U.S. wireless innovation, foster competition, and strengthen supply chain resilience. It will also help unlock opportunities for U.S. companies, particularly small and medium enterprises, to compete in a market historically dominated by a few foreign suppliers, including high-risk suppliers that raise security concerns. In comparison to traditional telecommunications networks, which utilize a single supplier's proprietary equipment, open and interoperable, standards-based RAN prevents vendor lock-in by facilitating competition. This competition allows operators to procure the best solutions for their specific needs by mixing and matching network components, rather than procuring proprietary end-to-end solutions from a single supplier. Open and interoperable, standards-based RAN may also reduce costs for consumers and network operators in the long run by improving efficiency through automation, supporting more seamless network updates, and potentially lowering capital expenditures (CapEx) and operating expenses (OpEx).
This Notice offers an opportunity for all interested parties to provide vital input and recommendations for consideration in the development and implementation of NTIA's Innovation Fund grant program. NTIA seeks public input and feedback from a wide array of stakeholders to inform the implementation of the Innovation Fund grant program. This is a historic investment, requiring the combined efforts of the Federal government, state and local governments, the U.S. private sector, non-governmental organizations, and likeminded partners from around the world.
This Notice seeks public comment to bolster NTIA's work and to improve the number and quality of ideas under consideration as the agency develops Notices of Funding Opportunity (NOFOs). These formal announcements (NOFOs) will be used to solicit applications for Innovation Fund grants and will provide information about the size of the awards, who is eligible to apply, the evaluation criteria for selection of an awardee, required components of an application, and how to submit an application.
This Notice also offers an opportunity for stakeholders to provide detailed comments and recommendations on the kinds of projects and programs the Innovation Fund should aim to support. Rather than focusing on the benefits of open, interoperable, and standards-based network deployments, such as Open RAN, or more general policy general policy recommendations detailed in previous FCC and NTIA processes,
NTIA welcomes input on any matter that commenters believe is important to NTIA's Innovation Fund implementation efforts. Commenters are invited to comment on the full range of issues presented by this Notice and are encouraged to address any or all of the following questions, or to provide additional information relevant to implementation of the Innovation Fund. We invite commenters who intend to apply or who have experience with
Commenters are not required to respond to all questions. When responding to one or more of the questions below, please note in the text of your response the number of the question to which you are responding. Commenters are welcome to provide specific actionable proposals, rationales, and relevant facts.
Commenters should include a page number on each page of their submissions. Please do not include in your comments information of a confidential nature, such as sensitive personal information or proprietary information. All comments received are a part of the public record and will generally be posted to
Understanding the current state of the telecommunications industry is important to determining how any topics should be prioritized in the Innovation Fund, and what level of funding a topic should receive.
1. What are the chief challenges to the adoption and deployment of open and interoperable, standards-based RAN, such as Open RAN? Are those challenges different for public vs. private networks?
a. What are the challenges for brownfield deployments, in which existing networks are upgraded to incorporate open, interoperable, and standards-based equipment?
2. What ongoing public and private sector initiatives may be relevant to the Innovation Fund?
a. What gaps exist from an R&D, commercialization, and standards perspective?
b. How might NTIA best ensure funding is used in a way that complements existing public and private sector initiatives?
3. What kind of workforce constraints impact the development and deployment of open and interoperable, standards-based RAN, such as Open RAN? How (if at all) can the Innovation Fund help alleviate some of these workforce challenges?
4. What is the current climate for private investment in Open RAN, and how can the Innovation Fund help increase and accelerate the pace of investment by public and private entities?
5. How do global supply chains impact the open, interoperable, and standards-based RAN market, particularly in terms of procuring equipment for trials or deployments?
Understanding the current state of open and interoperable, standards-based RAN and the standards that inform its development will assist NTIA in maximizing the impact of grants. Questions in this section will be used to assess the maturity of the technology and related standards to help determine which topics should receive additional investment.
6. What open and interoperable, standards-based network elements, including RAN and core network elements, would most benefit from additional research and development (R&D) supported by the Innovation Fund?
7. Are the 5G and open and interoperable RAN standards environments sufficiently mature to produce stable, interoperable, cost-effective, and market-ready RAN products? If not:
a. What barriers are faced in the standards environment for open and interoperable RAN?
b. What is required, from a standards perspective, to improve stability, interoperability, cost effectiveness, and market readiness?
c. What criteria should be used to define equipment as compliant with open standards for multivendor network equipment interoperability?
8. What kinds of projects would help ensure 6G and future generation standards are built on a foundation of open and interoperable, standards-based RAN elements?
Challenges associated with systems integration and component interoperability can hinder the adoption of open and interoperable, standards-based RAN. This section will help NTIA structure the NOFOs in a way that most effectively addresses these challenges and facilitates adoption. NTIA also welcomes feedback on the effectiveness of certification regimes in driving open and interoperable, standards-based RAN adoption.
9. How can projects funded through the Innovation Fund most effectively support promoting and deploying compatibility of new 5G equipment with future open, interoperable, and standards-based equipment?
a. Are interoperability testing and debugging events (
10. How can projects funded through the program most effectively support the “integration of multi-vendor network environments”?
11. How do certification programs impact commercial adoption and deployment?
a. Is certification of open, interoperable, standards-based equipment necessary for a successful marketplace?
b. What bodies or fora would be appropriate to host such a certification process?
12. What existing gaps or barriers are presented in the current RAN and open and interoperable, standards-based RAN certification regimes?
a. Are there alternative processes to certification that may prove more agile, economical, or effective than certification?
b. What role, if any, should NTIA take in addressing gaps and barriers in open and interoperable, standards-based RAN certification regimes?
A key aim of the Innovation Fund is to promote and deploy technologies that will enhance competitiveness of 5G and successor open and interoperable, standards-based RAN. We have seen a range of Open RAN trials, pilots, and use cases underway across the United States and internationally to date. This section will inform the types of NOFOs NTIA publishes and administers as the Department works to accelerate adoption.
13. What are the foreseeable use cases for open and interoperable, standards-based networks, such as Open RAN, including for public and private 5G networks? What kinds of use cases, if any, should be prioritized?
14. What kinds of trials, use cases, feasibility studies, or proofs of concept will help achieve the goals identified in 47 U.S.C. 906(a)(1)(C), including accelerating commercial deployments?
a. What kinds of testbeds, trials, and pilots, if any, should be prioritized?
15. How might existing testbeds be utilized to accelerate adoption and deployment?
16. What sort of outcomes would be required from proof-of-concept pilots and trials to enable widespread adoption and deployment of open and
Strengthening supply chain resilience is a critical benefit of open and interoperable, standards-based RAN adoption. In line with the Innovation Fund's goal of “promoting and deploying security features” to enhance the integrity and availability of multi-vendor network equipment, and Department priorities outlined in the National Strategy to Secure 5G Implementation Plan, this section will inform how NTIA incorporates security into future Innovation Fund NOFOs.
17. “Promoting and deploying security features enhancing the integrity and availability of equipment in multi-vendor networks,” is a key aim of the Innovation Fund (47 U.S.C 906(a)(1)(C)(vi)). How can the projects and initiatives funded through the program best address this goal and alleviate some of the ongoing concerns relating to the security of open and interoperable, standards-based RAN?
a. What role should security reporting play in the program's criteria?
b. What role should security elements or requirements, such as industry standards, best practices, and frameworks, play in the program's criteria?
18. What steps are companies already taking to address security concerns?
19. What role can the Innovation Fund play in strengthening the security of open and interoperable, standards-based RAN?
20. How is the “zero-trust model” currently applied to 5G network deployment, for both traditional and open and interoperable, standards-based RAN? What work remains in this space?
The Innovation Fund is a historic investment in America's 5G future. As such, NTIA is committed to developing a program that results in meaningful progress toward the deployment and adoption of open and interoperable, standards-based RAN. To accomplish this, we welcome feedback from stakeholders on how our program requirements and monitoring can be tailored to achieve the goals set out in 47 U.S.C. 906.
21. Transparency and accountability are critical to programs such as the Innovation Fund. What kind of metrics and data should NTIA collect from awardees to evaluate the impact of the projects being funded?
22. How can NTIA ensure that a diverse array of stakeholders can compete for funding through the program? Are there any types of stakeholders NTIA should ensure are represented?
23. How (if at all) should NTIA promote teaming and/or encourage industry consortiums to apply for grants?
24. How can NTIA maximize matching contributions by entities seeking grants from the Innovation Fund without adversely discouraging participation? Matching requirements can include monetary contributions and/or third-party in-kind contributions (as defined in 2 CFR 200.1).
25. How can the fund ensure that programs promote U.S. competitiveness in the 5G market?
a. Should NTIA require that grantee projects take place in the U.S.?
b. How should NTIA address potential grantees based in the U.S. with significant overseas operations and potential grantees not based in the U.S. (
c. What requirements, if any, should NTIA take to ensure “American-made” network components are used? What criteria (if any) should be used to consider whether a component is “American-made”?
26. How, if at all, should NTIA collaborate with like-minded governments to achieve Innovation Fund goals?
NTIA welcomes any additional input that stakeholders believe will prove useful to our implementation efforts.
27. Are there specific kinds of initiatives or projects that should be considered for funding that fall outside of the questions outlined above?
28. In addition to the listening session mentioned above and forthcoming NOFOs, are there other outreach actions NTIA should take to support the goals of the Innovation Fund?
National Telecommunications and Information Administration, Department of Commerce.
Notice of open meeting.
The National Telecommunications and Information Administration (NTIA) will convene a virtual industry roundtable listening session on the Public Wireless Supply Chain Innovation Fund. The listening session is designed to collect stakeholder input to help inform the development and administration of the Innovation Fund grant program.
The listening session will be held on January 24, 2023, from 10:00 a.m. to 12:30 p.m., Eastern Standard Time.
The session will be held virtually, with online slide share and dial-in information to be posted at
Please direct questions regarding this Notice to
Today's fifth generation wireless technology (known as “5G”) infrastructure market is highly consolidated, with a small group of vendors making up the majority of the marketplace. This lack of competition can reduce supply chain resilience and security, contribute to higher prices, and make it challenging for new, innovative U.S. companies to break into the market.
To help inform development and administration of the Innovation Fund grant program, NTIA has established multiple avenues for the public to offer input, including through a Request for Comment also published today as well as this public virtual listening session. NTIA seeks input from all interested stakeholders—including private industry, academia, civil society, and other experts. The discussions held at this session will be analyzed to help inform, among other items: the kinds of grant criteria NTIA should consider, recommendations on the types of projects and programs the Innovation Fund should aim to support, and practical solutions to the chief challenges of open, interoperable, and standards-based RAN adoption.
Office of the Under Secretary of Defense for Personnel and Readiness (OUSD(P&R)), Department of Defense (DoD).
30-Day information collection notice.
The DoD has submitted to the Office of Management and Budget (OMB) for clearance the following proposal for collection of information under the provisions of the Paperwork Reduction Act.
Consideration will be given to all comments received by January 12, 2023.
Written comments and recommendations for the proposed information collection should be sent within 30 days of publication of this notice to
Angela Duncan, 571-372-7574,
A. Age-appropriate training and education programs for elementary and secondary school students, designed to assist such students in learning positive relationship behaviors in families and with intimate partners.
B. Means of improving access to resources for survivors who have already experienced domestic abuse, including survivors who are geographically relocating.
C. Strategies to prevent domestic abuse by training, educating, and assigning prevention-related responsibilities to military leaders; medical, behavioral, and mental health service providers; staff from domestic abuse and related prevention programs; and others with relevant responsibilities, such as law enforcement.
Respondents will be responding to the information collection to apply their expertise and help improve domestic abuse prevention and response in the military.
You may also submit comments and recommendations, identified by Docket ID number and title, by the following method:
•
Requests for copies of the information collection proposal should be sent to Ms. Duncan at
Office of the Under Secretary of Defense for Personnel and Readiness (OUSD(P&R)), Department of Defense (DoD).
30-Day information collection notice.
The DoD has submitted to the Office of Management and Budget (OMB) for clearance the following proposal for collection of information under the provisions of the Paperwork Reduction Act.
Consideration will be given to all comments received by January 12, 2023.
Written comments and recommendations for the proposed information collection should be sent within 30 days of publication of this notice to
Angela Duncan, 571-372-7574,
You may also submit comments and recommendations, identified by Docket ID number and title, by the following method:
•
Requests for copies of the information collection proposal should be sent to Ms. Duncan at
Department of the Navy, Department of Defense.
60-Day information collection notice.
In compliance with the
Consideration will be given to all comments received by February 13, 2023.
You may submit comments, identified by docket number and title, by any of the following methods:
To request more information on this proposed information collection or to obtain a copy of the proposal and associated collection instruments, please write to the Marine Corps Records, Reports, and Directives Management Branch (ARDB), 3000 Marine Corps, Pentagon Rm 2B253 Washington, DC 20350, ATTN: Mr. David-John Tucker, or call 571-256-8883.
This constitutes notice, in accordance with 18 CFR 385.2201(b), of the receipt of prohibited and exempt off-the-record communications.
Order No. 607 (64 FR 51222, September 22, 1999) requires Commission decisional employees, who make or receive a prohibited or exempt off-the-record communication relevant to the merits of a contested proceeding, to deliver to the Secretary of the Commission, a copy of the communication, if written, or a summary of the substance of any oral communication.
Prohibited communications are included in a public, non-decisional file associated with, but not a part of, the decisional record of the proceeding. Unless the Commission determines that the prohibited communication and any responses thereto should become a part of the decisional record, the prohibited off-the-record communication will not be considered by the Commission in reaching its decision. Parties to a proceeding may seek the opportunity to respond to any facts or contentions made in a prohibited off-the-record communication and may request that the Commission place the prohibited communication and responses thereto in the decisional record. The Commission will grant such a request only when it determines that fairness so requires. Any person identified below as having made a prohibited off-the-record communication shall serve the document on all parties listed on the official service list for the applicable proceeding in accordance with Rule 2010, 18 CFR 385.2010.
Exempt off-the-record communications are included in the decisional record of the proceeding, unless the communication was with a cooperating agency as described by 40 CFR 1501.6, made under 18 CFR 385.220(e)(1)(v).
The following is a list of off-the-record communications recently received by the Secretary of the Commission. The communications listed are grouped by docket numbers in ascending order. These filings are available for electronic review at the Commission in the Public Reference Room or may be viewed on the Commission's website at
The following notice of meeting is published pursuant to section 3(a) of the government in the Sunshine Act (Pub. L. 94-409), 5 U.S.C. 552b:
Federal Energy Regulatory Commission.
December 15, 2022, 10:00 a.m.
Room 2C, 888 First Street NE, Washington, DC 20426.
Open to the public.
Agenda. * Note—Items listed on the agenda may be deleted without further notice.
Kimberly D. Bose, Secretary, Telephone (202) 502-8400.
For a recorded message listing items stricken from or added to the meeting, call (202) 502-8627.
This is a list of matters to be considered by the Commission. It does not include a listing of all documents relevant to the items on the agenda. All public documents, however, may be viewed on line at the Commission's website at
A free webcast of this event is available through the Commission's website. Anyone with internet access who desires to view this event can do so by navigating to
Immediately following the conclusion of the Commission Meeting, a press briefing will be held in the Commission Meeting Room. Members of the public may view this briefing in the designated overflow room. This statement is intended to notify the public that the press briefings that follow Commission meetings may now be viewed remotely at Commission headquarters but will not be telecast.
Take notice that the Commission has received the following Natural Gas Pipeline Rate and Refund Report filings:
Any person desiring to intervene or protest in any of the above proceedings must file in accordance with Rules 211 and 214 of the Commission's Regulations (18 CFR 385.211 and 385.214) on or before 5:00 p.m. Eastern time on the specified comment date. Protests may be considered, but intervention is necessary to become a party to the proceeding.
Any person desiring to protest in any the above proceedings must file in accordance with Rule 211 of the Commission's Regulations (18 CFR 385.211) on or before 5:00 p.m. Eastern time on the specified comment date.
The filings are accessible in the Commission's eLibrary system (
eFiling is encouraged. More detailed information relating to filing requirements, interventions, protests, service, and qualifying facilities filings can be found at:
Take notice that the Commission received the following electric rate filings:
Take notice that the Commission received the following foreign utility company status filings:
The filings are accessible in the Commission's eLibrary system (
Any person desiring to intervene or protest in any of the above proceedings must file in accordance with Rules 211 and 214 of the Commission's Regulations (18 CFR 385.211 and 385.214) on or before 5:00 p.m. Eastern time on the specified comment date. Protests may be considered, but intervention is necessary to become a party to the proceeding.
eFiling is encouraged. More detailed information relating to filing requirements, interventions, protests, service, and qualifying facilities filings can be found at:
Environmental Protection Agency (EPA).
Notice.
In accordance with the Federal Insecticide, Fungicide and Rodenticide Act (FIFRA), EPA is issuing a notice of receipt of requests by the registrants to voluntarily cancel certain
Comments must be received on or before January 12, 2023.
The docket for this action, identified by docket identification (ID) number EPA-HQ-OPP-2022-0223, is available at
Patricia Biggio, Pesticide Re-Evaluation Division (7508P), Office of Pesticide Programs, Environmental Protection Agency, 1200 Pennsylvania Ave. NW, Washington, DC 20460-0001; telephone number: 202-566-0700; email address:
This action is directed to the public in general and may be of interest to a wide range of stakeholders including environmental, human health, and agricultural advocates; the chemical industry; pesticide users; and members of the public interested in the sale, distribution, or use of pesticides. Since others also may be interested, the Agency has not attempted to describe all the specific entities that may be affected by this action.
1.
2.
This notice announces receipt by the Agency of requests from registrants to cancel certain pesticide product registrations and terminate certain uses of product registrations. These affected registrations are listed in sequence by registration number in Table 1 and Table 2 of this Unit. Table 3 of this Unit includes the names and addresses of record for the registrants of the products listed in Table 1 and Table 2 of this Unit, in sequence by EPA company number. This company number corresponds to the first part of the EPA registration numbers of the products listed in Table 1 and Table 2 of this Unit.
Unless the Agency determines that there are substantive comments that warrant further review of the requests or the registrants withdraw their requests, EPA intends to issue an order in the
Section 6(f)(1) of FIFRA (7 U.S.C. 136d(f)(1)) provides that a registrant of a pesticide product may at any time request that any of its pesticide registrations be cancelled or amended to terminate one or more registered uses. FIFRA further provides that, before acting on the request, EPA must publish a notice of receipt of any such request in the
Section 6(f)(1)(B) of FIFRA (7 U.S.C. 136d(f)(1)(B)) requires that before acting on a request for voluntary cancellation, EPA must provide a 30-day public comment period on the request for voluntary cancellation or use termination. In addition, FIFRA section 6(f)(1)(C) (7 U.S.C. 136d(f)(1)(C)) requires that EPA provide a 180-day comment period on a request for voluntary cancellation or termination of any minor agricultural use before granting the request, unless:
1. The registrants request a waiver of the comment period, or
2. The EPA Administrator determines that continued use of the pesticide would pose an unreasonable adverse effect on the environment.
The registrants in Table 2 of Unit II have requested that EPA waive the 180-day comment period. Accordingly, EPA will provide a 30-day comment period on the proposed requests.
Registrants who choose to withdraw a request for cancellation should submit such withdrawal in writing to the person listed under
Existing stocks are those stocks of registered pesticide products that are currently in the United States and that were packaged, labeled, and released for shipment prior to the effective date of the cancellation action.
If the requests for voluntary cancellation and amendments to terminate uses are granted, the Agency intends to publish a final cancellation order in the
EPA proposes prohibiting all use of existing stocks of chlorpyrifos products identified in Tables 1 and 2 for food uses. Because all chlorpyrifos tolerances expired on February 28, 2022, use of chlorpyrifos in or on food will result in adulterated food, which cannot be delivered into interstate commerce. Such use would be inconsistent with the purposes of FIFRA. EPA is proposing to allow use of existing stocks of chlorpyrifos products identified in Tables 1 and 2 for non-food uses identified on the existing labels, as long as such use is consistent with the label. All other use of existing stocks of chlorpyrifos products would be prohibited.
Moreover, EPA proposes prohibiting all sale and distribution of existing stocks of the chlorpyrifos products identified in Tables 1 and 2 of Unit II, except for export consistent with FIFRA section 17 (7 U.S.C. 136o) or for proper disposal, in accordance with state regulations. In addition, EPA is working with Corteva and Adama to develop plans for the return of existing stocks of chlorpyrifos to the registrants. Corteva and Adama are developing plans for the return of existing stocks of chlorpyrifos to the registrants. Subject to EPA approval, the terms and conditions of these plans will be implemented through the Cancellation Orders governing the distribution of these products under those return programs. If EPA and Corteva and Adama can come to agreement on those plans, EPA intends to include in the final cancellation order terms allowing for distribution consistent with those return programs.
Environmental Protection Agency (EPA).
Notification of public hearing.
The Environmental Protection Agency (EPA) is announcing a virtual public hearing to be held on January 10, 2023, on its proposal for the “Renewable Fuel Standard (RFS) Program: Standards for 2023-2025 and Other Changes,” which was announced on November 30, 2022. An additional session will be held on January 11, 2023, if necessary, to accommodate the number of testifiers that sign-up to testify. EPA is proposing the 2023-2025 renewable fuel standards for cellulosic biofuel, biomass-based diesel, advanced biofuel, and total renewable fuel. EPA is also proposing the second supplemental standard addressing the remand of the 2016 standard-setting rulemaking and several regulatory changes to the RFS program, including regulations governing the generation of qualifying renewable electricity and other modifications intended to improve the program's implementation.
EPA will hold a virtual public hearing on January 10, 2023. An additional session will be held on January 11, 2023, if necessary, to accommodate the number of testifiers that sign-up to testify. Please refer to the
The virtual public hearing will begin at 9 a.m. Eastern Time (ET) and end when all parties who wish to speak have had an opportunity to do so, but no later than 5 p.m. ET. All hearing attendees (including even those who do not intend to provide testimony) should register for the public hearing by January 3, 2023. Information on how to register can be found at
Nick Parsons, Office of Transportation and Air Quality, Assessment and Standards Division, Environmental Protection Agency, 2000 Traverwood Drive, Ann Arbor, MI 48105; telephone number: (734) 214-4479; email address:
EPA is proposing to establish the 2023-2025 volume targets and corresponding renewable fuel standards for cellulosic biofuel, biomass-based diesel, advanced biofuel, and total renewable fuel. EPA is also proposing the second supplemental standard to address the remand of the 2016 standard-setting rulemaking, as well as several regulatory changes to the Renewable Fuel Standard (RFS) program, including regulations governing the generation of qualifying
Each commenter will have 3 minutes to provide oral testimony. EPA may ask clarifying questions during the oral presentations, but will not respond to the presentations at that time. Written statements and supporting information submitted during the comment period will be considered with the same weight as oral comments and supporting information presented at the public hearing.
Please note that any updates made to any aspect of the hearing will be posted online at
If you require the services of a translator or special accommodations such as audio description, please pre-register for the hearing and describe your needs by January 3, 2023. EPA may not be able to arrange accommodations without advance notice.
Centers for Disease Control and Prevention (CDC), Agency for Toxic Substances and Disease Registry (ATSDR), Department of Health and Human Services (HHS).
Notice of meeting.
The Centers for Disease Control and Prevention (CDC)and Agency for Toxic Substances and Disease Registry (ATSDR) announces the Winter 2023 CDC/ATSDR Tribal Advisory Committee (TAC) meeting. The meeting is being hosted by CDC/ATSDR, in person and virtually, and is open to the public, except for certain hours set aside for tribal caucus. Pre-registration is required, and instructions are provided below in the dates section.
The meeting will be held on February 8, 2023, from 9 a.m. to 4 p.m., EST, and February 9, 2023, from 9 a.m. to 3:30 p.m., EST. Attendees must pre-register for the event by January 16, 2023, at the following link:
CDC, Global Communications Center, Building 21, Conference Rooms 1204A and 1204B, 1600 Clifton Road NE, Atlanta, Georgia 30329-4027.
Mitchell Morris, BA, Acting Director, Office of Tribal Affairs and Strategic Alliances, Center for State, Tribal, Local, and Territorial Support, CDC, 1600 Clifton Road NE, Mailstop V18-4, Atlanta, Georgia 30329-4027; Telephone: (770) 488-1518; Email:
The Tribal Advisory Committee (TAC) advises CDC/ATSDR on policy issues and broad strategies that may significantly affect American Indian and Alaska Native (AI/AN) communities. The TAC assists CDC/ATSDR in fulfilling its mission to promote health and quality of life by preventing and controlling disease, injury, and disability through established and ongoing relationships and consultation sessions.
Information about the TAC and previous meetings is available at
The Director, Strategic Business Initiatives Unit, Office of the Chief Operating Officer, Centers for Disease Control and Prevention, has been delegated the authority to sign
Centers for Disease Control and Prevention (CDC)/Agency for Toxic Substances and Disease Registry (ATSDR), Department of Health and Human Services (HHS).
Notice of meeting.
The Centers for Disease Control and Prevention (CDC)/Agency for Toxic Substances and Disease Registry (ATSDR) announces the 2023
The tribal consultation will be held on February 9, 2023, from 4:00 p.m. to 5:00 p.m., EST. Written tribal testimony is due by 5:00 p.m. EST, on February 24, 2023.
Virtually through Zoom. To register, go to
Joanne Odenkirchen, MPH, Senior Public Health Advisor, Office of Tribal Affairs and Strategic Alliances, Center for State, Tribal, Local, and Territorial Support, CDC, 1600 Clifton Road NE, Mailstop V18-4, Atlanta, Georgia 30329-4027; Telephone: (404) 498-0300; Email:
This meeting is being held in accordance with Presidential Executive Order No. 13175 of November 6, 2000, Consultation and Coordination with Indian Tribal Governments and the Presidential Memoranda of January 26, 2021, November 5, 2009, and September 23, 2004.
Elected tribal officials can find guidance to assist in developing tribal testimony for CDC/ATSDR at
Based on the number of elected tribal officials giving testimony and the time available, it may be necessary to limit the time for each presenter. We will adjourn tribal consultation meetings early if all attendees who requested to provide oral testimony in advance of and during the consultation have delivered their comments. Agenda items are subject to change as priorities dictate.
Additional information about CDC/ATSDR's Tribal Consultation Policy can be found at
The Director, Strategic Business Initiatives Unit, Office of the Chief Operating Officer, Centers for Disease Control and Prevention, has been delegated the authority to sign
Office of Child Support Enforcement, Administration for Children and Families, Department of Health and Human Services.
Request for public comments.
The Office of Child Support Enforcement (OCSE), Administration for Children and Families (ACF), is requesting a three-year extension with proposed revisions to the Hague Child Support Forms (OMB #0970-0488, expiration February 28, 2023). There are two new forms being incorporated.
Written comments and recommendations for the proposed information collection should be sent within 30 days of publication of this notice to
State and federal law require states to use federally approved case processing forms. Section 311(b) of UIFSA 2008, which has been enacted by all 50 states, the District of Columbia, Guam, Puerto Rico, and the Virgin Islands, requires states to use forms mandated by federal law. 45 CFR 303.7 also requires child support programs to use federally approved forms in intergovernmental IV-D cases unless a country has provided alternative forms as a part of its chapter in a Caseworker's Guide to Processing Cases with Foreign Reciprocating Countries.
Food and Drug Administration, HHS.
Notice; renewal of Federal advisory committee.
The Food and Drug Administration (FDA) is announcing the renewal of the Cardiovascular and Renal Drugs Advisory Committee by the Commissioner of Food and Drugs (the Commissioner). The Commissioner has determined that it is in the public interest to renew the Cardiovascular and Renal Drugs Advisory Committee for an additional 2 years beyond the charter expiration date. The new charter will be in effect until the August 27, 2024, expiration date.
Authority for the Cardiovascular and Renal Drugs Advisory Committee will expire on August 27, 2024 unless the Commissioner formally determines that renewal is in the public interest.
Joyce Yu, Center for Drug Evaluation and Research, Food and Drug Administration, 10903 New Hampshire Ave., Bldg. 31, Rm. 2417, Silver Spring, MD 20993-0002, (301) 837-7126,
Pursuant to 41 CFR 102-3.65 and approval by the Department of Health and Human Services and by the General Services Administration, FDA is announcing the renewal of the Cardiovascular and Renal Drugs Advisory Committee (the Committee). The Committee is a discretionary Federal advisory committee established to provide advice to the Commissioner. The Committee advises the Commissioner or designee in discharging responsibilities as they relate to helping to ensure safe and effective drugs for human use and, as required, any other product for which FDA has regulatory responsibility.
The Committee reviews and evaluates available data concerning the safety and effectiveness of marketed and investigational human drug products for use in the treatment of cardiovascular and renal disorders and makes appropriate recommendations to the Commissioner.
The Committee shall consist of a core of 11 voting members including the Chair. Members and the Chair are selected by the Commissioner or designee from among authorities knowledgeable in the fields of cardiology, hypertension, arrhythmia, angina, congestive heart failure, diuresis, and biostatistics. Members will be invited to serve for overlapping terms of up to 4 years. Non-Federal members of this committee will serve as Special Government Employees, representatives, or Ex-Officio members. Federal members will serve as Regular Government Employees or Ex-Officios. The core of voting members may
Further information regarding the most recent charter and other information can be found at
This notice is issued under the Federal Advisory Committee Act (5 U.S.C. app.). For general information related to FDA advisory committees, please visit us at
Food and Drug Administration, HHS.
Notice.
The Food and Drug Administration (FDA, Agency, or we) is announcing that a proposed collection of information has been submitted to the Office of Management and Budget (OMB) for review and clearance under the Paperwork Reduction Act of 1995.
Submit written comments (including recommendations) on the collection of information by January 12, 2023.
To ensure that comments on the information collection are received, OMB recommends that written comments be submitted to
Rachel Showalter, Office of Operations, Food and Drug Administration, Three White Flint North, 10A-12M, 11601 Landsdown St., North Bethesda, MD 20852, 240-994-7399,
In compliance with 44 U.S.C. 3507, FDA has submitted the following proposed collection of information to OMB for review and clearance.
This information collection supports FDA regulatory requirements contained in part 1140 (21 CFR part 1140) authorized under Chapter IX of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 9) and associated Agency guidance. Regulations in part 1140 establish permissible forms of labeling and advertising for cigarettes or smokeless tobacco and include reporting requirements directing persons to notify FDA if they intend to use a form of advertising or labeling that is not addressed in the regulations. Section 1140.30(a)(2) (21 CFR 1140.30(a)(2)) requires tobacco product manufacturers, distributors, and retailers to notify FDA if they intend to use advertising or labeling for cigarettes or smokeless tobacco in a medium that is not listed in the regulations. The notifications must be made 30 days prior to the use of such mediums.
We allow electronic and written submission of these notifications. Respondents can mail notifications as prescribed in section 1140.30(a)(2) to FDA. Instructions providing clarification on how to format the notification may be found in the guidance document entitled “Compliance with Regulations Restricting the Sale and Distribution of Cigarettes and Smokeless Tobacco To Protect Children and Adolescents” (2010) (
In the
FDA estimates the burden of this collection of information as follows:
The burden hour estimates for this collection of information were based on submissions regarding cigarette and smokeless tobacco product advertising expenditures.
FDA estimates that approximately 25 respondents will submit an annual notice of alternative advertising or labeling, and the Agency has estimated it should take 1 hour to provide such notice. Therefore, the total estimated
Food and Drug Administration, HHS.
Notice.
The Food and Drug Administration (FDA) is announcing that a proposed collection of information has been submitted to the Office of Management and Budget (OMB) for review and clearance under the Paperwork Reduction Act of 1995.
Submit written comments (including recommendations) on the collection of information by January 12, 2023.
To ensure that comments on the information collection are received, OMB recommends that written comments be submitted to
Domini Bean, Office of Operations, Food and Drug Administration, Three White Flint North, 10A-12M, 11601 Landsdown St., North Bethesda, MD 20852, 301-796-5733,
In compliance with 44 U.S.C. 3507, FDA has submitted the following proposed collection of information to OMB for review and clearance.
As authorized under section 520(f) of the Federal Food, Drug, and Cosmetic Act (FD&C Act) (21 U.S.C. 360j(f)), the Secretary of the Department of Health and Human Services has issued regulations requiring that the methods used in, and the facilities and controls used for, the manufacture, preproduction design validation (including a process to assess the performance of a device, but not including an evaluation of the safety and effectiveness of a device), packing, storage, and installation of a device conform to current good manufacturing practice (CGMP) and assure that the device will be safe and effective and otherwise in compliance with the FD&C Act.
The quality system regulation (QSR) under part 820 (21 CFR part 820) sets forth CGMP requirements governing the design, manufacture, packing, labeling, storage, installation, and servicing of all finished medical devices intended for human use. The requirements cover purchasing and service controls, clarify recordkeeping for device failure and complaint investigations, clarify requirements for verifying/validating production processes and process or product changes, and clarify requirements for product acceptance activities, quality data evaluations, and corrections of nonconforming product/quality problems. In the
Information collection under the QSR is intended to assist FDA in assuring the safety of medical devices. Requirements include documenting the establishment of procedures and identifying required records that assist FDA in determining whether firms are in compliance with CGMP. In particular, for example, compliance with CGMP design control requirements should decrease the number of design-related device failures that have resulted in deaths and serious injuries. Records must be made available for review or copying during FDA inspection. The regulations in part 820 apply to approximately 29,424 respondents, based on current data within our device registration and listing database.
In the
We estimate the burden of this collection of information as follows:
Our estimated burden for the information collection reflects an overall increase of 1,217,800 hours. We made this adjustment to correspond with an observed increase in submissions relating to medical devices and an increase in respondents in the medical device industry since last OMB review and approval of the information collection.
Food and Drug Administration, HHS.
Notice.
The Food and Drug Administration (FDA) is announcing that a proposed collection of information has been submitted to the Office of Management and Budget (OMB) for review and clearance under the Paperwork Reduction Act of 1995.
Submit written comments (including recommendations) on the collection of information by January 12, 2023.
To ensure that comments on the information collection are received, OMB recommends that written comments be submitted to
Domini Bean, Office of Operations, Food and Drug Administration, Three White Flint North, 10A-12M, 11601 Landsdown St., North Bethesda, MD 20852, 301-796-5733,
In compliance with 44 U.S.C. 3507, FDA has submitted the following proposed collection of information to OMB for review and clearance.
This information collection supports implementation of general drug labeling provisions, including certain OTC drug product labeling requirements found in FDA regulations in 21 CFR part 201 and in section 502(x) of the Federal Food, Drug, and Cosmetic Act (FD&C Act) (21 U.S.C. 352(x)), as well as OTC drug product labeling recommendations discussed in FDA guidance documents enumerated below. The requirements and recommendations contained in this authority help ensure that OTC drug product labeling includes information to assist consumers with product selection and with the safe and effective use of products that protect the public health from potential harm that could result from the dissemination of false and misleading statements regarding FDA-regulated products. As described further below, the information collection provisions of one guidance also apply to prescription drug labeling.
Certain information collection provisions address the labeling (third-party disclosures) that drug companies provide on the principal display panel of every OTC drug product in package form—the part of that drug product's label that is most likely to be displayed or examined in a retail sale setting (see 21 CFR 201.60). Information on this panel supports consumers' product selection, as well as identification after purchase. OTC drug product companies must include a declaration of the net quantity of the OTC product contents on the principal display panel (see § 201.62 (21 CFR 201.62)). They also must include a statement of identity (see § 201.61 (21 CFR 201.61)).
FDA has made available a draft guidance for industry entitled “Statement of Identity and Strength—Content and Format of Labeling for Human Nonprescription Drug Products”
In estimating burden for statement of identity labeling, we have excluded the burden for disclosing any statement of identity specified in a final OTC monograph order under section 505G of the FD&C Act (21 U.S.C. 355h), because FDA regulations state that for purposes of § 201.61, the statement of identity shall be the term or phrase used in an applicable OTC monograph (see 21 CFR 330.1(c)(1)). By operation of law, OTC monographs are now established by order under section 505G of the FD&C Act, and information collections made under section 505G are exempt from the PRA under section 505G(o) of the FD&C Act.
In addition to labeling that drug companies provide on the principal display panel, companies must also comply with Agency regulations in § 201.66 (21 CFR 201.66), which requires standard content elements and formatting for the “Drug Facts” labeling (DFL) of all OTC drug products. This standardized labeling helps consumers understand the information that appears on OTC drug products to help ensure that consumers can use those products safely and effectively. The use of consistent language in labeling headings and subheadings helps consumers comprehend information, and consistent formatting helps consumers more efficiently locate information.
The DFL is where OTC drug product labeling presents certain specific, standardized content required or recommended under other regulations
The quantitative labeling requirements in those regulations cited above are complemented by the draft guidance for industry entitled “Quantitative Labeling of Sodium, Potassium, and Phosphorus for Human Over-the-Counter and Prescription Drug Products”
The Quantitative Sodium, Potassium, and Phosphorus Labeling Guidance also recommends how drug firms can provide quantitative information on sodium, potassium, and phosphorus in prescription drug labeling to help patients who need to limit their overall consumption of these substances. Prescription drugs are not subject to the OTC labeling regulations, but the content and format of prescription drug labeling is set forth in 21 CFR 201.56 and 201.57 and approved under OMB control number 0910-0572. In the guidance, FDA recommends that when the recommended quantitative information about sodium, potassium, and phosphorus is included in prescription drug labeling, it should be presented within the DESCRIPTION section of that labeling, following the list of inactive ingredients. We estimate that the recommendations of the guidance regarding disclosing quantitative information about sodium, potassium, and phosphorus in prescription drug labeling will have no effect on the overall burden estimate for prescription drug labeling as a whole, which is addressed under OMB control number 0910-0572.
Our estimate of burden for OTC drug labeling that appears within the DFL reflects several considerations. For those OTC drug products that are marketed pursuant to an application approved under section 505 of the FD&C Act (21 U.S.C. 355), we assume a substantial part of the burden of developing labeling is addressed in the submission of the new drug application, which includes submission of the proposed labeling. The information collections associated with new drug applications are approved under OMB control number 0910-0001. For OTC drugs that are legally marketed under section 505G of the FD&C Act that do not have an approved application under section 505 of the FD&C Act, a substantial part of the DFL's content, including applicable Uses (Indications), Warnings, and Directions, is established under section 505G, either by final administrative orders or by section 505G(a)(3) of the FD&C Act. Collections of information made under section 505G of the FD&C Act are exempt from the PRA. Therefore, labeling required by administrative orders under section 505G of the FD&C Act or required by section 505G(a)(3) of the FD&C Act, even if it would ordinarily be a collection of information,
Our annualized estimate of burden addresses new products and products for which the DFL and/or net quantity of contents otherwise change in a 12-month period.
Section 502(x) of the FD&C Act requires the label of a nonprescription drug product marketed in the United States without an application approved under section 505 of the FD&C Act to include a domestic address or domestic telephone number through which a manufacturer, packer, and distributor may receive a report of a serious adverse event associated with its product(s). To help implement this provision, we developed the guidance for industry entitled “Labeling of Nonprescription Human Drug Products Marketed Without an Approved Application as Required by the Dietary Supplement and Nonprescription Drug Consumer Protection Act: Questions and Answers” (September 2009) (available at
FDA regulations in § 201.66(e) authorize FDA to exempt or defer specific requirements in § 201.66 if FDA finds that the requirement is inapplicable, impracticable, or contrary to public health or safety. A manufacturer, packer, or distributor can seek such an exemption or deferral by submitting a written request in accordance with the requirements of § 201.66(e), which address the content of such a written request submission and how and where to submit it. A request for an exemption or deferral must be submitted in triplicate for each OTC drug product and contain certain information allowing the Agency to make an informed decision on the request. FDA uses the submitted information to assess whether the grounds for an exemption or deferral are met. Based on historical experience and from feedback received from respondents who have submitted similar requests, FDA estimates that it will take 24 hours to prepare and submit each submission and that on average annually, the Agency will receive one request for a waiver or exemption from the drug labeling requirement.
In addition, § 201.63(d) states that FDA may grant exemptions from the specific OTC drug product warning for patients who are pregnant or breast feeding that is ordinarily required to appear in labeling by § 201.63(a). To request such an exemption, the regulations call for submission of a citizen petition in accordance with § 10.30 (21 CFR 10.30). The submission of citizen petitions under § 10.30, including those petitions that request this labeling exemption, is approved under OMB control number 0910-0191, and we do not address its burden further in this document.
In the
We estimate the burden of this collection of information as follows:
This information collection also includes submissions associated with the OTC Monograph Drug User Fee Program. Section 744M of the FD&C Act (21 U.S.C. 379j-72) establishes an OTC monograph drug user fee program (commonly called OMUFA) and authorizes FDA to assess and collect: (1) facility fees from qualifying OTC monograph drug facilities and (2) fees from submitters of qualifying OTC Monograph Order Requests (OMORs). The OMUFA program supports FDA activities related to the regulation of OTC monograph drug products, including provisions of section 505G of the FD&C Act that facilitate innovation and make it easier for FDA to better respond to safety issues when they emerge. We provide information regarding the OMUFA program on our website at
We developed Form FDA 5009,
In the
We estimate the burden of the collection of information as follows:
Based on data from our electronic Drug Registration and Listing System, we estimate that there will be 1,184 respondents who will provide information in conjunction with facility fee payments annually. In addition, consistent with the “Over-the-Counter Monograph User Program Performance Goals and Procedures” commitment letter (available at
Food and Drug Administration, HHS.
Notice.
The Food and Drug Administration (FDA, Agency, or we) is announcing that a proposed collection of information has been submitted to the Office of Management and Budget (OMB) for review and clearance under the Paperwork Reduction Act of 1995.
Submit written comments (including recommendations) on the collection of information by January 12, 2023.
To ensure that comments on the information collection are received, OMB recommends that written comments be submitted to
Domini Bean, Office of Operations, Food and Drug Administration, Three White Flint North, 10A-12M, 11601 Landsdown St., North Bethesda, MD 20852, 301-796-5733,
In compliance with 44 U.S.C. 3507, FDA has submitted the following proposed collection of information to OMB for review and clearance.
This information collection supports Agency regulations and recommendations found in associated Agency guidance, as discussed below. Under section 705 of the Federal Food, Drug, and Cosmetic Act (FD&C Act) (21 U.S.C. 375), the Secretary of the Department of Health and Human Services (the Secretary) may require dissemination of information for drugs in situations that involve, in the Secretary's opinion, “imminent danger to health, or gross deception of the consumer.” Implementing regulations are found in § 200.5 (21 CFR 200.5) and outline the general provisions for “Dear Healthcare Provider” (DHCP) letters that manufacturers and distributors disseminate about important drug warnings, important prescribing information, and important correction of drug information. The regulations also prescribe certain format and content instructions regarding the dissemination of covered information. Manufacturers or distributors send DHCP letters to physicians and other healthcare providers to communicate an important drug warning, a change in prescribing information, or a correction of misinformation in prescription drug promotional labeling or advertising. We developed the guidance document entitled “Dear Healthcare Provider Letters: Improving Communication of Important Safety Information” (January 2014), available at
In addition to the content and format recommendations for each type of DHCP letter, the guidance also includes recommendations on consulting with FDA on: (1) how to develop a DHCP letter; (2) when to send a letter; (3) what type of letter to send; and (4) how to assess the letter's impact.
In the
We estimate the burden of this collection of information as follows:
We have identified 24 DHCP letters that 18 distinct sponsors submitted to FDA during the 3-year period (2019 to 2021). Based on our Document Archiving, Reporting, and Regulatory Tracking System, we estimate eight DHCP letters will be submitted annually from six application holders. Based on our experience, we assume that each letter will require 100 hours to prepare and disseminate as recommended in the guidance. Our estimate reflects a downward adjustment by five responses and 500 hours annually. We attribute this decrease to the effectiveness of the guidance and the decreased number of DHCP letters submitted for FDA review.
Health Resources and Services Administration (HRSA), Department of Health and Human Services.
Notice.
In compliance with the requirement for opportunity for public comment on proposed data collection projects of the Paperwork Reduction Act of 1995, HRSA announces plans to submit an Information Collection Request (ICR), described below, to the Office of Management and Budget (OMB). Prior to submitting the ICR to OMB, HRSA seeks comments from the public regarding the burden estimate, below, or any other aspect of the ICR.
Comments on this ICR should be received no later than February 13, 2023.
Submit your comments to
To request more information on the proposed project or to obtain a copy of the data collection plans and draft instruments, email
When submitting comments or requesting information, please include the ICR title for reference.
The THCGME program awards payment for both direct and indirect expenses to support training for primary care residents in community-based ambulatory patient care settings. Direct expense payments are designed to compensate eligible teaching health centers for those expenses directly associated with sponsoring resident training programs, while indirect expense payments are intended to compensate for the additional costs relating to teaching residents in such programs.
HRSA collects information from THCGME program award recipients using an OMB-approved reconciliation tool. HRSA seeks to extend its approved information collection and is increasing the total estimated annual burden hours associated with the collection, due to an increase in the number of program award recipients from 58 to 83.
HRSA specifically requests comments on (1) the necessity and utility of the proposed information collection for the proper performance of the agency's functions; (2) the accuracy of the estimated burden; (3) ways to enhance the quality, utility, and clarity of the information to be collected; and (4) the use of automated collection techniques or other forms of information technology to minimize the information collection burden.
Office of the National Coordinator for Health Information Technology (ONC), HHS.
Notice of meetings.
The Health Information Technology Advisory Committee (HITAC) was established in accordance with the 21st Century Cures Act and the Federal Advisory Committee Act. The HITAC, among other things, identifies priorities for standards adoption and makes recommendations to the National Coordinator for Health Information Technology (National Coordinator). The HITAC will hold public meetings throughout 2023. See list of public meetings below.
Michael Berry, Designated Federal Officer, at
Section 4003(e) of the 21st Century Cures Act (Pub. L. 114-255) establishes the Health Information Technology Advisory Committee (referred to as the “HITAC”). The HITAC will be governed by the provisions of the Federal Advisory Committee Act (FACA) (Pub. L. 92-463), as amended, (5 U.S.C. app.), which sets forth standards for the formation and use of federal advisory committees.
The HITAC is comprised of at least 25 members, of which:
• No fewer than 2 members are advocates for patients or consumers of health information technology;
• 3 members are appointed by the HHS Secretary
○ 1 of whom shall be appointed to represent the Department of Health and Human Services and
○ 1 of whom shall be a public health official;
• 2 members are appointed by the majority leader of the Senate;
• 2 members are appointed by the minority leader of the Senate;
• 2 members are appointed by the Speaker of the House of Representatives;
• 2 members are appointed by the minority leader of the House of Representatives; and
• Other members are appointed by the Comptroller General of the United States.
Members serve for one-, two-, or three-year terms. All members may be reappointed for a subsequent three-year term. Each member is limited to two three-year terms, not to exceed six years of service. Members serve without pay, but will be provided per-diem and travel costs for committee services, if warranted.
The HITAC recommendations to the National Coordinator are publicly available at
The schedule of meetings to be held in 2023 is as follows:
All meetings are open to the public. Additional meetings may be scheduled as needed. For web conference instructions and the most up-to-date information, please visit the HITAC calendar on the ONC website,
All HITAC meetings in 2023 will be virtual until further notice. Please refer to future
Notice of these meetings are given under the Federal Advisory Committee Act (Pub. L. 92-463, 5 U.S.C., app. 2).
Office of the Secretary, HHS.
Notice.
In compliance with the requirement of the Paperwork Reduction Act of 1995, the Office of the Secretary (OS), Department of Health and Human Services, is publishing the following summary of a proposed collection for public comment.
Comments on the ICR must be received on or before February 13, 2023.
Submit your comments to
When submitting comments or requesting information, please include the document identifier 0990-New-60D and project title for reference, to Sherrette A. Funn, email:
Interested persons are invited to send comments regarding this burden estimate or any other aspect of this collection of information, including any of the following subjects: (1) The necessity and utility of the proposed information collection for the proper performance of the agency's functions; (2) the accuracy of the estimated burden; (3) ways to enhance the quality, utility, and clarity of the information to be collected; and (4) the use of automated collection techniques or other forms of information technology to minimize the information collection burden.
Pursuant to section 10(d) of the Federal Advisory Committee Act, as amended, notice is hereby given of a meeting of the National Center for Advancing Translational Sciences Advisory Council.
This meeting is being held virtually only; there is no in-person option. The open session will be videocast and may be accessed by the public from the NIH Videocasting and Podcasting website (
The meeting will be closed to the public in accordance with the provisions set forth in sections 552b(c)(4) and 552b(c)(6), title 5 U.S.C.,
Closed: 11:00 a.m. to 12:30 p.m.
Open: 1:00 p.m. to 6:00 p.m.
Any interested person may file written comments with the committee by forwarding the statement to the Contact Person listed on this notice no later than 15 days after the meeting at
Pursuant to section 10(a) of the Federal Advisory Committee Act, as amended, notice is hereby given of a meeting of the Sickle Cell Disease Advisory Committee.
The meeting will be open to the public through a virtual meeting. Individuals who plan to attend and need special assistance, such as sign language interpretation or other reasonable accommodations, should notify the Contact Person listed below in advance of the meeting.
Any member of the public interested in presenting oral comments to the committee may notify the Contact Person listed on this notice at least 10 days in advance of the meeting. Interested individuals and representatives of organizations may submit a letter of intent, a brief description of the organization represented, and a short description of the oral presentation. Only one representative of an organization may be allowed to present oral comments and if accepted by the committee, presentations may be limited to five minutes. Both printed and electronic copies are requested for the record. In addition, any interested person may file written comments with the committee by forwarding their statement to the Contact Person listed on this notice. The statement should include the name, address, telephone number and when applicable, the business or professional affiliation of the interested person.
Information is also available on the Institute's/Center's home page:
National Institutes of Health, HHS.
Request for information; correction.
The Department of Health and Human Services, National Institutes of Health published a Notice in the
Questions about this request for information should be directed to Office of Extramural Research, Dr. Kristin Kramer, Phone number (301) 437-0911, Email
In the
March 2021 slides; currently reads
Final recommendations from the CSR Advisory Council report; currently reads
Additional background information can be found here; currently reads
Detailed descriptions of the three factors can be found here; currently reads
Federal Emergency Management Agency, Department of Homeland Security.
60-Day notice of revision and request for comments.
The Federal Emergency Management Agency (FEMA), as part of its continuing effort to reduce paperwork and respondent burden, invites the general public to take this opportunity to comment on an extension, with change, of a currently approved information collection. In accordance with the Paperwork Reduction Act of 1995, this notice seeks comments concerning the collection of information necessary to allow FEMA to support the needs of State, Tribes, and Territories during disaster situations through the use of other Federal agency resources.
Comments must be submitted on or before February 13, 2023.
To avoid duplicate submissions to the docket, please submit comments at
All submissions received must include the agency name and Docket ID. Regardless of the method used for submitting comments or material, all submissions will be posted, without change, to the Federal eRulemaking Portal at
John Walls, via email:
According to the Robert T. Stafford Disaster Relief and Emergency Assistance Act (Stafford Act), 42 U.S.C. 5121
Comments may be submitted as indicated in the
Fish and Wildlife Service, Interior.
Notice of information collection; request for comment.
In accordance with the Paperwork Reduction Act of 1995, we, the U.S. Fish and Wildlife Service (Service), are proposing to renew an information collection.
Interested persons are invited to submit comments on or before January 12, 2023.
Written comments and recommendations for the proposed information collection should be sent within 30 days of publication of this notice to
Madonna L. Baucum, Service Information Collection Clearance Officer, by email at
In accordance with the Paperwork Reduction Act (PRA, 44 U.S.C. 3501
On March 4, 2022, we published in the
As part of our continuing effort to reduce paperwork and respondent burdens, we invite the public and other Federal agencies to comment on new, proposed, revised, and continuing collections of information. This helps us assess the impact of our information collection requirements and minimize the public's reporting burden. It also helps the public understand our information collection requirements and provide the requested data in the desired format.
We are especially interested in public comment addressing the following:
(1) Whether or not the collection of information is necessary for the proper performance of the functions of the agency, including whether or not the information will have practical utility;
(2) The accuracy of our estimate of the burden for this collection of information, including the validity of the methodology and assumptions used;
(3) Ways to enhance the quality, utility, and clarity of the information to be collected; and
(4) How might the agency minimize the burden of the collection of information on those who are to respond, including through the use of appropriate automated, electronic, mechanical, or other technological collection techniques or other forms of information technology,
Comments that you submit in response to this notice are a matter of public record. We will include or summarize each comment in our request to OMB to approve this ICR. Before including your address, phone number, email address, or other personal identifying information in your comment, you should be aware that your entire comment—including your personal identifying information—may be made publicly available at any time. While you can ask us in your comment to withhold your personal identifying information from public review, we cannot guarantee that we will be able to do so.
The Electronic Duck Stamp Act of 2005 (Pub. L. 109-266) required the Secretary of the Interior to conduct a 3-year pilot program, under which States could issue electronic Federal Duck Stamps. This pilot program is now permanent with the passage of the Permanent Electronic Duck Stamp Act of 2013 (Pub. L. 113-239). Anyone, regardless of State residence, is able to purchase an electronic Duck Stamp through any State that participates in the program. The electronic stamp is issued as a temporary permit and is valid from the date of purchase through up to 45 days after the date of purchase, and thus is available for immediate use by the purchaser while he or she waits to receive the actual physical stamp in the mail. Upon receipt of the physical stamp or after the temporary permit expires, whichever comes first, the purchaser must carry the signed physical Federal Duck Stamp while hunting or to gain fee-free access to national wildlife refuges.
Eight States participated in the pilot. At the end of the pilot, we provided a report to Congress outlining the successes of the program. The program improved public participation by increasing the ability of the public to obtain required Federal Duck Stamps.
Under our authorities in 16 U.S.C. 718
• Information verifying the current systems the State uses to sell hunting, fishing, and other associated licenses and products.
• Applicable State laws, regulations, or policies that authorize the use of electronic systems to issue licenses.
• Examples and explanations of the codes the State proposes to use to create and endorse the unique identifier for the individual to whom each stamp is issued.
• Mockup copy of the printed version of the State's proposed electronic stamp, including a description of how attention will be drawn to the 45-day validity of the temporary electronic stamp, customer support information, and identifying features of the licensee to be specified on the temporary permit.
• Description of any fee the State will charge for issuance of an electronic stamp.
• Description of the process the State will use to account for and transfer the amounts collected by the State that are required to be transferred under the program.
• Manner in which the State will transmit electronic stamp customer data.
Each State approved to participate in the program must provide the following information, on a regular basis (not to exceed 7 days post purchase), to the Service-approved stamp distribution company, to enable that company to issue the physical stamp within the required 45-day period:
• Full name (first, middle, last, and any prefixes/suffixes), and complete mailing address of each individual who purchases an electronic stamp from the State.
• Date of e-stamp purchase.
We did not make any substantive changes to the application form (FWS Form 3-2341); however, we updated the formatting of the form to comply with the requirements of section 508 of the Rehabilitation Act of 1973 (29 U.S.C. 794d), and to conform with formatting requirements of the Department of the Interior and the Service. No substantive changes were made to the information collected from States. Upon request, a copy of the draft form is available by sending a request to the Service Information Collection Clearance Officer at
An agency may not conduct or sponsor and a person is not required to respond to a collection of information unless it displays a currently valid OMB control number.
The authority for this action is the Paperwork Reduction Act of 1995 (44 U.S.C. 3501
Bureau of Land Management, Interior.
Notice; correction.
This notice corrects the total acreage figure and the legal land description of the proposed public land withdrawal identified as the Chaco Culture National Historical Park Area withdrawal published in the
Sarah Scott, BLM Farmington Field Office, (505) 564-7689 or
In the
secs. 3 and 5;
The area aggregates 3,188.01 acres.
National Park Service, Interior.
Meeting notice.
In accordance with the Federal Advisory Committee Act of 1972, the National Park Service (NPS) is hereby giving notice that the Acadia National Park Advisory Commission (Commission) will meet as indicated below.
The Commission will meet: Monday, February 6, 2023; Monday, June 5, 2023; and Monday, September 11, 2023. All scheduled meetings will begin at 1 p.m. and will end by 4 p.m. (Eastern).
The February 6, 2023, and June 5, 2023, meetings will be held at the headquarters conference room, Acadia National Park, 20 McFarland Hill Drive, Bar Harbor, Maine 04609. The September 11, 2023, meeting will be held at the Schoodic Education and Research Center, Winter Harbor, Maine 04693. All three meetings will also be held virtually for those who are unable to attend in person and will be closed captioned.
Kathy Flanders, Superintendent's Secretary, Acadia National Park, P.O. Box 177, Bar Harbor, Maine 04609, telephone (207) 288-8702 or
The Commission was established by section 103 of Public Law 99-420, as amended, (16 U.S.C. 341 note), and in accordance with the Federal Advisory Committee Act (5 U.S.C. appendix 1-16). The Commission advises the Secretary of the Interior and the NPS on matters relating to the management and development of Acadia National Park, including but not limited to, the acquisition of lands and interests in lands (including conservation easements on islands) and the termination of rights of use and occupancy.
The meetings are open to the public. Interested persons may make oral presentations to the Commission. Such requests should be made to the Superintendent at the beginning of the meeting. Depending on the number of persons wishing to speak, and the time available, the time for individual comments may be limited. Written comments can be sent to Kathy Flanders [see
The Commission meeting locations may change based on inclement weather or exceptional circumstances. If a meeting location is changed, the Superintendent will issue a press release and use local newspapers to announce the change. Detailed minutes of the meeting will be available for public inspection within 90 days of the meeting.
National Park Service, Interior.
Meeting notice.
The National Park Service (NPS) is hereby giving notice that the Aniakchak National Monument Subsistence Resource Commission (SRC), the Denali National Park SRC, the Cape Krusenstern National Monument SRC, the Lake Clark National Park SRC, the Kobuk Valley National Park SRC, the Wrangell-St. Elias National Park SRC, and the Gates of the Arctic National Park SRC will meet as indicated below.
The Aniakchak National Monument SRC will meet in-person and via teleconference from 1 p.m. to 5 p.m. or until business is completed on Wednesday, March 1, 2023. The alternate meeting date is Wednesday, March 8, 2023, from 1 p.m. to 5 p.m. or
The Denali National Park SRC will meet via teleconference from 1 a.m. to 5 p.m. or until business is completed on Wednesday, January 11, 2023. The alternate meeting date is Wednesday, January 18, 2023, from 1 a.m. to 5 p.m. or until business is completed only via teleconference.
The Cape Krusenstern National Monument SRC will meet in-person and via teleconference from 1 p.m. to 5 p.m. on Wednesday, February 22, 2023, and from 9 a.m. to 12 p.m. or until business is completed on Thursday, February 23, 2023. The alternate meeting dates are Monday, February 27, 2023, from 1 p.m. to 5 p.m., and Tuesday, February 28, 2023, from 9 a.m. to 12 p.m. or until business is completed at the same location and via teleconference.
The Lake Clark National Park SRC will meet in-person and via teleconference, from 1 p.m. to 4 p.m. or until business is completed on Wednesday, March 29, 2023. The alternate meeting date is Wednesday, April 5, 2023, from 1 p.m. to 4 p.m. or until business is completed at the same location and via teleconference.
The Kobuk Valley National Park SRC will meet in-person and via teleconference from 1 p.m. to 5 p.m. on Thursday, February 23, 2023, and from 9 a.m. to 12 p.m. on Friday, February 24, 2023, or until business is completed. The alternate meeting dates are Tuesday, February 28, 2023, from 1 p.m. to 5 p.m., and Wednesday, March 1, 2023, from 9 a.m. to 12 p.m. or until business is completed at the same location and via teleconference.
The Wrangell-St. Elias National Park SRC will meet in-person and via teleconference from 9 a.m. to 5 p.m. or until business is completed on both Thursday, February 23, 2023, and Friday, February 24, 2023. If business is completed on February 23, 2023, the meeting will adjourn, and no meeting will take place on February 24, 2023. The alternate meeting dates are Tuesday, March 7, 2023, and Wednesday, March 8, 2023, from 9 a.m. to 5 p.m., or until business is completed at the same location and via teleconference.
The Gates of the Arctic National Park SRC will meet in-person and via teleconference from 9 a.m. to 5 p.m. or until business is completed on both Tuesday, March 21, 2023, and Wednesday, March 22, 2023. The alternate meeting dates are Tuesday, April 18, 2023, from 9 a.m. to 5 p.m., and Wednesday, April 19, 2023, from 9 a.m. to 5 p.m. or until business is completed at the same location and via teleconference.
The Aniakchak National Monument SRC will meet in-person at the Port Heiden Community Building, 2200 James Street, Port Heiden AK 99549 and via teleconference. Teleconference participants must call the NPS office at (907) 246-2121 prior to the meeting to receive teleconference passcode information. For more detailed information regarding these meetings, or if you are interested in applying for SRC membership, contact Designated Federal Official Mark Sturm, Superintendent, at (907) 246-2120 or via email at
The Denali National Park SRC will meet only via teleconference. Teleconference participants must call the NPS office at (907) 644-3604 prior to the meeting to receive teleconference passcode information. For more detailed information regarding these meetings, or if you are interested in applying for SRC membership, contact Designated Federal Official Brooke Merrell, Superintendent, at (907) 683-9627 or via email at
The Cape Krusenstern National Monument SRC will meet in-person at the Northwest Arctic Heritage Center, 171 3rd Avenue, Kotzebue, AK 99752 and via teleconference. Teleconference participants must call the NPS office at (907) 442-8342 prior to the meeting to receive teleconference passcode information. For more detailed information regarding this meeting or if you are interested in applying for SRC membership, contact Designated Federal Official Ray McPadden, Superintendent, at (907) 442-3890 or via email at
The Lake Clark National Park SRC will meet in-person at the Nondalton Community Center, 109 Main Street, Nondalton, AK 99640 and via teleconference. Teleconference participants must call the NPS office at (907) 644-3648 prior to the meeting to receive teleconference passcode information. For more detailed information regarding this meeting or if you are interested in applying for SRC membership, contact Designated Federal Official Susanne Green, Superintendent, at (907) 644-3627 or via email at
The Kobuk Valley National Park SRC will meet in-person at the Northwest Arctic Heritage Center, 171 3rd Avenue, Kotzebue, AK 99752 and via teleconference. Teleconference participants must call the NPS office at (907) 442-8342 prior to the meeting to receive teleconference passcode information. For more detailed information regarding this meeting or if you are interested in applying for SRC membership, contact Designated Federal Official Ray McPadden, Superintendent, at (907) 442-3890 or via email at
The Wrangell-St. Elias National Park SRC will meet in-person at the Copper Center Visitor Center Complex, Wrangell-St. Elias National Park and Preserve, Mile 106.8 Richardson Highway, Copper Center, AK 99573 and via teleconference. Teleconference participants must contact Subsistence Coordinator, Barbara Cellarius, at (907) 822-7236 or
The Gates of the Arctic National Park SRC will meet in-person at the Sophie Station Hotel, Zach's Boardroom, 1717 University Avenue, Fairbanks, Alaska 99709 and via teleconference. Teleconference participants must call
In the event that an in-person meeting is not feasible or advisable, all meetings will be held solely via teleconference.
The NPS is holding meetings pursuant to the Federal Advisory Committee Act (5 U.S.C. appendix 1-16). The NPS SRC program is authorized under title VIII, section 808 of the Alaska National Interest Lands Conservation Act (16 U.S.C. 3118).
SRC meetings are open to the public and will have time allocated for public testimony. The public is welcome to present written or oral comments to the SRC. SRC meetings will be recorded and the meeting minutes will be certified by the Superintendent and available upon request 90 days after the meeting.
SRC meeting location and date may change based on inclement weather or exceptional circumstances, including public health advisories or mandates. If the meeting date and location are changed, the Superintendent will issue a press release and use local newspapers and/or radio stations to announce the rescheduled meeting.
National Park Service, Interior.
Meeting notice.
In accordance with the Federal Advisory Committee Act of 1972, the National Park Service is hereby giving notice that the Cedar Creek and Belle Grove National Historical Park Advisory Commission (Commission) will meet as indicated below.
The meeting will meet via teleconference on Thursday, February 2, 2023; Thursday, March 16, 2023; Thursday, June 15, 2023; Thursday, September 21, 2023; and Thursday, December 14, 2023. All scheduled meetings will begin at 9 a.m. and will end by 11 a.m. (EASTERN).
Information on joining the teleconference will be available on the Cedar Creek and Belle Grove National Park at
Karen Beck-Herzog, Site Manager, Cedar Creek and Belle Grove National Historical Park, P.O. Box 700, Middletown, Virginia 22645, telephone (540) 868-9176, email
The Commission was designated by Congress to provide advice to the Secretary of the Interior on the preparation and implementation of the park's general management plan and to advise on land protection (16 U.S.C. 410iii-7). The meeting is open to the public. Members of the public who are interested in the park, the implantation of the plan, or the business of the Commission are encouraged to attend. Attendees may present, either orally or through written comments, information for the Commission to consider during the meeting. Attendees and those wishing to provide comment are strongly encouraged to preregister through the contact information provided. Written comments may be sent to Karen Beck-Herzog (see
Commission meetings consist of the following:
Bureau of Reclamation, Interior.
Rescindment of a system of records notice.
The Department of the Interior (DOI) is issuing a public notice of its intent to rescind the Bureau of Reclamation (Reclamation) Privacy Act system of records notice, INTERIOR/WBR-48, Lower Colorado River Well Inventory, from its existing inventory. This system of records was maintained by Reclamation and is no longer required as the records are neither stored nor retrieved using an individual's personal identifier. All well inventory records are stored and retrieved by either site identification data or well number. As such, these records do not meet the statutory definition of a system of records under the Privacy Act.
These changes take effect on December 13, 2022.
You may send comments identified by docket number [DOI-2022-0013] by any of the following methods:
•
•
•
You should be aware your entire comment including your personally identifiable information, such as your address, phone number, email address, or any other personal information in your comment, may be made publicly available at any time. While you may request to withhold your personally identifiable information from public review, we cannot guarantee we will be able to do so.
Regina Magno, Associate Privacy Officer, Bureau of Reclamation, P.O. Box 25007, Denver, CO 80225,
Pursuant to the provisions of the Privacy Act of 1974, as amended, 5 U.S.C. 552a, Reclamation is rescinding the INTERIOR/WBR-48, Lower Colorado River Well Inventory, system of records notice from its inventory. An assessment of the well inventory records by the Reclamation Associate Privacy Officer revealed that the records contained therein are not stored, maintained or retrieved by use of an individual's personal identifier. Reclamation utilizes these records to support the annual compilation and publication of records of consumptive use of mainstream Colorado River water. The records include contact information for individuals or groups that own or have physical control of wells or access sites (site owners) where Reclamation collects groundwater data. Site owner contact information stored in these records may include name, address, phone number and email address, when provided. These records are saved and retrieved by use of the site identification data or well number; records cannot be retrieved by use of the site owner's personal information. Therefore, these records do not meet the statutory definition of a system of records under the Privacy Act of 1974. Rescindment of INTERIOR/WBR-48, Lower Colorado River Well Inventory, will ensure statutory compliance with the Privacy Act of 1974, as amended, and Office of Management and Budget Circular A-108,
Rescinding the INTERIOR/WBR-48, Lower Colorado River Well Inventory, system of records notice will have no adverse impacts on individual privacy of the site and well owners. Controls are in place to ensure contact information is only accessible to authorized Reclamation personnel; it is not published or released to the public. The affected records will continue to be maintained under the applicable records schedules as approved by the National Archives and Records Administration. This rescindment will also promote the overall streamlining and management of DOI Privacy Act systems of records.
INTERIOR/WBR-48, Lower Colorado River Well Inventory.
64 FR 29874 (June 3, 1999); modification published at 73 FR 20949 (April 17, 2008) and 86 FR 50156 (September 7, 2021).
U.S. International Trade Commission.
Notice.
Notice is hereby given that the U.S. International Trade Commission (the “Commission”) has determined to review in part the final initial determination (“ID”) issued by the presiding administrative law judge (“ALJ”). On review, the Commission has determined to affirm the final ID's finding of no violation. The investigation is hereby terminated.
Carl P. Bretscher, Office of the General Counsel, U.S. International Trade Commission, 500 E Street SW, Washington, DC 20436, telephone (202) 205-2382. Copies of non-confidential documents filed in connection with this investigation may be viewed on the Commission's electronic docket system (“EDIS”) at
On June 28, 2021, the Commission instituted this investigation based on a complaint filed by Arigna Technology Limited of Carrickmines, Ireland (“Arigna”). 86 FR 34042-43 (Jun. 28, 2021). The complaint, as amended, alleges violations of section 337 of the Tariff Act of 1930, as amended, 19 U.S.C. 1337 (“section 337”), based upon the importation into the United States, the sale for importation, and the sale within the United States after importation of certain power inverters and converters, vehicles containing the same, and components thereof that infringe one of more of the asserted claims of U.S. Patent Nos. 8,247,867 (“the '867 patent”) and 8,289,082 (“the '082 patent”).
The Commission's notice of investigation named the following respondents: Audi AG of Ingolstadt, Germany and Audi of America, LLC of Herndon, Virginia (collectively, “Audi”); Bentley MotorsLimited. of Crewe, United Kingdom and Bentley Motors, Inc. of Reston, Virginia (collectively, “Bentley”); Bayerische Motoren Werke AG of Munich, Germany and BMW of North America, LLC, of Woodcliff Lake, New Jersey (collectively, “BMW”); Daimler AG of Stuttgart, Germany and Mercedes-Benz USA, LLC of Sandy Springs, Georgia (collectively, “Daimler”); General Motors Company of Detroit, Michigan (“GMC”); General Motors LLC of Detroit, Michigan (“GM”); Automobili Lamborghini S.p.A. of Sant'Agata, Italy and Automobili Lamborghini America, LLC of Herndon, Virginia (collectively, “Lamborghini”); Porsche AG of Stuttgart, Germany and Porsche Cars North America, Inc. of Atlanta, Georgia (collectively, “Porsche”); and Volkswagen AG of Wolfsburg, Germany and Volkswagen Group of America, Inc. of Herndon, Virginia (collectively, “Volkswagen”) (all collectively, “Respondents”).
On December 1, 2021, the presiding administrative law judge (“ALJ”) held a
On January 18, 2022, the Commission terminated the investigation with respect to General Motors Company based on a withdrawal of the complaint. Order No. 23 (Dec. 20, 2021),
On March 15, 2022, the Commission partially terminated the '867 patent from the investigation as asserted against BMW. Order No. 37 (Feb. 18, 2022),
On April 25, 2022, the Commission terminated certain claims of the '082 patent and '867 patent based on a partial withdrawal of the complaint. Order No. 50 (Apr. 6, 2022),
On May 17, 2022, the Commission terminated the investigation with respect to Porsche due to a settlement agreement. Order No. 53 (April 29, 2022),
The presiding ALJ held an evidentiary hearing on April 4-8, 2022. The parties timely filed their initial post-hearing briefs on April 25, 2022, and their post-hearing reply briefs on May 4, 2022.
On August 12, 2022, the presiding ALJ issued the subject ID, finding no violation of section 337 with respect to either the '082 patent or the '867 patent. In particular, the ID finds: (1) Arigna failed to prove that Respondents infringed any of asserted claims 1, 13, 17, or 29 of the '082 patent; (2) claims 1, 13, 17, and 29 of the '082 patent are invalid as anticipated or obvious over the prior art; (3) Respondents did not infringe asserted claim 8 of the '867 patent; (4) claim 4 of the '867 patent (asserted for domestic industry purposes) is invalid as anticipated; but asserted claim 8 is not invalid; and (5) Arigna has not satisfied the economic prong of the domestic industry requirement with respect to the '867 patent.
On August 26, 2022, the presiding ALJ issued a recommended determination on remedy, the public interest, and bonding, recommending that the Commission issue a limited exclusion order (subject to a delay in implementation of up to six months) and cease and desist orders against Audi, BMW, Mercedes, GM, and Volkswagen (but not Bentley or Lamborghini), and set a zero percent bond, should the Commission find a violation of section 337.
On August 26, 2022, Arigna filed a petition for review of the ID's findings on claim construction, non-infringement, and invalidity with respect to the '082 patent. No other party petitioned for review of the ID's findings regarding the '082 patent.
On August 26, 2022, respondent GM filed a contingent petition for review of the ID's finding that asserted claim 8 of the '867 patent is not invalid. No other party, including Arigna, petitioned for review of any findings regarding the '867 patent.
On September 6, 2022, Respondents and OUII each filed their opposition to Arigna's petition for review of the ID's findings with respect to the '082 patent. OUII filed a response to GM's contingent petition for review on the same date.
On November 22, 2022, the Commission terminated the investigation with respect to Daimler, Volkswagen, Audi, Bentley, and Lamborghini due to settlement agreements. Comm'n Notice (Nov. 22, 2022). BMW and GM remain as respondents.
Upon consideration of the ID, the parties' submissions, and the evidence of record, the Commission has determined to review in part and, on
The Commission has determined not to review, and thereby adopts, the ID's remaining findings, including with respect to the '082 patent: (a) the ID's claim constructions; (b) that Arigna failed to prove that Respondents infringed any of asserted claims 1, 13, 17, and 29; (c) that asserted independent claims 1 and 17 are invalid as anticipated by a prior art article written by Suharli Tedja et al. and published in the IEEE Journal of Solid-State Circuits in February 1995 (“Tedja”); (d) that asserted dependent claims 13 and 29 are invalid as obvious over Tedja alone or Tedja in combination with Kozisek; and (e) that asserted claims 1, 13, 17, and 29 are invalid as obvious over Kozisek in combination with Soneda. The Commission has further determined not to review the ID's findings that the asserted claims of the '867 patent are not infringed and claim 4 is invalid as anticipated by International Patent Application Publication WO 2009/060670 to Torii.
For the foregoing reasons, the Commission concludes that there is no violation of section 337 with respect to either the '082 patent or '867 patent. This investigation is hereby terminated.
The Commission voted to approve this determination on December 7, 2022.
The authority for the Commission's determination is contained in section 337 of the Tariff Act of 1930, as amended (19 U.S.C. 1337), and in part 210 of the Commission's Rules of Practice and Procedure (19 CFR part 210).
By order of the Commission.
U.S. International Trade Commission.
Notice.
Notice is hereby given that a complaint was filed with the U.S. International Trade Commission on November 7, 2022, under section 337 of the Tariff Act of 1930, as amended, on behalf of Dometic Corporation of Rosemont, Illinois and Dometic Sweden AB of Solna, Sweden. Supplements were filed on November 10, November 25, and November 28, 2022. The complaint alleges violations of section 337 based upon the importation into the United States, the sale for importation, and the sale within the United States after importation of certain marine air conditioning systems, components thereof, and products containing same by reason of the infringement of certain claims of U.S. Patent No. 8,056,351 (“the '351 patent”). The complaint further alleges that an industry in the United States exists as required by the applicable Federal Statute. The complainant requests that the Commission institute an investigation and, after the investigation, issue a limited exclusion order and cease and desist orders.
The complaint, except for any confidential information contained therein, may be viewed on the Commission's electronic docket (EDIS) at
Jessica Mullan, Office of Docket Services, U.S. International Trade Commission, telephone (202) 205-1802.
Authority: The authority for institution of this investigation is contained in section 337 of the Tariff Act of 1930, as amended, 19 U.S.C. 1337, and in section 210.10 of the Commission's Rules of Practice and Procedure, 19 CFR 210.10 (2022).
(1) Pursuant to subsection (b) of section 337 of the Tariff Act of 1930, as amended, an investigation be instituted to determine whether there is a violation of subsection (a)(1)(B) of section 337 in the importation into the United States, the sale for importation, or the sale within the United States after importation of certain products identified in paragraph (2) by reason of infringement of one or more of claims 1-5, 7, 11, and 17-22 of the '351 patent, and whether an industry in the United States exists as required by subsection (a)(2) of section 337;
(2) Pursuant to section 210.10(b)(1) of the Commission's Rules of Practice and Procedure, 19 CFR 210.10(b)(1), the plain language description of the accused products or category of accused products, which defines the scope of the investigation, is “marine air conditioning systems for use in nautical vehicles, having marine blower systems adapted to nautical vehicles, main body systems for use in marine air conditioning units, or assemblies for adjusting the blower with respect to the aforementioned main body”;
(3) For the purpose of the investigation so instituted, the following are hereby named as parties upon which this notice of investigation shall be served:
(a) The complainants are:
(b) The respondents are the following entities alleged to be in violation of section 337, and are the parties upon which the complaint is to be served:
(3) For the investigation so instituted, the Chief Administrative Law Judge, U.S. International Trade Commission, shall designate the presiding Administrative Law Judge.
The Office of Unfair Import Investigation is not a party to this investigation.
Responses to the complaint and the notice of investigation must be submitted by the named respondents in accordance with section 210.13 of the Commission's Rules of Practice and Procedure, 19 CFR 210.13. Pursuant to 19 CFR 201.16(e) and 210.13(a), as amended in 85 FR 15798 (March 19, 2020), such responses will be considered by the Commission if received not later than 20 days after the date of service by the complainants of the complaint and the notice of investigation. Extensions of time for submitting responses to the complaint and the notice of investigation will not be granted unless good cause therefor is shown.
Failure of a respondent to file a timely response to each allegation in the complaint and in this notice may be deemed to constitute a waiver of the right to appear and contest the allegations of the complaint and this notice, and to authorize the administrative law judge and the Commission, without further notice to the respondent, to find the facts to be as alleged in the complaint and this notice and to enter an initial determination and a final determination containing such findings, and may result in the issuance of an exclusion order or a cease and desist order or both directed against the respondent.
By order of the Commission.
Bureau of Alcohol, Tobacco, Firearms and Explosives, Department of Justice.
30-Day notice.
The Bureau of Alcohol, Tobacco, Firearms and Explosives (ATF), Department of Justice (DOJ) will submit the following information collection request to the Office of Management and Budget (OMB) for review and approval in accordance with the Paperwork Reduction Act of 1995. The proposed collection OMB 1140-0102 (FEL Out of Business Records) is being revised due to an increase in the number of respondents to this IC, which has also contributed to a rise in both the public burden hours and cost associated with this IC since the last renewal in 2019.
Comments are encouraged and will be accepted for an additional 30 days until January 12, 2023.
Written comments and recommendations for the proposed information collection should be sent within 30 days of publication of this notice to
Written comments and suggestions from the public and affected agencies concerning the proposed collection of information are encouraged. Your comments should address one or more of the following four points:
• Evaluate whether the proposed collection of information is necessary for the proper performance of the functions of the agency, including whether the information will have practical utility;
• Evaluate the accuracy of the agency's estimate of the burden of the proposed collection of information, including the validity of the methodology and assumptions used;
• Evaluate whether and, if so, how the quality, utility, and clarity of the information to be collected can be enhanced; and
• Minimize the burden of the collection of information on those who are to respond, including through the use of appropriate automated, electronic, mechanical, or other technological collection techniques or other forms of information technology,
Overview of this information collection:
1.
2.
3.
4.
5.
7.
If additional information is required contact: Robert Houser, Department Clearance Officer, Policy and Planning Staff, Office of the Chief Information Officer, United States Department of Justice, Justice Management Division, Two Constitution Square, 145 N Street NE, Mail Stop 3.E-206, Washington, DC 20530.
On December 7, 2022, the Department of Justice lodged a proposed Consent Decree with the United States District Court for the District of Nebraska in the lawsuit entitled
The proposed consent decree resolves claims against Dravo, LLC, formerly known as Dravo Corp., pursuant to the section 107(a) CERCLA for response costs incurred and to be incurred by EPA for Operable Units 01 and 19 of the Hastings Groundwater Contamination Superfund Site. The settlement requires Defendant to make a payment of $1,439,336 to EPA, based on analysis of Defendant's financial inability to pay.
The publication of this notice opens a period for public comment on the consent decree. Comments should be addressed to the Assistant Attorney General, Environment and Natural Resources Division, and should refer to
During the public comment period, the consent decree may be examined and downloaded at this Justice Department website:
Please enclose a check or money order for $7.00 (25 cents per page reproduction cost) payable to the United States Treasury.
Copyright Royalty Board, Library of Congress.
Notice requesting comments.
The Copyright Royalty Judges solicit comments on a motion of the Allocation Parties for further partial distribution of 2015-2017 satellite royalty funds.
Comments are due on or before January 12, 2023.
Interested claimants must submit timely comments using eCRB, the Copyright Royalty Board's online electronic filing application, at
Anita Brown, Program Specialist, 202-707-7658,
Each year satellite television providers must submit royalty payments to the Register of Copyrights as required by the statutory license set forth in section 119 of the Copyright Act for the retransmission to satellite service subscribers of over-the-air television broadcast signals.
Allocation of the royalties collected occurs in one of two ways. In the first instance, the Judges may authorize distribution in accordance with a negotiated settlement among all claiming parties.
On August 17, 2022, representatives of all the Allocation Phase claimant categories
Parties objecting to the proposed partial distribution must advise the Judges of the existence and extent of all their objections by the end of the comment period. The Judges will not consider any objections with respect to the partial distribution motion that come to their attention after the close of the comment period.
The Motion is available for review in eCRB, the CRB'S electronic filing site, at
10:00 a.m., December 15, 2022.
Board Room, 7th Floor, Room 7B, 1775 Duke Street (All visitors must use Diagonal Road Entrance), Alexandria, VA 22314-3428.
This meeting will be open to the public.
1. Board Briefing, Share Insurance Fund 2023 Normal Operating Level.
2. NCUA's 2023-2024 Budget.
3. NCUA Rules and Regulations, Financial Innovation—Loan Participation, Eligible Obligations, and Notes of Liquidating Credit Unions.
Melane Conyers-Ausbrooks, Secretary of the Board, Telephone: 703-518-6304.
Nuclear Regulatory Commission.
Intent To conduct scoping process and prepare environmental impact statement; public scoping meeting, and request for comment.
The U.S. Nuclear Regulatory Commission (NRC) will conduct a scoping process to gather information necessary to prepare an environmental impact statement (EIS) to evaluate the environmental impacts for the license renewal of the operating licenses for Comanche Peak Nuclear Power Plant (CPNPP), Units 1 and 2. The NRC is seeking public comment on this action and has scheduled a public scoping meeting that will take place in Glen Rose, Texas.
The NRC will hold a public scoping meeting on January 10, 2023, from 1 to 3 p.m. and 5 to 7 p.m. local time. Submit comments on the scope of the EIS by January 30, 2023. Comments received after this date will be considered if it is practical to do so, but the NRC is able to ensure consideration only for comments received on or before this date. See Section IV, “Public Scoping Meeting,” of this notice for additional information.
You may submit comments by any of the following methods; however, the NRC encourages electronic comment submission through the Federal rulemaking website.
•
•
•
•
For additional direction on obtaining information and submitting comments, see “Obtaining Information and Submitting Comments” in the
Tam Tran, Office of Nuclear Material Safety and Safeguards, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001; telephone: 301-415-3617; email:
Please refer to Docket ID NRC-2022-0183 when contacting the NRC about the availability of information regarding this document. You may obtain publicly available information related to this document by any of the following methods:
•
•
•
The NRC encourages electronic comment submission through the Federal rulemaking website (
The NRC cautions you not to include identifying or contact information that you do not want to be publicly disclosed in your comment submission. The NRC will post all comment submissions at
If you are requesting or aggregating comments from other persons for submission to the NRC, then you should inform those persons not to include identifying or contact information that they do not want to be publicly disclosed in their comment submission. Your request should state that the NRC does not routinely edit comment submissions to remove such information before making the comment submissions available to the public or entering the comment submissions into ADAMS.
On October 3, 2022, the NRC received an application for the renewal of Facility Operating License Nos. NPF-87 and NPF89, which would authorize Vistra Operations Company LLC (Vistra, the applicant) to operate CPNPP, Units 1 and 2 for an additional 20 years of operation beyond the period specified in each of the current licenses (ADAMS Accession No. ML22276A082). This submission initiated the NRC's proposed action: determining whether to grant or deny the license renewal
This notice informs the public of the NRC's intention to conduct environmental scoping and prepare an EIS related to the license renewal application for CPNPP, and to provide the public an opportunity to participate in the environmental scoping process, as defined in 10 CFR 51.29.
The regulations in 36 CFR 800.8, “Coordination with the National Environmental Policy Act,” allow agencies to use their National Environmental Policy Act of 1969 (42 U.S.C. 4321,
In accordance with 10 CFR 51.53(c) and 10 CFR 54.23, Vistra submitted an ER as part of the license renewal application. The ER was prepared pursuant to 10 CFR part 51 and is available in ADAMS under Accession No. ML22297A246. The ER may also be viewed on the NRC public website at
As required by 10 CFR 51.95, the NRC intends to gather the information necessary to prepare a plant-specific supplement (supplement 60) to the NRC's NUREG-1437, “Generic Environmental Impact Statement for License Renewal of Nuclear Plants” (ADAMS Package Accession No. ML13107A023) (GEIS), related to the license renewal application for CPNPP Units 1 and 2. This notice is being published in accordance with NEPA and the NRC's regulations found at 10 CFR part 51.
Supplement 60 to the GEIS will evaluate the environmental impacts of the license renewal for CPNPP Units 1 and 2, and reasonable alternatives thereto. Possible alternatives to the proposed action include the no action alternative and reasonable alternative energy sources.
As part of its environmental review, the NRC will first conduct a scoping process for the supplement 60 to the GEIS and, as soon as practicable thereafter, will prepare a draft supplement 60 to the GEIS for public comment. Participation in this scoping process by members of the public and local, State, Tribal, and Federal government agencies is encouraged. The scoping process for the supplement 60 to the GEIS will be used to accomplish the following:
a. Define the proposed action, which is to be the subject of the supplement 60 to the GEIS;
b. Determine the scope of the supplement 60 to the GEIS and identify the significant issues to be analyzed in depth;
c. Identify and eliminate from detailed study those issues that are peripheral or are not significant; or were covered by a prior environmental review;
d. Identify any environmental assessments and other ElSs that are being or will be prepared that are related to, but are not part of, the scope of the supplement 60 to the GEIS being considered;
e. Identify other environmental review and consultation requirements related to the proposed action;
f. Indicate the relationship between the timing of the preparation of the environmental analyses and the Commission's tentative planning and decisionmaking schedule;
g. Identify any cooperating agencies and, as appropriate, allocate assignments for preparation and schedules for completing the supplement 60 to the GEIS to the NRC and any cooperating agencies; and
h. Describe how the supplement 60 to the GEIS will be prepared, including any contractor assistance to be used.
The NRC invites the following entities to participate in scoping:
a. The applicant, Vistra;
b. Any Federal agency that has jurisdiction by law or special expertise with respect to any environmental impact involved or that is authorized to develop and enforce relevant environmental standards;
c. Affected State and local government agencies, including those authorized to develop and enforce relevant environmental standards;
d. Any affected Indian Tribe;
e. Any person who requests or has requested an opportunity to participate in the scoping process; and
f. Any person who has petitioned or intends to petition for leave to intervene under 10 CFR 2.309.
In accordance with 10 CFR 51.26(b), the scoping process for an EIS may include a public scoping meeting to help identify significant issues related to a proposed activity and to determine the scope of issues to be addressed in an EIS.
The NRC is announcing that it will hold a public scoping meeting for the CPNPP Units 1 and 2 license renewal supplement 60 to the GEIS. A court reporter will record and transcribe all comments received during the meeting. To be considered, comments must be provided either at the transcribed public meeting or in writing, as discussed in the
In addition, the NRC staff will host informal discussions one hour before the start of each session at the same location. The staff will not accept formal comments on the proposed scope of the supplement 60 to the GEIS during these informal discussions.
The public scoping meeting will include: (1) an overview by the NRC staff of the environmental and safety review processes, the proposed scope of the supplement 60 to the GEIS, and the proposed review schedule; and (2) the opportunity for interested government agencies, organizations, and individuals to submit comments or suggestions on environmental issues or the proposed scope of the supplement 60 to the GEIS.
Persons interested in attending should monitor the NRC's Public Meeting Schedule at
Participation in the scoping process for the supplement 60 to the GEIS does not entitle participants to become parties to the proceeding to which the supplement 60 to the GEIS relates. Matters related to participation in any hearing are outside the scope of matters to be discussed at this public meeting.
For the Nuclear Regulatory Commission.
Postal Regulatory Commission.
Notice.
The Commission is noticing a recent Postal Service filing for the Commission's consideration concerning a negotiated service agreement. This notice informs the public of the filing, invites public comment, and takes other administrative steps.
Submit comments electronically via the Commission's Filing Online system at
David A. Trissell, General Counsel, at 202-789-6820.
The Commission gives notice that the Postal Service filed request(s) for the Commission to consider matters related to negotiated service agreement(s). The request(s) may propose the addition or removal of a negotiated service agreement from the Market Dominant or the Competitive product list, or the modification of an existing product currently appearing on the Market Dominant or the Competitive product list.
Section II identifies the docket number(s) associated with each Postal Service request, the title of each Postal Service request, the request's acceptance date, and the authority cited by the Postal Service for each request. For each request, the Commission appoints an officer of the Commission to represent the interests of the general public in the proceeding, pursuant to 39 U.S.C. 505 (Public Representative). Section II also establishes comment deadline(s) pertaining to each request.
The public portions of the Postal Service's request(s) can be accessed via the Commission's website (
The Commission invites comments on whether the Postal Service's request(s) in the captioned docket(s) are consistent with the policies of title 39. For request(s) that the Postal Service states concern Market Dominant product(s), applicable statutory and regulatory requirements include 39 U.S.C. 3622, 39 U.S.C. 3642, 39 CFR part 3030, and 39 CFR part 3040, subpart B. For request(s) that the Postal Service states concern Competitive product(s), applicable statutory and regulatory requirements include 39 U.S.C. 3632, 39 U.S.C. 3633, 39 U.S.C. 3642, 39 CFR part 3035, and 39 CFR part 3040, subpart B. Comment deadline(s) for each request appear in section II.
1.
This Notice will be published in the
Notice is hereby given that, pursuant to the Paperwork Reduction Act of 1995 (44 U.S.C. 3501-3521) (“Paperwork Reduction Act”), the Securities and Exchange Commission (the “Commission”) is soliciting comments on the collections of information summarized below. The Commission plans to submit these existing collections of information to the Office of Management and Budget (“OMB”) for extension and approval.
Rule 17f-7 (17 CFR 270.17f-7) permits a fund under certain conditions to maintain its foreign assets with an eligible securities depository, which has to meet minimum standards for a depository. The fund or its investment adviser generally determines whether the depository complies with those requirements based on information provided by the fund's primary custodian (a bank that acts as global custodian). The depository custody arrangement also must meet certain conditions. The fund or its adviser must receive from the primary custodian (or its agent) an initial risk analysis of the depository arrangements, and the fund's contract with its primary custodian must state that the custodian will
The collection of information requirements in rule 17f-7 are intended to provide workable standards that protect funds from the risks of using foreign securities depositories while assigning appropriate responsibilities to the fund's primary custodian and investment adviser based on their capabilities. The requirement that the foreign securities depository meet specified minimum standards is intended to ensure that the depository is subject to basic safeguards deemed appropriate for all depositories. The requirement that the fund or its adviser must receive from the primary custodian (or its agent) an initial risk analysis of the depository arrangements, and that the fund's contract with its primary custodian must state that the custodian will monitor risks and promptly notify the fund or its adviser of material changes in risks, is intended to provide essential information about custody risks to the fund's investment adviser as necessary for it to approve the continued use of the depository. The requirement that the primary custodian agree to exercise reasonable care is intended to provide assurances that its services and the information it provides will meet an appropriate standard of care.
The staff estimates that each of approximately 1,445 investment advisers
In addition, based on public filings made with the Commission, we estimate that there are approximately 38 global custodians that are engaged to perform global custodial services to funds and thus subject to the provisions of rule 17f-7.
The estimate of average burden hours is made solely for the purposes of the Paperwork Reduction Act and is not derived from a comprehensive or even a representative survey or study of the costs of Commission rules and forms. Compliance with the collection of information requirements of the rule is necessary to obtain the benefit of relying on the rule's permission for funds to maintain their assets in foreign custodians. The information provided under rule 17f-7 will not be kept confidential. An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid OMB control number.
Written comments are invited on: (a) whether the proposed collection of information is necessary for the proper performance of the functions of the Commission, including whether the information shall have practical utility; (b) the accuracy of the Commission's estimate of the burden of the collection of information; (c) ways to enhance the quality, utility, and clarity of the information collected; and (d) ways to minimize the burden of the collection of information on respondents, including through the use of automated collection techniques or other forms of information technology. Consideration will be given to comments and suggestions submitted by February 13, 2023.
An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information under the PRA unless it displays a currently valid OMB control number.
Please direct your written comments to: David Bottom, Acting Director/Chief Information Officer, Securities and Exchange Commission, c/o John Pezzullo, 100 F Street NE, Washington, DC 20549 or send an email to:
Pursuant to Section 19(b)(1)
Pursuant to the provisions of Section 19(b)(1) under the Act,
The text of the proposed rule change is available at the Exchange's website at
In its filing with the Commission, the self-regulatory organization included statements concerning the purpose of and basis for the proposed rule change and discussed any comments it received on the proposed rule change. The text of these statement may be examined at the places specified in Item IV below. The self-regulatory organization has prepared summaries, set forth in Sections A, B, and C below, of the most significant aspects of such statements.
The COVID-19 pandemic has caused a host of operational disruptions to the securities industry and impacted IEX Members,
This proposed extension would provide further clarity to Members on regulatory requirements and account for time needed for many Members to carefully assess when and how to have their employees safely return to their offices considering vaccination coverage in the U.S. and transmission levels of the virus, including any emergent variants throughout the country.
The proposed amendment would provide that Members have the option to conduct remotely those inspections described in Supplementary Material .15 to IEX Rule 5.110 through the end of 2022. IEX is not proposing to amend the other conditions of the temporary relief in Supplementary Material .15 of IEX Rule 5.110. The current conditions of Supplementary Material .15 of IEX Rule 5.110 for Members that elect to conduct remote inspections would remain unchanged: such firms must still amend or supplement their written supervisory procedures for remote inspections, use remote inspections as part of an effective supervisory system, and maintain the required documentation. The additional period of time would also allow IEX to further monitor the effectiveness of remote inspections and their impacts—positive or negative—on Members' overall supervisory systems in the evolving workplace.
IEX continues to believe this temporary remote inspection option is a reasonable alternative to provide to Members to fulfill their IEX Rule 5.110 obligations during the ongoing pandemic, and is designed to achieve the investor protection objectives of the inspection requirements under these unique circumstances. Members should consider whether, under their particular operating conditions, reliance on remote inspections would be reasonable under the circumstances. For example, Members with offices that are open to the public or that are otherwise doing business as usual should consider whether some form of in-person inspections would be feasible and appropriately contribute to a supervisory system that is reasonably designed to achieve compliance with applicable securities laws and regulations, and with applicable IEX rules.
IEX has filed the proposed rule change for immediate effectiveness and has requested that the SEC waive the requirement that the proposed rule change not become operative for 30 days after the date of the filing, so IEX can implement the proposed rule change immediately.
IEX believes that the proposed rule change is consistent with the provisions of Section 6(b)
In recognition of the impact of COVID-19 on performing on-site inspections, the proposed rule change is intended to provide firms a temporary regulatory option to conduct inspections of offices and locations remotely for calendar year 2022 inspections. This proposed supplementary material does not relieve firms from meeting the core regulatory obligation to establish and maintain a system to supervise the activities of each associated person that is reasonably designed to achieve compliance with applicable securities laws and regulations, and with applicable IEX rules that directly serve investor protection. In a time when faced with unique challenges resulting from the COVID-19 pandemic, IEX believes that the proposed rule change provides sensibly tailored relief that will afford firms the ability to observe the recommendations of public health officials to provide for the health and safety of their personnel, while continuing to serve and promote the protection of investors and the public interest.
IEX does not believe that the proposed rule change will result in any burden on competition that is not necessary or appropriate in furtherance of the purposes of the Act. The proposed rule change is not designed to address any competitive issue but to align the Exchange's rules with those of FINRA, which will assist FINRA in its oversight work done pursuant to a regulatory services agreement with IEX. The proposed rule change will also provide for consistent application of the Exchange's supervision rules with those of FINRA, on which they are based. Consequently, the Exchange does not believe that the proposed change implicates competition at all.
Written comments on the proposed rule change were neither solicited nor received.
The Exchange has designated this rule filing as non-controversial under Section 19(b)(3)(A)
The Exchange believes that this filing is non-controversial because it raises no novel issues and is consistent with FINRA rules previously approved by or filed with the Commission. In particular, the purpose of the proposed rule change is to harmonize with and conform to FINRA rules. The Exchange believes that the proposal promotes the protection of investors as it will harmonize the Exchange's supervision rules with those of FINRA, which will simplify the oversight process conducted by FINRA pursuant to a regulatory services agreement with the Exchange. Moreover, the Exchange does not believe that the proposed rule change implicates competition at all because the proposed change aligns the Exchange's rules with those of FINRA, which will assist it in its oversight work done pursuant to such regulatory services agreement.
A proposed rule change filed under Rule 19b-4(f)(6)
IEX has indicated that extending the relief provided in SR-IEX-2021-09 would provide assurances to its member firms that they can plan their 2022 inspection program and conduct remote inspections for any inspections to be conducted through calendar year 2022. Importantly, extending the relief immediately upon filing and without a 30-day operative delay would allow IEX's member firms to continue performing their supervisory obligations, while addressing the ongoing impacts of the COVID-19 pandemic. Moreover, like SR-IEX-2021-09, the proposed extension would provide only temporary relief during the period in which IEX's member firms' operations remain impacted by COVID-19. Thus, the amended rules will revert back to their original state at the conclusion of the temporary relief period and, if applicable, any extension thereof. For these reasons, the Commission believes that waiver of the 30-day operative delay for this proposed rule change is consistent with the protection of investors and the public interest. Accordingly, the Commission hereby waives the 30-day operative delay and designates the proposed rule change operative upon filing.
At any time within 60 days of the filing of the proposed rule change, the Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is necessary or appropriate in the public interest, for the protection of investors, or otherwise in furtherance of the purposes of the Act. If the Commission takes such action, the Commission shall institute proceedings under Section 19(b)(2)(B)
Interested persons are invited to submit written data, views and arguments concerning the foregoing, including whether the proposed rule change is consistent with the Act. Comments may be submitted by any of the following methods:
• Use the Commission's internet comment form (
• Send an email to
• Send paper comments in triplicate to Secretary, Securities and Exchange Commission, 100 F Street NE, Washington, DC 20549-1090.
All submissions should refer to File Number SR-IEX-2022-12 and should be submitted on or before January 3,
For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
Effectiveness of Proposed Rule Change to amend the Fee Schedule of NYSE Chicago, Inc.
Pursuant to Section 19(b)(1)
The Exchange proposes to amend the Fee Schedule of NYSE Chicago, Inc. (the “Fee Schedule”) to adopt a new credit and increase an existing credit applicable to certain Exchange members. The Exchange proposes to implement the fee changes effective November 28, 2022. The proposed rule change is available on the Exchange's website at
In its filing with the Commission, the self-regulatory organization included statements concerning the purpose of, and basis for, the proposed rule change and discussed any comments it received on the proposed rule change. The text of those statements may be examined at the places specified in Item IV below. The Exchange has prepared summaries, set forth in sections A, B, and C below, of the most significant parts of such statements.
The Exchange proposes to amend the Fee Schedule to adopt a new credit and increase an existing credit applicable to certain Exchange members. Specifically, the Exchange proposes new Section F.1 to adopt a Participant
The Exchange operates in a highly competitive market. The Commission has repeatedly expressed its preference for competition over regulatory intervention in determining prices, products, and services in the securities markets. In Regulation National Market System (“NMS”), the Commission highlighted the importance of market forces in determining prices and Self-Regulatory Organizations (“SRO”) revenues and, also, recognized that current regulation of the market system “has been remarkably successful in promoting market competition in its broader forms that are most important to investors and listed companies.”
While Regulation NMS has enhanced competition, it has also fostered a “fragmented” market structure where trading in a single stock can occur across multiple trading centers. When multiple trading centers compete for order flow in the same stock, the Commission has recognized that “such competition can lead to the fragmentation of order flow in that stock.”
The Exchange believes that the ever-shifting market share among the exchanges from month to month demonstrates that market participants can move order flow, or discontinue or reduce use of certain categories of products. While it is not possible to know a firm's reason for shifting order flow, the Exchange believes that one such reason is because of fee changes at any of the registered exchanges or non-exchange venues to which a firm routes order flow.
Current Section E.3(a) assesses a fee of $0.0030 per share, capped at $75 per Clearing Side,
Current Section E.7 assesses a similar fee of $0.0030 per share, capped at $75 per Clearing Side, for an away execution in a security priced at $1.00 per share or more that is cleared through the Exchange's systems by an Institutional Broker and submitted to a Qualified Clearing Agency pursuant to Article 21, Rule 6(a).
The Exchange proposes to adopt new Section F.1 titled “Participant credits” pursuant to which the total monthly fees owed by a Clearing Participant to the Exchange under Section E.3(a) and Section E.7 would be reduced by the application of a credit equal to 5% of such fees. The Exchange believes that reducing Section E.3(a) and Section E.7 fees would increase trading on the Exchange.
Additionally, current Section F.2 provides for a Transaction Fee Credit and a Clearing Submission Fee Credit and generally states that the total monthly fees owed by an Exchange-registered Institutional Broker to the Exchange will be reduced (and Institutional Brokers will be paid for any unused credits) by the application of a Transaction Fee Credit and a Clearing Submission Fee Credit. Specifically, a Clearing Broker
The Exchange proposes to amend current Section F.2 by increasing both the Transaction Fee Credit and the Clearing Submission Fee Credit from 5% to 8% each. As with the Participant credit proposed herein, the Exchange believes that increasing the Transaction Fee Credit and the Clearing Submission Fee Credit, which would result in reduced fees, would increase trading and post-trade activity on the Exchange.
The Exchange believes that the proposed rule change is consistent with Section 6(b) of the Act,
As discussed above, the Exchange operates in a highly fragmented and competitive market. The Commission has repeatedly expressed its preference for competition over regulatory intervention in determining prices, products, and services in the securities markets. Specifically, in Regulation NMS, the Commission highlighted the importance of market forces in determining prices and SRO revenues and, also, recognized that current regulation of the market system “has been remarkably successful in promoting market competition in its broader forms that are most important to investors and listed companies.”
The Exchange believes that the ever-shifting market share among the exchanges from month to month demonstrates that market participants can shift order flow, or discontinue or reduce use of certain categories of products, in response to fee changes. With respect to non-marketable orders that provide liquidity on an Exchange, Participants can choose from any one of the 16 currently operating registered exchanges to route such order flow. Accordingly, competitive forces reasonably constrain exchange transaction fees that relate to orders that would provide displayed liquidity on an exchange. Stated otherwise, changes to exchange transaction fees can have a direct effect on the ability of an exchange to compete for order flow.
The Exchange believes that the proposed new Participant credit is reasonable because it is designed to encourage increased trading activity on the Exchange. The Exchange believes the proposed rule change to introduce the Participant credit, which would result in lower fees paid by Clearing Participants for the execution of single-
The Exchange believes that the proposal represents a reasonable effort to promote enhanced order execution opportunities as well as promote post-trade clearing submissions by Exchange members. The Exchange notes that market participants are free to shift their order flow to competing venues if they believe other markets offer more favorable fees and credits.
On the backdrop of the competitive environment in which the Exchange currently operates, the proposed rule change is a reasonable attempt to attract additional order flow and increase liquidity on the Exchange and improve the Exchange's market share relative to its competitors.
The Exchange believes that the proposed new Participant credit and the proposed increase to the Transaction Fee Credit and the Clearing Submission Fee Credit equitably allocates its fees and credits among its market participants. The Exchange believes the proposed new Participant credit is equitable because it is open to all similarly situated Clearing Participants on an equal basis and provides a per share credit that is reasonably related to the value of an exchange's market quality associated with higher volumes. The Exchange believes it is equitable to provide Clearing Participants with the proposed credit and provide Clearing Brokers with increased credits, both of which would result in lower fees, because the credits would serve to incentivize each such member to conduct more of its trading and clearing activity on the Exchange.
The Exchange believes that the proposed new Participant credit could encourage the submission of a greater number of orders to the Exchange, thus enhancing order execution opportunities for all market participants trading on the Exchange. All market participants would benefit from the greater amounts of liquidity that would be present on the Exchange, which would provide greater execution opportunities. The Exchange also believes that the proposed increase to the Transaction Fee Credit and the Clearing Submission Fee Credit could encourage Institutional Brokers to conduct more of their trading and post-trade activity on the Exchange.
The Exchange believes that the proposed new Participant credit and increasing the level of the Transaction Fee Credit and the Clearing Submission Fee Credit is not unfairly discriminatory. The Exchange believes that the proposal does not permit unfair discrimination because the proposed new credit would be applied to all similarly situated Clearing Participants while the existing Transaction Fee Credit and the Clearing Submission Fee Credit would be similarly applied to all Clearing Brokers on an equal basis. Accordingly, no Exchange member already operating on the Exchange would be disadvantaged by the proposed allocation of fees and credits under the proposal. The Exchange further believes that the proposed fee change would not permit unfair discrimination among Clearing Participants or among Clearing Brokers because the credits would be available equally to them. As described above, in today's competitive marketplace, market participants have a choice of where to direct their order flow or which market to transact on. The Exchange believes this proposal would benefit a number of members by lowering their current fees, regardless of whether or not they increase their trading and clearing activity on the Exchange.
In the prevailing competitive environment, Exchange members are free to disfavor the Exchange's pricing if they believe that alternatives offer them better value. Accordingly, no Exchange member already operating on the Exchange would be disadvantaged by the proposed allocation of the Exchange's fees and credits.
Finally, the submission of orders to the Exchange is optional for Exchange members in that they could choose whether to submit orders to the Exchange and, if they do, the extent of its activity in this regard. The Exchange believes that it is subject to significant competitive forces, as described below in the Exchange's statement regarding the burden on competition.
For the foregoing reasons, the Exchange believes that the proposal is consistent with the Act.
In accordance with Section 6(b)(8) of the Act,
No written comments were solicited or received with respect to the proposed rule change.
The foregoing rule change has become effective upon filing pursuant to Section 19(b)(3)(A)
Interested persons are invited to submit written data, views and arguments concerning the foregoing, including whether the proposed rule change is consistent with the Act. Comments may be submitted by any of the following methods:
• Use the Commission's internet comment form (
• Send an email to
• Send paper comments in triplicate to Secretary, Securities and Exchange Commission, 100 F Street NE, Washington, DC 20549-1090.
For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
4:00 p.m. on Friday, December 9, 2022.
The meeting will be held via remote means and/or at the Commission's headquarters, 100 F Street NE, Washington, DC 20549.
This meeting will be closed to the public.
Commissioners, Counsel to the Commissioners, the Secretary to the Commission, and recording secretaries will attend the closed meeting. Certain staff members who have an interest in the matters also may be present.
In the event that the time, date, or location of this meeting changes, an announcement of the change, along with the new time, date, and/or place of the meeting will be posted on the Commission's website at
The General Counsel of the Commission, or his designee, has certified that, in his opinion, one or more of the exemptions set forth in 5 U.S.C. 552b(c)(3), (5), (6), (7), (8), 9(B) and (10) and 17 CFR 200.402(a)(3), (a)(5), (a)(6), (a)(7), (a)(8), (a)(9)(ii) and (a)(10), permit consideration of the scheduled matters at the closed meeting.
The subject matter of the closed meeting will consist of the following topics:
Institution and settlement of injunctive actions;
Institution and settlement of administrative proceedings;
Resolution of litigation claims; and
Other matters relating to examinations and enforcement proceedings.
At times, changes in Commission priorities require alterations in the scheduling of meeting agenda items that may consist of adjudicatory, examination, litigation, or regulatory matters.
For further information; please contact Vanessa A. Countryman from the Office of the Secretary at (202) 551-5400.
5 U.S.C. 552b.
Notice of request for public comment and submission to OMB of proposed collection of information.
The Department of State has submitted the information collection described below to the Office of
Submit comments up to 30 days after the date of publication in the
Written comments and recommendations for the proposed information collection should be sent within 30 days of publication of this notice to
Direct requests for additional information regarding the collection listed in this notice, including requests for copies of the proposed collection instrument, and supporting documents, to Hilary Schroeder, who may be reached at (202) 890-9798 or at
•
•
•
•
•
•
•
•
•
•
•
•
We are soliciting public comments to permit the Department to:
• Evaluate whether the proposed information collection is necessary for the proper functions of the Department.
• Evaluate the accuracy of our estimate of the time and cost burden for this proposed collection, including the validity of the methodology and assumptions used.
• Enhance the quality, utility, and clarity of the information to be collected.
• Minimize the reporting burden on those who are to respond, including the use of automated collection techniques or other forms of information technology.
Please note that comments submitted in response to this Notice are public record. Before including any detailed personal information, you should be aware that your comments as submitted, including your personal information, will be available for public review.
This collection includes DOSAR provisions and clauses implemented via solicitations and contracts to ensure offerors meet qualifications and awardees meet specific post-award requirements.
Information is collected electronically.
Federal Aviation Administration (FAA), DOT.
Notice and request for comments.
In accordance with the Paperwork Reduction Act of 1995, the FAA invites public comments about their intention to request Office of Management and Budget (OMB) approval to renew an information collection. The
Written comments should be submitted by December 1, 2022.
Written comments and recommendations for the proposed information collection should be sent within 30 days of publication of this notice to
For technical questions concerning this action, contact Mr. Paul Von Hoene, Aviation Safety, Aviation Safety Inspector (AC/OPS) at
The collection involves planned routes of flight and aircraft avionics equipment. The information that is collected will be used to predict whether an aircraft flying the proposed route of flight will have sufficient position accuracy and integrity for the following:
In addition, the website will allow operators to request authorization to operate in ADS-B-Out rule airspace with aircraft that do not fully meet the ADS-B Out requirements via:
Under 14 CFR 91.103, pilots must use all available information in planning
The RAIM SAPT is intended mainly for pilots, dispatchers, and commercial operators using TSO-C129 equipment to check their predicted navigation horizontal protection level (HPL). It incorporates TSO-C129 GPS RAIM predictions to check the availability of GPS RAIM satisfying the RNAV requirements of AC 90-100A Change 2, Paragraph 10(5)).
The ADS-B SAPT is provided to help operators comply with 14 CFR 91.225 and 91.227 by predicting whether operators will meet regulatory requirements, and to advise holders of FAA Exemption 12555 whether back-up surveillance will be available for any waypoints where installed aircraft avionics are not predicted to meet the requirements of 14 CFR 91.227(c)(1)(i) and (iii).
Information collected via ADS-B SAPT is comparable to that provided by pilots when they file flight plans, with some additional information about aircraft position source TSO and related capabilities. The ADS-B SAPT prediction is based on the ability of the aircraft's position source (
The ADS-B SAPT predicts whether GPS position information will be sufficient throughout the flight to meet the performance requirements of 14 CFR 91.227(c)(1)(i) and (iii). If a waypoint is in rule airspace and the aircraft's position source is not predicted to meet the performance requirements of 14 CFR 91.227, the ADS-B SAPT checks for the availability of back-up surveillance at that waypoint.
Operators of aircraft equipped with TSO-C129 (SA-On) GPS receivers must run a pre-flight prediction. The operator may use their own prediction tool. Although Exemption 12555 does not require operators with SA-On to use the ADS-B SAPT for pre-flight availability prediction, if the operator does use their own tool and receives an indication that performance will fall below rule requirements, the operator cannot obtain back-up surveillance information from that tool and must either replan the flight or use ADS-B SAPT to determine whether back-up surveillance is available along the planned route of flight per Exemption 12555.
ADAPT is mandatory for operators desiring to apply for an ATC authorization, per 14 CFR 91.225(g), to fly in ADS-B Out rule airspace using aircraft with avionics that do not meet the ADS-B equipage requirements. ADAPT allows operators to create an air traffic authorization request to operate in ADS-B Out rule airspace when either (1) the aircraft is without ADS-B equipment; (2) that equipment is inoperative; or (3) their avionics are not expected to meet the ADS-B performance requirements as identified in 14 CFR 91.227(c)(1)(i) and (iii). Operators who wish to submit an ADAPT request must complete the ADS-B SAPT analysis using information entered into the flight information entry form before filing the ADAPT request.
RAIM SAPT and ADS-B SAPT can be automated as part of the dispatch process by operators or flight service providers, thus eliminating manual data-entry.
RAIM SAPT—Insignificant, as all transactions are automated in flight planning systems.
ADS-B SAPT—5 minutes or less for transactions input via the flight plan form, including 1 minute or less to note the transaction id.
ADAPT—7 minutes or less (includes up to 2 minutes to check FAA email response).
RAIM SAPT—Insignificant additional burden.
ADS-B SAPT—Approximately 2159 hours.
ADAPT—Approximately 590 hours.
National Highway Traffic Safety Administration (NHTSA), Department of Transportation (DOT).
Denial of petition.
Mercedes-Benz AG (MB AG) and Mercedes-Benz USA, LLC (MBUSA) (collectively, “Mercedes-Benz”), formerly known as Daimler AG has determined that certain model year (MY) 2019 Mercedes-Benz AMG GT motor vehicles do not fully comply with Federal Motor Vehicle Safety Standard (FMVSS) No. 201,
Karen Nuschler, Office of Vehicle Safety Compliance, NHTSA, telephone (202) 366-5829.
Mercedes-Benz has determined that certain MY 2019 Mercedes-Benz AMG GT motor vehicles do not fully comply with paragraph S5.3.1(c) of FMVSS No. 201,
Mercedes-Benz filed a noncompliance report dated October 18, 2019, pursuant to 49 CFR part 573,
Notice of receipt of Mercedes-Benz's petition was published, with a 30-day public comment period, on May 21, 2020, in the
Approximately 12 MY 2019 Mercedes-Benz GT63, GT53, and GT63S AMG motor vehicles, manufactured between August 29, 2017, and March 4, 2019, are potentially involved.
Mercedes-Benz explains that an interior compartment door assembly in the subject vehicles does not meet the requirements of paragraph S5.3.1(c) of FMVSS No. 201. Specifically, the front center console storage compartment sliding lid may open briefly in certain types of forward crashes.
Paragraphs S5.3, S5.3.1(a) and S5.3.1(c) of FMVSS No. 201, include the requirements relevant to this petition. Each interior compartment door assembly located in an instrument panel, console assembly, seat back, or side panel adjacent to a designated seating position shall remain closed when tested in accordance with either S5.3.1(a) and S5.3.1(b) or S5.3.1(a) and S5.3.1(c). S5.3.1(a) subjects the interior compartment door latch system to an inertia load of 10g in a horizontal transverse direction and an inertia load of 10g in a vertical direction in accordance with the procedure described in section 5 of SAE Recommended Practice J839b (1965) (incorporated by reference, see § 571.5), or an approved equivalent. Further, S5.3.1(c) subjects the interior compartment door latch system to a horizontal inertia load of 30g in a longitudinal direction in accordance with the procedure described in section 5 of SAE Recommended Practice J839b (1965) (incorporated by reference, see § 571.5), or an approved equivalent.
The following views and arguments presented in this section, “V. Summary of Mercedes-Benz's Petition,” are the views and arguments provided by Mercedes-Benz. They do not reflect the views of the Agency. Mercedes-Benz describes the subject noncompliance and contends that the noncompliance is inconsequential as it relates to motor vehicle safety.
1. At issue in this petition are a total of 12 MY 2019 Mercedes-Benz AMG GT vehicles. MB AG previously determined that the interior compartment door located within the vehicle's center console does not fully meet the requirement in FMVSS No. 201,
2. Mercedes-Benz states that due to the location and geometry of the compartment door, there is no risk of injury even if it were to open in a frontal crash. Mercedes-Benz states that the door is located in the center console, below the invehicle display, and does not present an opportunity to strike vehicle occupants when opened. Further, because the design of the door slides forward and into the center console when it opens, there is similarly no risk of injury from the performance of the door. Finally, although the purpose and objective of the standard is to protect against injury from hard and sharp surfaces in the event of a crash, because the compartment door will automatically close within an extremely short period of time (a matter of milliseconds) from opening and because the door may only open during a frontal crash in which case any objects within the compartment would only move in a forward direction and not rearward into the occupant compartment, there is no risk of harm from objects inside the compartment escaping into the occupant space.
3. The Performance of the Compartment Door Does Not Create an Increased Safety Risk: Mercedes-Benz cites the provisions of the Safety Act, 49 U.S.C. 30118(d) and 30120(h) and the basis upon which NHTSA evaluates an inconsequentiality petition “whether an occupant who is affected by the noncompliance is likely to be exposed to a
As described below, the issue here does not impact the operational safety of the vehicle and will not create an enhanced risk to vehicle occupants because, in the limited, frontal crash scenario in which the door could potentially open, neither the door itself nor any objects within the compartment could cause injury to vehicle occupants.
4. Description of the Compartment Door: Mercedes-Benz explains that the interior compartment door at issue in this petition is a storage compartment used in vehicles with the Wireless Media Interface (WMI) package. The WMI feature allows users to wirelessly charge cell phones within the compartment and the compartment can also be used to store small objects like coins and accessories. The compartment is located within the center console between the driver and front passenger's seat and the storage portion of the compartment is approximately 15 cm/6 inches long and 13 cm/5 inches deep.
In normal use, the door remains shut until an occupant pushes the door forward. The door moves forward in an upward direction, towards the front of the vehicle. When reaching the top, the door is enclosed within the housing of the compartment itself and, with an additional push is snapped into place to remain open. Once it is snapped into place, in order to close the door an
5. It is Not Possible for the Compartment Door to Strike Occupants: Mercedes-Benz states that the performance of the interior compartment door does not present any of the safety risks contemplated by FMVSS No. 201 because there is no risk of vehicle occupants coming into contact with or striking the compartment door. When originally promulgated, the interior compartment door provisions in FMVSS No. 201 were focused on preventing injuries that could occur from hard interior doors, such as the glove compartment door, striking an occupant.
The location, geometry, and operation of the compartment door prevent it from causing or contributing to an injury in the event of a crash. The door is located in the bottom of the center console, in the area between the driver and front passenger seats. Mercedes-Benz states that the door is installed in a location where it could not strike a vehicle occupant should it open in a crash. The door, moreover, does not have any sharp edges and is not comprised of a hard, metal surface.
Further, Mercedes-Benz states that because of the manner in which the door opens, there is no opportunity for the door to strike a vehicle occupant. The door covering slides forwards and into the housing of the compartment itself, it does not extend outwards into the passenger compartment which is the concern that the standard is intended to address. In typical use, the operator slides the door covering away towards the front of the vehicle, away from the occupant compartment and into the center console where it becomes fully enclosed within the housing. By contrast, glove box doors and other interior compartment doors on hinges that open outwards and into the occupant compartment are the traditional types of doors that FMVSS No. 201 was designed to address because the door's surface could come into contact with a vehicle occupant if it opened in a crash. Mercedes-Benz contends that this same risk does not exist with the door covering in the AMG vehicles based on its geometry and design.
Additionally, the compartment door will automatically close after opening if it has not been snapped into place to stay open. In the event of a frontal crash force that is severe enough to cause the door to open, the door would open for an extremely short period of time, a matter of milliseconds, and then would automatically pull back into place and the door will close again. Because of the design and operation of the door, it remains open for a matter of milliseconds seconds after which it will retreat back into its fully closed position.
6. There is No Risk of Injury to Occupants from Objects Escaping the Compartment: Mercedes-Benz states there is no potential for items inside the storage compartment to escape and injure vehicle occupants. Although the scope of the standard has always been focused on risks of injury presented by the hard surface of vehicle doors opening in a crash, Mercedes-Benz claims that there is similarly no enhanced risk to safety from items escaping the compartment and causing injury. The compartment door has the potential to open only in specific situations, a frontal crash with loads exceeding 24 g of force. Mercedes-Benz states that the compartment door operates within the requirements of the standard at all other times.
7. Mercedes-Benz states that the above described discrepancy does not create a safety risk and that it is not aware of any warranty claims, field reports, customer complaints, legal claims, or injuries related to this noncompliance. Even if the compartment door was to open in the event of a severe crash, there is no increased risk of injury due to the location of the door covering itself, its operation and design that allows it to retract into the console housing and the fact that it will automatically close after an extremely short period of time. Mercedes-Benz states that vehicle occupants are not at risk of coming into contact with the door itself (when opened or closed) and there is no risk of objects stored inside the compartment from escaping into the occupant space.
Mercedes-Benz concludes that the subject noncompliance is inconsequential as it relates to motor vehicle safety and that its petition to be exempted from providing notification of the noncompliance, as required by 49 U.S.C. 30118, and a remedy for the noncompliance, as required by 49 U.S.C. 30120, should be granted.
FMVSS No. 201 establishes performance requirements designed to reduce the risk of injury in the event an occupant strikes the interior of a vehicle during a crash. S5.3 of FMVSS No. 201 specifies that doors to interior compartments must remain latched when subjected to certain forces that might be experienced in a crash.
NHTSA notes first that a petitioner seeking relief from the notification and remedy requirements must, when requesting the Agency to grant a petition for inconsequential noncompliance, meet the burden of persuasion to obtain relief. Further, the burden of establishing the inconsequentiality of a failure to comply with a
An important issue to consider in determining inconsequentiality based upon NHTSA's prior decisions on noncompliance issues was the safety risk to individuals who experience the type of event against which the recall would otherwise protect.
Arguments that only a small number of vehicles or items of motor vehicle equipment are affected have also not justified granting an inconsequentiality petition.
Mercedes-Benz states that the door is located in the center console, below the in-vehicle display, and does not present an opportunity to strike vehicle occupants when opened. Further, Mercedes-Benz states the design of the door slides forward and into the center console when it opens and presents little or no opportunity for any contact between the vehicle's occupants and the door. Finally, although the purpose and objective of the standard are to protect against injury from hard and sharp surfaces in the event of a crash, Mercedes-Benz states the compartment door will automatically close within 250 ms.
Without presenting any test data or other information supporting this thesis, Mercedes-Benz argues that in a frontal crash there is the possibility that the center console door will open for a matter of milliseconds then automatically close. Specifically, Mercedes-Benz represents that there is “no risk of injury to occupants from objects escaping the compartment . . . only opening in crash loads exceeding 24 g of force . . . and would open and completely close within approximately 250 ms.” NHTSA notes that frontal crash events, such as seen in NHTSA FMVSS No. 208,
NHTSA finds that in the instant case, the mere assertion that the center console door will open for up to 250 ms and then automatically close is not sufficiently persuasive to justify granting the relief Mercedes-Benz seeks. In addition, the Agency has never made a distinction between sliding interior compartment doors and other, pivoting or hinged doors that project outward when opened. Mercedes-Benz asserts that an open sliding compartment door does not present a potential for occupant injury because an open sliding compartment door does not project outward into the interior of the vehicle. S5.3 of FMVSS No. 201 requires that doors in the console or a side panel remain closed regardless of the method by which a manufacturer chooses to open or close them. The concern that an open door could cause occupant injury is not limited to a protrusion created by an open door. Rather, the concern addressed by the requirement is that a sharp or rigid surface does not expose an occupant to undue risk of injury. In other words, we do not consider the risk posed by the sharp edges of the door itself to be the only risk addressed by FMVSS No. 201. Surfaces that should be masked by a door may themselves pose risks to occupants during a crash.
Finally, Mercedes-Benz represents that it is “not aware of any warranty claims, field reports, customer complaints, legal claims, or injuries related to this noncompliance.” As noted above, NHTSA does not consider the absence of complaints or injuries to show that the issue is inconsequential to safety.
NHTSA finds that Mercedes-Benz has not met its burden of persuasion that the FMVSS No. 201 noncompliance is inconsequential as it relates to motor vehicle safety. Accordingly, the petition is hereby denied and Mercedes-Benz is not exempt from the obligation to provide notification of, and remedy for, the subject noncompliance in the affected vehicles under 49 U.S.C. 30018 and 30120.
Internal Revenue Service (IRS), Treasury.
Notice of Meeting.
The Electronic Tax Administration Advisory Committee (ETAAC) will hold a public meeting via telephone conference line on Wednesday, January 11, 2023.
Mr. Alec Johnston, Office of National Public Liaison, at (202) 317-4299, or send an email to
Notice is hereby given pursuant to section
Department of Veterans Affairs.
Notice of availability.
The Department of Veterans Affairs (VA) announces the availability of the Record of Decision (ROD) for the Final Programmatic Environmental Impact Statement (PEIS) for VA's Housing Loan Program (HLP). Notice of the Final PEIS was published by the U.S. Environmental Protection Agency (EPA) in the
The ROD is available at the VA website
Erin Byrum, Lead Management Analyst, Loan Guaranty Service, Veterans Benefit Administration, Department of Veterans Affairs, 810 Vermont Avenue NW, Washington, DC 20420, at
The Final PEIS was developed pursuant to the National Environmental Policy Act (NEPA) of 1969, as amended (42 U.S.C. 4321,
The Final PEIS assessed the potential physical, environmental, cultural, socioeconomic and cumulative effects of the HLP and will be used to assist and inform agency planning and decision-making. The HLP assists hundreds of thousands of Veterans each year across the United States and its Territories. This PEIS process has ensured VA appropriately considered the potential effects of the HLP, a major Federal action, on the quality of the human environment, as required by 40 CFR 1500.1.
Denis McDonough, Secretary of Veterans Affairs, approved this document on December 7, 2022, and authorized the undersigned to sign and submit the document to the Office of the Federal Register for publication electronically as an official document of the Department of Veterans Affairs.
Veterans Health Administration, Department of Veterans Affairs.
Notice.
In compliance with the Paperwork Reduction Act (PRA) of 1995, this notice announces that the Veterans Health Administration, Department of Veterans Affairs, will submit the collection of information abstracted below to the Office of Management and Budget (OMB) for review and comment. The PRA submission describes the nature of the information collection and its expected cost and burden and it includes the actual data collection instrument.
Written comments and recommendations for the proposed information collection should be sent within 30 days of publication of this notice to
Maribel Aponte, Office of Enterprise and Integration, Data Governance Analytics (008), 1717 H Street NW, Washington, DC 20006, (202) 266-4688 or email
An agency may not conduct or sponsor, and a person is not required to
By direction of the Secretary.
Centers for Medicare & Medicaid Services (CMS), Department of Health and Human Services (HHS).
Proposed rule.
This proposed rule would place 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 proposed rule would also add 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.
To be assured consideration, comments must be received at one of the addresses provided below, no later than 5 p.m. on March 13, 2023.
In commenting, please refer to file code CMS-0057-P.
Comments, including mass comment submissions, must be submitted in one of the following three ways (please choose only one of the ways listed):
1.
2.
Please allow sufficient time for mailed comments to be received before the close of the comment period.
3.
For information on viewing public comments, see the beginning of the
Alexandra Mugge, (410) 786-4457, for general questions related to any of the policies in this proposed rule, or questions related to CMS interoperability initiatives.
Lorraine Doo, (443) 615-1309, for issues related to the prior authorization process policies, or the Prior Authorization Requirements, Documentation, and Decision (PARDD) Application Programming Interface (API).
Shanna Hartman, (410) 786-0092, for issues related to the Payer-to-Payer API, the Electronic Prior Authorization measure for the MIPS Promoting Interoperability performance category and Medicare Promoting Interoperability Program, or any of the API standards and implementation guides (IGs) included in this proposed rule.
David Koppel, (303) 844-2883, for issues related to the Patient Access API policies, or patient privacy.
Scott Weinberg, (410) 786-6017, for issues related to the Provider Access API policies, or the Requests for Information.
Amy Gentile, (410) 786-3499, for issues related to Medicaid managed care.
Kirsten Jensen, (410) 786-8146, for issues related to Medicaid FFS.
Joshua Bougie, (410) 786-8117, for issues related to CHIP.
Natalie Albright, (410) 786-1671, for issues related to MA organizations.
Ariel Novick, (301) 492-4309, for issues related to QHPs.
Elizabeth Holland, (410) 786-1309, for issues related to MIPS and the Medicare Promoting Interoperability Program.
Russell Hendel, (410) 786-0329, for issues related to the Collection of Information and Regulatory Impact Analysis.
In the May 1, 2020,
On December 18, 2020, we published a proposed rule (85 FR 82586) (hereinafter referred to as the “December 2020 CMS Interoperability proposed rule”) in which we proposed new requirements for state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to improve the electronic exchange of healthcare data and streamline processes related to prior authorization, while continuing CMS' drive toward interoperability and reducing burden in the healthcare market. In addition, on behalf of the Department of Health and Human Services (HHS), the Office of the National Coordinator for Health Information Technology (ONC) proposed the adoption of certain specified implementation guides (IGs) needed to support the proposed Application Programming Interface (API) policies in that proposed rule.
We received approximately 251 individual comments on the December 2020 CMS Interoperability proposed rule by the close of the comment period on January 4, 2021. While commenters largely supported the intent of the proposals and the proposals themselves, many noted and emphasized that MA organizations were not included among the impacted payers. The National Association of Medicaid Directors and state Medicaid programs expressed concerns about the implementation timeframes, states' constraints to secure the funding necessary to implement the requirements of the rule in a timely manner, and states' ability to recruit staff with necessary technical expertise. Commenters also raised concerns that the relatively short comment period inhibited more thorough analyses of the proposals and, for membership organizations, the ability to receive input from and gain consensus among their members. The December 2020 CMS Interoperability proposed rule will not be finalized; we considered whether to issue a final rule based on that proposed rule, but considering the concerns raised by the commenters, we have opted not to do so. Instead, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates the feedback we received from stakeholders on that proposed rule. This approach will allow us to incorporate the feedback we have already received and provide additional time for public comment.
Some of the changes we have incorporated in this proposed rule were influenced by the comments we received on the December 2020 CMS Interoperability proposed rule. For example, unlike in that proposed rule, we now propose to require impacted payers to use those health information technology (IT) standards at 45 CFR 170.215 that are applicable to each set of API requirements proposed in this rule, including the HL7 Fast Healthcare Interoperability Resources (FHIR) standard, the HL7 FHIR US Core Implementation Guide, and the HL7 SMART Application Launch Framework Implementation Guide. Also, in this proposed rule, we include MA organizations as impacted payers and propose that the policies included herein would have a longer implementation timeline.
Most of the implementation dates for the proposals included in this proposed rule would begin in 2026, including those for the API proposals, prior authorization decision timeframes for certain impacted payers, and certain reporting proposals. We believe 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. In addition to the proposed three-year implementation timeframe, we propose to give state Medicaid and CHIP FFS programs an opportunity to seek an extension of proposed implementation deadlines, or an exemption from meeting certain proposed requirements, in certain circumstances. Additionally, we include a proposal to provide an exceptions process for issuers of QHPs on the FFEs. We believe the three-year timeframe would offer sufficient time for these impacted payers to evaluate their qualifications to participate in the API proposals in this proposed rule and to prepare the necessary documentation to request an extension, exemption, or exception.
We are proposing some clarifications to existing Medicaid beneficiary notice and fair hearing regulations which apply to Medicaid prior authorization decisions. Because these are clarifications and improvements to existing regulations, these policies would become effective upon the effective date of a final rule if these proposals are finalized as proposed. We are also proposing terminology changes in section II.A.2.e related to the Patient Access API that would take effect with the effective date of the final rule, should these proposals be finalized as proposed.
We are proposing a new Electronic Prior Authorization measure for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS, which is in direct response to comments we received on the December 2020 CMS Interoperability proposed rule.
We are re-issuing two requests for information (RFIs) that were included in the December 2020 CMS Interoperability proposed rule. We are also issuing three new RFIs: one to solicit information related to opportunities for improving the electronic exchange of medical documentation between providers to support prior authorization programs for Medicare FFS, a second to gather public feedback regarding data standardization and use of prior authorization to improve maternal health care, and a third to solicit comment regarding enabling exchange under the Trusted Exchange Framework and Common Agreement (TEFCA).
With this new proposed rule, we are taking an active approach to move certain participants in the healthcare market toward interoperability by proposing policies for the MA program, Medicaid, CHIP, and QHP issuers on the FFEs, as well as eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS.
Our proposals emphasize improving health information exchange and facilitating appropriate and necessary
For purposes of this proposed rule, references to QHP issuers on the FFEs exclude issuers offering only stand-alone dental plans (SADPs). Likewise, we are also excluding QHP issuers offering only QHPs in the Federally-facilitated Small Business Health Options Program Exchanges (FF-SHOPs) from the proposed provisions of this rule. We believe that the proposed standards would be overly burdensome for both SADP and SHOP issuers. Requiring issuers offering only SADPs and QHPs in the FF-SHOPs, which have relatively lower enrollment and premium intake compared to individual market QHPs, to comply with the proposals in this rule could result in those issuers no longer participating in the FFEs, which would not be in the best interest of the enrollees. The categorical exclusion of these issuers is consistent with CMS' approach to some other QHP requirements. We also propose offering an exceptions process for QHP issuers on the FFEs for the API requirements proposed in this rule, that would be conditioned upon approval of a narrative justification that meets CMS requirements. The proposed exceptions processes could apply to small issuers, financially vulnerable issuers, or new entrants to the FFEs that demonstrate that deploying standards-based API technology consistent with the proposed policies would pose a significant barrier to the issuers' ability to provide coverage or service to patients and that not certifying the issuers QHP or QHPs would result in patients having few or no plan options in certain areas. This approach is consistent with the exceptions process finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule. Were we to apply the proposed standards to such issuers, we believe it could result in those issuers no longer participating in the FFEs, which would not be in the best interest of enrollees. We note that, in this proposed rule, FFEs include FFEs in states that perform plan management functions. State-based Exchanges on the Federal Platform (SBE-FPs) are not FFEs, even though patients in those states enroll in coverage through
Throughout this proposed rule, we use terms such as “patient,” “consumer,” “beneficiary,” “enrollee,” and “individual.” Every reader of this proposed rule is a patient and has received, or will receive, medical care at some point in their life. In this proposed rule, we use the term “patient” as an inclusive term. We understand that, historically, we have referred in our regulations to patients using the other terms previously noted. However, for the proposals herein, we will use additional, specific terms applicable to individuals covered under the healthcare programs that we administer and regulate. We also note that when we discuss patients, the term includes, where applicable, a patient's personal representative. For example, a patient or their personal representative may consent to certain types of information exchange under our proposals. But when we refer to a patient's medical needs or health records, we are not including the medical needs or health records of the patient's personal representative. Per the Privacy, Security, and Breach Notification Rules (HIPAA Rules)
We also use terms such as “payer,” “plan,” and “issuer” in this proposed rule. Certain portions of this proposed rule are applicable to MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans (managed care organizations (MCOs), prepaid inpatient health plans (PIHPs), and prepaid ambulatory health plans (PAHPs)), CHIP managed care entities (MCOs, PIHPs, and PAHPs), and QHP issuers on the FFEs. Where certain proposed provisions may not be applicable to specific plan or provider types, we have identified them separately from the aforementioned categories. We use the term “payer” in the preamble of this proposed rule as an inclusive term for all these programs and, in the case of plans, plan types, but we also use specific terms as applicable in various sections of this proposed rule. We are proposing at 42 CFR 457.700(c) that states that have a Medicaid expansion CHIP (a program under which a state receives Federal funding to expand Medicaid eligibility to optional targeted low-income children that meets the requirements of section 2103 of the Social Security Act), the proposals in this rule for Medicaid would apply to those programs rather than our proposals for a separate CHIP. Functionally, our proposals are the same; however, for clarity, we are making explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 would apply to those programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732.
We use the term “items and services” when discussing prior authorization in this proposed rule, and note that, unless otherwise stated, the proposals for prior authorization APIs and processes do not apply to drugs of any type, meaning any drugs that could be covered by the impacted payers in this proposed rule (for example, this would include outpatient drugs, drugs that may be prescribed, those that may be administered by a physician, or that may be administered in a pharmacy or hospital), because the processes and standards for prior authorization applicable to drugs differ from the other “items and services” for which we propose regulation. In the CMS Interoperability and Patient Access final rule, we finalized policies that would require payers to send claims data
Additionally, we use the terms “provider” and “supplier” as inclusive terms composed of individuals, organizations, and institutions that provide health services, such as clinicians (that is, physicians and other practitioners), hospitals, skilled nursing facilities, home health agencies, hospice settings, laboratories, suppliers of durable medical equipment, prosthetics, orthotics, and supplies (DMEPOS), community-based organizations, as appropriate in the context used. When specifically discussing policies related to the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of MIPS, we refer to MIPS eligible clinicians, eligible hospitals, and CAHs.
Throughout this proposed rule we make several API-related proposals in which we refer to the functionality as a singular API, or API gateway, though we acknowledge that this functionality may be made up of one or multiple APIs. For example, while we refer to the Patient Access API (discussed in section II.A. of this proposed rule) as a single API for the purpose of describing the functionality, the same functionality may be achieved with one or multiple APIs, depending on the implementation approach chosen by the applicable payer.
An API is a set of commands, functions, protocols, or tools published by one software developer (“A”) that enables other software developers to create programs (applications or “apps”) that can interact with A's software without needing to know the internal workings of A's software, while maintaining data security and patient privacy, if properly implemented. This is how API technology enables the seamless user experiences associated with applications, which are familiar in other aspects of patients' daily lives, such as travel and personal finance. Standardized, secure, transparent, and pro-competitive API technology can enable similar benefits for patients of healthcare services.
Health Level 7 (HL7®) is the standards development organization which develops the Fast Healthcare for Interoperability Resources (FHIR®) standard and IGs referenced throughout this proposed rule. HL7 requires the registered trademark with the first use of its name in a document, for which policies are available on its website at
Finally, we note that throughout this proposed rule we discuss the APIs in relation to the proposed programmatic requirements to share data between payers, between payers and providers, and between payers and patients under specific rules. However, these APIs could be used for a multitude of transactions, aside from those currently described by section 1173(a)(1) of the Social Security Act, beyond those proposed in this rule. For instance, a patient could request data outside the scope of this proposed rule, or program integrity entities could request data from payers or providers (such as under the Inspector General Act of 1978). Nothing in this proposed rule would prevent the requested data from being shared via the APIs discussed in this proposed rule, if technologically feasible, for appropriate purposes. In fact, we encourage the use of these standards-based APIs for purposes beyond the proposed requirements to improve the interoperability of health data regardless of the use case.
To drive interoperability, improve care coordination, reduce burden on providers and payers, and empower patients, we are proposing several requirements for MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, as well as MIPS eligible clinicians participating in the MIPS Promoting Interoperability performance category, and eligible hospitals and CAHs in the Medicare Promoting Interoperability Program. We are also including RFIs to gather information that may support future rulemaking or other initiatives.
Executive Order (E.O.) 13985 of January 20, 2021, entitled “Advancing Racial Equity and Support for Underserved Communities Through the Federal Government,” set Administration policy that the “Federal Government should pursue a comprehensive approach to advancing equity for all.”
In the CMS Interoperability and Patient Access final rule, we required 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) to implement and maintain a standards-based Patient Access API. The Patient Access API must allow patients, through the health applications of their choice, to easily access their claims and encounter information as well as clinical data, including laboratory results, and provider remittances and enrollee cost-sharing pertaining to such claims, if maintained by the impacted payer, (85 FR 25558). In this proposed rule, we are proposing to require that 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, we are proposing to require these impacted payers to 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, we are proposing to require that 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), utilizes 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.
In the CMS Interoperability and Patient Access final rule, CMS required certain payers (MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) to exchange a patient's health data with other payers at the patient's request, beginning on January 1, 2022, or plan years beginning on or after January 1, 2022, as applicable (85 FR 25568). We also required those payers to incorporate the data they receive through this payer to payer data exchange into patient records, with the goal of creating longitudinal records that would follow patients as they move from payer to payer throughout their healthcare journey. However, we did not require a standards-based API for the payer to payer data exchange.
Since the rule was finalized in May 2020, multiple impacted payers reported to CMS that the lack of technical specifications for the payer to payer data exchange requirement in the CMS Interoperability and Patient Access final rule was creating challenges for implementation, which, they stated, could lead to incompatible implementations across the industry, poor data quality, operational challenges, and increased administrative burdens. They were concerned that different implementation approaches could create gaps in patient health information, which would directly conflict with the intended goal of interoperable payer to payer data exchange.
After considering stakeholder concerns about implementing the payer to payer data exchange requirement finalized in the CMS Interoperability and Patient Access final rule, we announced in a December 10, 2021
To improve the patient experience and access to care, we are also proposing several new requirements for prior authorization processes that we believe would ultimately reduce burden on patients, providers, and payers. To streamline the prior authorization process, we are proposing to require 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.
We are proposing to require that 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. We are proposing
We are proposing a new measure for electronic prior authorization for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. To promote PARDD API adoption, implementation, and use among MIPS eligible clinicians, eligible hospitals, and CAHs, we are proposing to add a new measure titled “Electronic Prior Authorization” under the Health Information Exchange (HIE) objective in the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program, beginning with the performance period/EHR reporting period in calendar year (CY) 2026. For this measure, we are proposing that a MIPS eligible clinician, eligible hospital, or CAH must report a numerator and denominator or (if applicable) an exclusion.
Although these proposals do not directly pertain to Medicare FFS, we want to ensure that people with Medicare can benefit from the policies we are proposing, regardless of their coverage or delivery system. We intend for the Medicare FFS program to be a market leader on data exchange, including through the Provider Access, Payer-to-Payer, and Prior Authorization APIs. and therefore, seek comment throughout on how these proposals could apply to Medicare FFS. Similarly, we encourage other payers not directly impacted by this proposed rule to evaluate our proposals for voluntary adoption to reduce burden and support greater interoperability. Further information about CMS initiatives to achieve the desired level of data exchange with patients, providers and other payers can be found in those sections in this proposed rule.
We are also including five RFIs to gather information that may support future rulemaking or other initiatives. Specifically, we request information on barriers to adopting standards, and opportunities to accelerate the adoption of standards, for social risk data. We recognize that social risk factors (for example, housing instability and food insecurity) influence patient health and healthcare utilization. In addition, we understand that providers in value-based payment arrangements rely on comprehensive, high-quality social risk data. Given the importance of these data, we want to understand how we can better standardize and promote the exchange of these data in accordance with the law.
Additionally, we are seeking comment on how CMS could leverage APIs (or other technology) to facilitate electronic data exchange between and with behavioral healthcare providers, which generally have lower rates of EHR adoption than other provider types.
Furthermore, in the Medicare FFS program, the ordering provider can be different than the rendering provider of items or services, which creates unique obstacles to the coordination of patient care and exchange of medical information needed to ensure an accurate and timely payment. We are interested in public comments regarding how Medicare FFS could support improved medical documentation exchange between and among providers, suppliers, and patients as we believe it could enable better care for beneficiaries if covered services are not delayed by inefficiencies.
We also seek comment on how using data standards and electronic health records can improve maternal health outcomes. Additionally, we include questions related to how prior authorization can be improved and what special considerations should be given to support data sharing in maternal health care.
Finally, we seek comment on how to encourage providers and payers to enable exchange under TEFCA to make patient information more readily available for access and exchange in a variety of circumstances. We wish to understand how CMS can support enabling exchange under TEFCA and what concerns commenters have about potential requirements related to enabling exchange under TEFCA.
In the CMS Interoperability and Patient Access final rule (85 FR 25558), in order to give patients access to their own health information in a way most meaningful and useful to them, we required impacted payers to share, via FHIR APIs, certain information including patient claims, encounter data, and a subset of clinical data that patients can access via health apps. Claims and encounter data, used in conjunction with clinical data, can offer a broad picture of an individual's healthcare experience. In the CMS Interoperability and Patient Access final rule (85 FR 25523), we gave examples of how claims data can be used to benefit patients and providers. For example, inconsistent benefit utilization patterns in an individual's claims data, such as a failure to fill a prescription or receive recommended therapies, can indicate to a provider or payer that the individual has had difficulty financing a treatment regimen and may require less expensive prescription drugs or therapies, additional explanation about the severity of their condition, or other types of assistance.
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. This lack of comprehensive patient data can impede care coordination efforts and access to appropriate care.
As stated in section I.A. of this proposed rule, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates feedback we received from stakeholders. We understand that many readers may be familiar with that proposed rule, and, in an effort to distinguish the differences between that proposed rule and our proposals herein, we refer readers to section I.A. of this proposed rule outlining the overarching differences between them. In this proposed rule, we are again proposing to require impacted payers to report Patient Access API metrics to CMS. However, we have changed the proposal to require reporting annually, as opposed to quarterly. In addition, we are no longer proposing that impacted payers maintain a process for requesting an attestation from health app developers when the developers register their app with the payer's Patient Access API. Instead, we are seeking comment on a variety of privacy considerations. Finally, we propose to extend the compliance date for our proposed policies to January 1, 2026.
As mentioned in section I.A. of this proposed rule, the proposals in this rule do not directly pertain to Medicare FFS. However, if our proposals are finalized, we plan to implement these provisions for Medicare FFS so that people with Medicare FFS could also benefit from their data availability. Through Blue
In the CMS Interoperability and Patient Access final rule (85 FR 25558-25559), we adopted regulations that require certain payers, specifically MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, to implement and maintain APIs that permit enrollees to use health apps to access data specified at 42 CFR 422.119, 431.60, 457.730, 438.242(b)(5), and 457.1233(d) and 45 CFR 156.221, respectively. The Patient Access API must make available, at a minimum, adjudicated claims (including provider remittances and enrollee cost-sharing), encounters with capitated providers, and clinical data, including laboratory results, with a date of service on or after January 1, 2016, as maintained by the payer. We finalized a policy that payers must make those data available via the Patient Access API no later than 1 business day after a claim is adjudicated or encounter or clinical data are received.
To enhance our policy by improving the usefulness of the information available to patients, we are proposing to add information about prior authorizations to the categories of data required to be made available to patients through the Patient Access API. In this section, we refer to the provider's workflow and associated information and documentation as the “prior authorization request” and the payer's processes and associated information and documentation as the “prior authorization decision.” This proposal would apply to all prior authorization requests and decisions for items and services (excluding drugs) for which the payer has data, whether the decision is still pending, active, denied, expired, or is in another status, as discussed further in this section. The primary goal of the Patient Access API is to give patients access to their health information. By expanding patient access to prior authorization information, we intend to help patients be more informed decision makers and true partners in their healthcare.
As discussed in section I.A. of this proposed rule, our proposals for prior authorization APIs and processes do not apply to drugs of any type that could be covered by an impacted payer, including, for example, outpatient drugs, drugs that may be prescribed, drugs that may be administered by a provider, or drugs that may be administered in a pharmacy or hospital. In section II.D. of this proposed rule, we propose several provisions focused on making the prior authorization process less burdensome for providers and payers, which we anticipate would reduce care delays and improve patient outcomes. We believe that giving patients access to information about prior authorization requests and decisions would enable patients to take a more active role in their own healthcare. As a result, we are proposing to require impacted payers to provide patients with access to information about the prior authorization requests made for their care through the Patient Access API.
We propose to require that via the Patient Access API, impacted payers make information about prior authorization requests and decisions (and related administrative and clinical documentation) for items and services (excluding drugs) available to patients no later than 1 business day after the payer receives the prior authorization request or there is another type of status change for the prior authorization. Examples of status changes include: a payer approves or denies a pending prior authorization request, a provider or patient updates a denied prior authorization request with additional information for reconsideration, or the count of the items or services used under the prior authorization decision is updated. We expect that impacted payers use a variety of terminology, but, generally, any meaningful change to the payer's record of the prior authorization request or decision would require an update to the information available to the patient. For the requirement to include prior authorization information in the data available via the Patient Access API, we propose a January 1, 2026 compliance date (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).
The required information available through the API would include the prior authorization status, the date the prior authorization was approved or denied, the date or circumstance under which the authorization ends, the items and services approved, and the quantity used to date under the authorization. The documentation required to be shared includes any materials that the provider sends to the payer to support a decision, for example, structured or unstructured clinical data including laboratory results, scores or assessments, past medications or procedures, progress notes, or diagnostic reports. In section II.D.4.a. of this proposed rule, we propose that in the case of a prior authorization denial, the payer must provide a specific reason for the denial. We propose that impacted payers would have to make that specific reason for denying a prior authorization request available to the patient via the Patient Access API as well. This information can help patients understand both why a payer denied a prior authorization request and/or what items and services were authorized for the patient's recent care.
As further discussed in sections II.B. and II.C. of this proposed rule, we are proposing to require impacted payers to share the same information about prior authorization requests and decisions with a patient's provider via the Provider Access API and via the Payer-to-Payer API. In this way, these prior authorization data can potentially be available to all relevant parties. We note that the requirement to share information about prior authorization via the API is in addition to any notice requirement that applies to prior authorization requests and decisions, such as the proposals to require notice of a decision within certain timeframes discussed in section II.D.5.b. of this proposed rule.
We believe that 1 business day is appropriate, as patients need timely access to the information to understand prior authorization processes and their available care options. As discussed further in section II.D. of this proposed rule, we are proposing to require payers to make much of the same information about prior authorization requests and decisions available via the PARDD API during the decision-making process. In
We are also proposing to require that information about prior authorizations (and related administrative and clinical documentation) be available via the Patient Access API for as long as the authorization is active and at least 1 year after the last status change. We note that we are formulating our proposal for at least 1 year after any status change, but this provision would be particularly relevant to denied and expired prior authorizations, to ensure that they would be available for at least a year after expiring or being denied. We do not propose to require that payers share a patient's full prior authorization history because that could comprise a significant amount of information that may no longer be clinically relevant. Claims, encounter, and/or clinical data can provide important information about a patient's health history. With those data available through the Patient Access API, we believe that process-related information about long-expired or denied prior authorizations would be redundant. Also, as prior authorization rules may change over time, we believe that this information has a limited lifespan of usefulness to a patient's current care. At the same time, the API should include information about all active authorizations for as long as they are active and therefore may be related to ongoing care.
We anticipate that requiring payers to make prior authorization information accessible through the Patient Access API would help patients better understand the lifecycle of a prior authorization request, the items and services that require prior authorization, the information being considered, and specific clinical criteria their payer uses to make a determination. We believe that more transparency would better equip patients to engage with their payer(s) and/or provider(s). For example, by having access to certain prior authorization information via the Patient Access API, a patient could see that prior authorization is needed and has been submitted for a particular item or service, which could help them better understand the timeline for the process and plan accordingly. Supporting documentation could give patients better visibility into what the payer is evaluating so they could help providers get the best and most accurate information to payers to facilitate a successful request, thus potentially avoiding unnecessary care delays and reducing burden on providers and payers. The proposed requirement could also reduce the need for patients to make repeated calls to their providers and payers to understand the status of requests, or to inquire why there are delays in care.
We believe that this proposal would enable patients to participate in their care more and reduce burden on both providers and payers to allow them to more efficiently navigate the prior authorization process. The proposal may also add an additional layer of accountability for payers to make timely prior authorization decisions, as patients would be able to follow the prior authorization process from initiation to conclusion. As with all information made available via the Patient Access API, we believe industry is in the best position to develop apps for patients to effectively use this information, and to make sure that the apps are accessible to people with disabilities. We look to industry innovators to produce apps that will help patients understand their health information and access it in a manner that is useful to them.
In summary, we propose 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. We are also proposing 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 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 at the CFR sections identified in Table 1.
The requirements for a Patient Access API imposed on Medicaid managed care plans and CHIP managed care entities are set forth at 42 CFR 438.242(b)(5) and 457.1233(d), respectively. Through an amendment to paragraph (b)(5) and by adding a new paragraph (b)(8) at 42 CFR 438.242, we are proposing to require Medicaid managed care plans (and through § 457.1233(d), CHIP managed care entities) to include information about prior authorization requests and decisions and related administrative and clinical documentation in the data available via to the Patient Access API by the rating period beginning on or after January 1, 2026. We request comment on this proposal.
We request comment on how we could or should apply these requirements to Medicare FFS and its existing prior authorization requirements and standards.
As stated earlier in this preamble, the proposals in this proposed rule do not apply to any drugs. However, we also request comments on whether we should consider policies to require impacted payers to include information about prior authorizations for drugs, when the payer covers drugs, via the Patient Access API, the Provider Access API, and the Payer-to-Payer API. We request comments on how future rulemaking to make information about prior authorizations for drugs available through these APIs might interact with existing prior authorization requirements and standards.
Previous proposals have elicited numerous comments regarding the interaction between the Patient Access API and HIPAA Privacy Rule requirements for individual access.
When an individual requests an electronic copy of PHI that a covered entity maintains electronically (ePHI), per 45 CFR 164.524(c)(2)(ii), the covered entity must provide the individual with access to the information in the requested electronic form and format, if it is readily producible in that form and format. When the ePHI is not readily producible in the electronic form and format requested, then the covered entity must provide access to an agreed upon alternative readable electronic format.
Individuals have the right under the HIPAA Privacy Rule to request access to PHI in the form and format requested by the individual, if it is readily producible in the manner requested.
Disagreement with the individual about the worthiness of a health app as a recipient of PHI, or even concerns about what the app might do with the requested PHI, would not be acceptable reasons to deny an individual's request.
We discussed privacy and safety concerns in the context of APIs in the CMS Interoperability and Patient Access final rule (85 FR 25516). We note that while the FHIR standard itself does not define security-related functions, when used in combination with appropriate security controls (such as authentication and access control), a FHIR API can and should be implemented and maintained to comply with the HIPAA Security Rule for secure data exchange.
Our proposals in this section address how a payer must make patients' data available to them; however, we do not have the authority to regulate health apps that individuals may wish to use, or what those apps do with PHI. As discussed, per the CMS Interoperability and Patient Access final rule, impacted payers may only deny or discontinue an app's connection to their APIs if an impacted payer makes a determination using objective, verifiable criteria that the specific health app would present a danger to the impacted payer's own systems, such as increasing the risk of cyber-attack.
Regardless of whether HIPAA applies to a health app, other Federal laws may apply, even where HIPAA does not apply, such as the Federal Trade Commission (FTC) Act. Under section 5 of the FTC Act (15 U.S.C. 45(a)), the FTC has authority to challenge unfair or deceptive trade practices, including those related to the privacy and security of personal health information that apps collect, use, maintain, or share. For example, if an app discloses an individual's health information in a manner inconsistent with the app's privacy policy, terms of use, or an individual's reasonable expectations, or fails to take reasonable measures to assess and address privacy or data security risks, the developer of that app may be violating the FTC Act. The FTC has applied its section 5 authority to a
The FTC also enforces the FTC Health Breach Notification Rule, which covers most health apps and similar technologies that are not covered by HIPAA, and therefore, not subject to the HIPAA Breach Notification Rule.
As we discussed earlier in this proposed rule and in detail throughout the CMS Interoperability and Patient Access final rule (85 FR 25550), one of the most important aspects of making health data accessible to patients is to protect the privacy and security of patient health information, especially because once a patient's data are received by a health app, their data may no longer be protected by the HIPAA Rules.
In the CMS Interoperability and Patient Access final rule, we required that impacted payers make educational resources available to their current and former patients with information to help protect the privacy and security of their health information. That includes factors to consider in selecting an app, including potential secondary uses of data, and the importance of understanding the security and privacy practices of any app to which they will entrust their health information. Furthermore, impacted payers must provide an overview of which types of organizations or individuals are and are not likely to be HIPAA-covered entities, and the oversight responsibilities of the Office for Civil Rights (OCR) and the FTC, and how to submit a complaint to those entities. See 42 CFR 422.119(g) for MA organizations, 42 CFR 431.60(f) for Medicaid FFS programs, through existing cross-reference at 42 CFR 438.242(b)(5) for Medicaid managed care plans, 42 CFR 457.730(f) for CHIP FFS programs, through existing cross reference at 42 CFR 457.1233(d) for CHIP managed care entities, and at 45 CFR 156.221(g) for QHP issuers on the FFEs. We continue to believe these resources are important to provide to patients, but seek comments on how we can improve this policy so patients can make educated decisions about sharing their personal health information.
In the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program final rule (21st Century Cures Act final rule) (85 FR 25642, 25814 through 25815), ONC noted that providing information that is factually accurate, objective, unbiased, not unfair or deceptive, and provided in a non-discriminatory manner to inform a patient about the advantages, disadvantages and any risks of sharing their health information with a health app, would be unlikely to interfere (as defined in that rule) with the access, exchange, or use of electronic health information (EHI) for purposes of the information blocking regulations at 45 CFR part 171.
In response to comments on the CMS Interoperability and Patient Access proposed rule (84 FR 7610), we noted in the final rule (85 FR 25549-25550) commenters' observations that many patients were unlikely to understand the potential risk of disclosure when their data are transmitted to a health app and are thus no longer protected by the HIPAA Rules. Commenters were specifically concerned about secondary uses of data, such as whether developers would sell their data to third parties for marketing or other purposes. In the CMS Interoperability and Patient Access final rule (85 FR 25549), we noted that a clear, plain language privacy policy is the best vehicle to inform patients about how their information will be protected and how it will be used once shared with the health app.
In the December 2020 CMS Interoperability proposed rule (85 FR 82592 through 82594), we proposed to require impacted payers to request a privacy policy attestation from health app developers when their app requests to connect to the payer's Patient Access API. We proposed that the attestation would include, at a minimum, statements that the app has a plain language privacy policy that is always publicly available and accessible, and has been affirmatively shared with the patient prior to the patient authorizing the app to access their health information. In addition, the attestation we proposed included yes/no elements as to whether the privacy policy specifically communicates how the patient's health information could be accessed, exchanged, or used.
While we still believe that certain aspects of our previously proposed attestation policy could support enhanced patient education about health apps' privacy policies, based on public comments and feedback, we are concerned that this type of attestation would not serve to benefit patients in ways that would outweigh the burden on impacted payers. We are also concerned that such a policy could have unintended consequences for patients. Under the proposal in the December 2020 CMS Interoperability proposed rule, a health app developer would only be attesting to the format and inclusion of certain information. There would be no attestation that the substance of the privacy policy meets specific minimum requirements or best practices. We believe that having payers inform patients that an app developer has attested to the form and format of a privacy policy could easily be misinterpreted as assurance that the substance of the privacy policy has been reviewed and found acceptable by the payer (or CMS). We believe this is especially true in the case of patients with low health or technology literacy, who are least likely to be able to find and interpret an app's privacy policy to make well-informed decisions about their health data. We are concerned that requiring such an attestation would only give the appearance of privacy and
Because CMS does not have the statutory authority to regulate health apps, we cannot require developers to respond to that attestation. Furthermore, as discussed, even if a health app developer does not respond to the attestation (or responds in the negative), a payer would be required to allow that app to connect (unless it would create a security risk to the payer's own system) and provide a patient's health information through the app selected by the patient.
Commenters also responded that the proposed process would put an undue burden on payers to manage an attestation process for app developers with whom they may have no legal or contractual relationship. Furthermore, commenters expressed concerns about payers' lack of adherence mechanisms and payer liability due to the HIPAA right of access requirements discussed previously.
We still believe it is important for patients to have a clear understanding of how their health information may be used by a person or entity not covered by the HIPAA Rules, such as a health app, whether their data would be sold or marketed, and how to stop sharing their health information with such entities if they so choose. In particular, explaining certain privacy and security practices in a patient-friendly, easy-to-read privacy policy would help patients understand those elements and how they can be an active participant in the protection of their information. We also encourage app developers to follow industry best practices, including the CARIN Alliance's Code of Conduct and the ONC Model Privacy Notice (MPN).
We request comments on how we can help give patients the tools they need to understand the privacy and security implications of using a health app within the scope of our regulatory authority. We seek ideas on how we can balance our desire to both educate patients and respect their rights under the HIPAA Privacy Rule. For example, should there be a process at the time a developer registers an app with a payer for access to the API to submit information about its privacy policy? Should payers be required to provide that information in an easy-to-understand format the first time a patient requests access via an app? We encourage comments about how we can leverage the MPN (most recent version from 2018). While we cannot require health app developers to utilize the MPN, should payers notify patients, the first time the patients request data through an app, whether the app utilizes the MPN or not? To encourage visibility for apps that use the MPN versus those that do not, should payers be required to list apps that have established access to their API on their websites that comply with the MPN's transparency requirements? We note that payers would have to treat apps identically based on the substance of their privacy policies and could not favor certain apps over others, such as for competitive advantage. Again, we (and payers) cannot prohibit patients from using health apps that do not comply with best privacy and security practices unless it presents an unacceptable security risk to the payer's systems.
We also request comment on whether we can leverage and build on other HHS health information exchange initiatives, such as TEFCA, to address these issues. For more background on TEFCA, see the related Request for Information in section III.E. of this proposed rule. The Common Agreement and Framework Agreement include privacy and security requirements for Qualified Health Information Networks (QHINs), Participants, and Subparticipants that elect to exchange information pursuant to it, including entities not covered by the HIPAA Rules.
IAS Providers must, among other requirements, have a written privacy and security notice; obtain express written consent from individuals regarding the way their information will be accessed, exchanged, used (as defined in the Common Agreement), or disclosed (as defined in the Common Agreement), including the sale of their health information; provide individuals with the right to delete their individually identifiable information as well as the right to revoke their consent, with certain exceptions, in addition to a disclosure of any applicable fees or costs related to IAS; and provide individuals with the right to obtain an export of their individually identifiable information in a computable format.
Given the Common Agreement's privacy and security requirements, and particularly those that will apply when patients access their health information through a participating IAS Provider, we request comment on whether CMS should explore requirements or ways to encourage exchange under TEFCA as a way to ensure that more patients are informed about the privacy and security implications of using health apps to access their health information, consistent with the requirements for IAS Providers described previously. For instance, how could CMS encourage health apps that are not subject to the HIPAA Rules to connect to entities that exchange information under TEFCA? If so, what should be the contours of, and levers for, such encouragement? What other approaches can CMS take to encourage app developers to enable exchange under TEFCA and therefore leverage the Common Agreement's privacy and security requirements?
In addition, we request comments on the availability of apps that are accessible to individuals with disabilities, availability of apps in a multitude of languages to ensure that individuals with limited English proficiency can understand the information provided, and availability of apps at an appropriate literacy level and in plain language. We note that the draft IAS Provider Privacy and Security Notice and Practices SOP includes guidance regarding plain language and literacy requirements.
We are proposing to require impacted payers to report metrics in the form of aggregated, de-identified data to CMS on an annual basis about how patients use the Patient Access API. This reporting would help CMS better understand whether the Patient Access API requirement is efficiently and effectively ensuring that patients have access to their health information and whether payers are providing that required information in a transparent and timely way. Aggregated usage data from every impacted payer would help us evaluate whether the Patient Access API policies are achieving the desired goals. Gathering this information would also help us to provide targeted support or guidance to impacted payers, if needed, to help ensure that patients have access to their data and can use their data consistently across the impacted payer types. We propose to require MA organizations to report these data to CMS at the organization level, state Medicaid and CHIP FFS programs to report at the state level, Medicaid managed care plans to report at the state level, CHIP managed care entities to report at the state level, and QHP issuers on the FFEs to report at the issuer level. We are considering, and therefore seek comment on, whether we should require payers that administer multiple plans under a single contract to report these data to CMS at the contract level. We also seek comment on the benefits or drawbacks of an alternative final policy that would permit MA organizations, entities offering Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to report aggregate data for the same plan type at higher levels (such as the parent organization level or all plans of the same type in a program). We note that in the December 2020 CMS Interoperability proposed rule (85 FR 82594), we proposed that these data be reported quarterly, and received comments from a broad variety of stakeholders strongly in favor of annual reporting. Based on that feedback, we are now proposing annual reporting.
Specifically, we propose that these payers annually report:
• The total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and
• The total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient.
Tracking multiple data transfers would indicate repeat access, showing that patients are either using multiple apps or are allowing apps to update their information over the course of the year. While we are not certain whether such data transfers would indicate to what extent patients are using the apps to manage their healthcare, it would be a preliminary indicator of interest in the technology to access their data.
We are proposing that payers must report data from the previous calendar year to CMS by March 31 of each year. The first year the requirement would be applicable, payers would report calendar year 2025 data by March 31, 2026. A new MA organization, Medicaid managed care plan, CHIP managed care entity, or QHP issuer on the FFEs would naturally have no data to report in its first year of existence and would be required to report data following its first full calendar year subject to the Patient Access API requirement.
In summary, we propose that beginning in 2026, MA organizations at the organization level, state Medicaid and CHIP FFS programs at the state level, Medicaid managed care plans at the state level, CHIP managed care entities at the state level, and QHP issuers on the FFEs at the issuer level must annually report the following metrics to CMS in the form of aggregated, de-identified data: (1) the total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and (2) the total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient. Collecting this information would facilitate CMS' oversight and evaluation of the MA, Medicaid, and CHIP programs and of QHP issuers on the FFEs. We propose that impacted payers report the previous calendar year's metrics, in the form of aggregated, de-identified data, to CMS by March 31 of each year. MA organizations, Medicaid managed care plans, and CHIP managed care entities would report metrics to CMS following any year that they operated, and QHP issuers would report metrics to CMS following any year that they offered a QHP on the FFEs. We are making this proposal at the CFR sections identified in Table 1.
If we finalize this proposal, we do not plan to publicly report these metrics at the state, plan, or issuer level, but may reference or publish aggregated and de-identified data that does not include names of specific state agencies, plans, or issuers. We solicit comment on this aspect of our proposal.
In addition, we request comment on what other Patient Access API metrics we should consider requiring payers to report to CMS and/or make available to the public on their own websites, for consideration in possible future rulemaking. For instance, we are seeking comments on whether payers could report aggregated demographic information, such as sex, race, age, ethnicity, and geographical (for instance, by zip code) data that they may already have to help identify disparities in patient access to health data or underserved populations and, if so, what policies should be considered to minimize those disparities. We are also seeking comment on the potential benefits and burden of requiring payers to report the names of all apps that patients have used to access the payers' API each year. We are considering either collecting this information, or requiring payers to make it public, not to recommend or endorse specific apps, but to maintain a view of the apps that patients use to access their health information, which could help us review for best practices and to evaluate patient ease of use.
To accommodate the proposed requirements regarding the use of the Patient Access API, we are proposing two minor terminology changes to the requirements finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558, 25547). We note that unlike most of our proposals, we are proposing that these amendments would go into effect on the effective date of the final rule. We are proposing these changes to clarify terms, but do not expect them to substantively change any current regulatory obligation.
First, we are proposing to revise the description of the clinical data to be made available via the Patient Access API by MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 1. These provisions currently require payers to make available “clinical data, including laboratory results.” We are proposing to revise these paragraphs to specify that the data that payers must make available are “all data classes and data elements included in a content standard at 45 CFR 170.213.” The standard currently referenced at 45 CFR 170.213 is the USCDI version 1. Laboratory Values/Results is a USCDI version 1 data element, and USCDI version 1 includes data classes for other aspects of clinical information such as Immunizations, Procedures, and Assessment and Plan of Treatment. Referring explicitly to the data set in a standard at 45 CFR 170.213 in the rule text would help avoid unnecessary confusion, as this reference would more clearly identify exactly what data must be available through the Patient Access API.
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. For the ONC Health IT Certification Program, this allows for a transition period between standards as health IT developers incorporate updated standards versions within their systems and complete required certification. Through this proposal, we are seeking to ensure that the same flexibility would apply for payers as they transition between the versions of the USCDI. During such a period, when 45 CFR 170.213 includes more than one version of the USCDI standard, payers would be allowed to use any of the then-available standards at 45 CFR 170.213 for the data classes and elements that they make available through the API.
Second, we are proposing to revise the language previously finalized for denial or discontinuation of a health app's access to the API. Currently, the rules require that the payer make a determination to deny or discontinue access to the Patient Access API using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which “enrollees” or “beneficiaries” seek to access EHI. We are proposing to change the terms “enrollees” and “beneficiaries” to “parties” for consistency with our proposal to apply this provision to the Provider Access API, Payer-to-Payer API, and the PARDD API discussed further in sections II.B., II.C., and II.D. of this proposed rule. Because other parties would be accessing these APIs, such as providers and payers, it would be more accurate to use the term “parties” rather than “enrollees” or “beneficiaries.”
In summary, we propose that we will replace “clinical data, including laboratory results” with “all data classes and data elements included in a content standard at 45 CFR 170.213” for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 1. We also propose that we will change the terms “enrollees” and “beneficiaries” to “parties” for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 1.
We request comment on these proposals. We also direct readers to section II.F. of this proposed rule for a discussion of proposed changes to the interoperability standards for APIs that affect the Patient Access API.
Specifically, for CHIP, the proposed amendments to 42 CFR 457.1233(d) would align separate CHIP managed care API requirements with the Medicaid managed care API requirements, rather than with the CHIP FFS API requirements. In the CMS Interoperability and Patient Access final rule (85 FR 25559), we finalized requirements for separate CHIP managed care entities at 42 CFR 457.1233(d). API requirements for CHIP managed care entities were codified at 42 CFR 457.1233(d)(2) and (3) through cross-references to CHIP FFS program requirements at 42 CFR 457.730 and 457.760, respectively. On November 13, 2020, we published a final rule titled “Medicaid Program; Medicaid and Children's Health Insurance Program (CHIP) Managed Care” (85 FR 72754). In that rule, we removed 42 CFR 457.1233(d)(1) through (3), and, at 42 CFR 457.1233(d), cross-referenced to Medicaid managed care regulatory requirements at 42 CFR 438.242. Therefore, the policies in the CMS Interoperability and Patient Access final rule (85 FR 25559) are applicable to separate CHIP managed care entities per 42 CFR 457.1233(d) through a cross reference to Medicaid managed care at 42 CFR 438.242. We propose to apply the API requirements in this proposed rule to separate CHIP managed care entities through the existing cross reference at 42 CFR 457.1233(d) to Medicaid managed care at 42 CFR 438.242, and have noted this throughout the proposals in this proposed rule.
Most states have Medicaid Expansion CHIP programs, in which a state receives Federal funding to expand Medicaid eligibility to optional targeted low-income children that meet the requirements of section 2103 of the Social Security Act (the Act). We are proposing at 42 CFR 457.700(c) that for states with Medicaid Expansion CHIP programs, the proposals in this rule for Medicaid would apply to those programs rather than our proposals for separate CHIP programs. Functionally, our proposals are the same, however, for clarity, we are making explicit that the Medicaid requirements at 42 CFR 431.60, 431.61, and 431.80 would apply to those programs rather than the
For MA organizations, we are proposing these new requirements and the revisions to current requirements under our authority at sections 1856(b)(1) (to promulgate regulations implementing MA standards, including the requirements in section 1852(h) of the Act), and 1857(e)(1) of the Act (to add contract terms determined by the Secretary to be “necessary and appropriate”). Section 1856(b)(1) of the Act requires the Secretary to establish regulatory standards for MA organizations that are consistent with and carry out Part C of the Medicare statute, Title XVIII of the Act. Section 1852(h) of the Act requires that MA organizations have procedures in place to maintain accurate and timely medical records and health information regarding MA enrollees and to assure enrollees have timely access to such records and information. Our proposal for the Patient Access API is to require access for enrollees to specified medical records and health information through a specific mechanism from the MA organization. The Secretary is authorized under section 1857(e)(1) of the Act to add new contract terms, including additional standards and requirements, for MA organizations that the Secretary finds necessary and appropriate and that are not inconsistent with Part C of the Medicare statute. The proposals here meet this standard by addressing and facilitating access to enrollees' medical records and health information for the reasons identified in our discussions for each proposal.
The proposal in section II.A.2.a. of this proposed rule that would require MA organizations to make an enrollee's prior authorization requests and related clinical documentation available through the Patient Access API would, if finalized as proposed, allow these enrollees to have access to that information in a convenient, timely, secure, and portable way, which is in enrollees' best interests. This proposed requirement is consistent with section 1852(h) of the Act, which requires MA organizations to assure enrollees timely access to their records and data that is maintained by MA organizations. To ensure that MA organizations meet modern-day patient expectations of transparency, efficiency, and timeliness when providing prior authorization data to enrollees, it is essential for CMS to ensure that each MA organization has a standardized system in place that offers enrollees access to their own data, including data that pertain to their prior authorizations, using existing and emerging technologies of their choice, specifically in this case, health apps. Therefore, making these data available through the Patient Access API is consistent with our programmatic authority to establish standards to implement section 1852(h) of the Act, and could help patients be more informed about and active in their own care, which could potentially lead to better health outcomes.
Making this information available via the Patient Access API could help enrollees support the prior authorization process, as well. Enrollees could see what information is needed and what information has been provided on their behalf to facilitate a prior authorization request. Enrollees could provide missing information needed by the payer to reach a decision. This could allow MA organizations to address prior authorization requests more promptly, streamlining this process, and thus simplifying prior authorization for the MA organizations. This could also improve an enrollee's experience with the process, by facilitating timelier and potentially more successful initial prior authorization requests. This, again, supports efficient operation and timely provision of information and services.
In addition, to ensure the requirements proposed here and finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559) would be most effective, CMS proposes in this rule that MA organizations report specific metrics to CMS on enrollee use of the Patient Access API. Section 1857(e)(1) of the Act explicitly authorizes the adoption of additional reporting to CMS by MA organizations where necessary and appropriate. Here, these proposed metrics would facilitate CMS's oversight, evaluation, and administration of patient health data access in the Part C program and therefore, this data collection is necessary and appropriate to adopt.
In alignment with HHS's priorities and goals, CMS is focused on putting patients at the center of their own healthcare and ensuring patients have secure access to their health information. We believe these proposals are critical and appropriate to ensure that MA organizations stay abreast of industry standards and continue to offer enrollees not only quality coverage but also a quality customer experience.
Our proposed requirements in this section for Medicaid managed care plans and Medicaid state agencies fall generally under our authority in sections 1902(a)(4), 1902(a)(7), 1902(a)(8), and 1902(a)(19) of the Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. Section 1902(a)(8) of the Act requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals. Section 1902(a)(19) of the Act requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients.
In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to uses or disclosures of information that are directly connected with the administration of the Medicaid state plan. The implementing regulations for this section of the Act list purposes that CMS has determined are directly connected to Medicaid state plan administration at 42 CFR 431.302 and provide safeguards states must apply to uses and disclosures of beneficiary data at 42 CFR 431.306. CHIP programs are subject to the same requirements through a cross reference at 42 CFR 457.1110(b). Our proposal to require that the data described in this section be shared via the Patient Access API would be consistent with the requirement that states may share these data only for purposes directly connected to the administration of the Medicaid state plan, since this data sharing would be related to providing services for beneficiaries, a purpose listed in § 431.302(c). As mentioned previously, giving a patient access to their own health information can make them a more active participant in ensuring they receive timely and appropriate care (for example, allowing them to monitor medications or access treatment history). Additionally, states must apply the safeguards described at 42 CFR 431.306 when sharing beneficiary data via the Patient Access API. We remind states that in order to meet the requirements of that regulation, states must have consistent criteria for release and use of information (which should comply with the proposed Patient Access API requirements, if finalized), in accordance with 42 CFR 431.306(a). Access to information concerning beneficiaries must be restricted to persons who are subject to standards of confidentiality that are comparable to that of the Medicaid agency, in accordance with 42 CFR 431.306(b). The
The proposed requirement to make information about prior authorization requests and associated documentation available through the Patient Access API is expected to allow beneficiaries to more easily obtain information about the status of prior authorization requests submitted on their behalf. Beneficiaries could potentially use that information to make more informed decisions about their healthcare, improve the efficiency of accessing and scheduling services, and, if needed, provide missing information that the state (or Medicaid managed care plan, if applicable) needs to reach a decision. Receiving missing information more quickly could enable more prompt responses from Medicaid FFS programs and managed care plans to prior authorization requests, thus facilitating more timely and successful prior authorizations, which would help states fulfill their obligations to provide care and services in a manner consistent with simplicity of administration and the best interests of the recipients, and to furnish services with reasonable promptness to all eligible individuals. Improving the prior authorization process could also help improve the efficient operation of the state plan by potentially improving the speed and consistency of prior authorizations, which could, in turn, facilitate faster access to care for beneficiaries. In these ways, these proposals are authorized under section 1902(a)(4), (8), and (19) of the Act.
In addition, this proposal would help implement section 1932(b)(4) of the Act, which provides that each Medicaid managed care organization must establish an internal grievance procedure under which a beneficiary who is eligible for medical assistance may challenge the denial of coverage or payment for such assistance. CMS has traditionally extended requirements applicable to Medicaid managed care organizations to other Medicaid managed care plan types as efficient and proper methods of administration under section 1902(a)(4) of the Act to ensure that Medicaid beneficiaries have the same protections, benefits, and responsibilities regardless of the type of managed care plan in which they are enrolled. Allowing beneficiaries to access the status of their denied prior authorizations within 1 business day could enable beneficiaries to file appeals timelier and receive faster resolution. Enabling beneficiaries to monitor the status of prior authorization requests submitted on their behalf is also consistent with how section 1932(c)(2)(A) of the Act indicates that timely access to care should be assured for beneficiaries. Knowing within 1 business day that a prior authorization has been approved could enable a beneficiary to more promptly schedule or obtain care.
We are also proposing to require state Medicaid agencies and Medicaid managed care plans to report Patient Access API metrics to CMS annually. We believe that having these metrics would support CMS' oversight, evaluation, and administration of the Medicaid program, as it would allow us to evaluate beneficiary access to the Patient Access API. Use of the API could indicate that the policy is supporting program efficiencies and ensuring access to information in a timely and efficient way and in the best interest of beneficiaries, as intended, and as is consistent with section 1902(a)(4) and (19) of the Act. Additionally, section 1902(a)(6) of the Act requires Medicaid state plans to provide that the state Medicaid agency will make such reports, in such form and containing such information, as the Secretary may from time to time require. These metrics would serve as a report to evaluate the implementation and execution of the Patient Access API.
For CHIP, we propose these requirements under the authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. This provision provides us with authority to adopt these requirements for CHIP because the proposed requirements increase patient access to their health information, which can improve the efficacy of CHIP programs, allow for more efficient communication and administration of services, and promote coordination across different sources of health benefits coverage.
We believe that requiring CHIP agencies, as well CHIP managed care entities, to make CHIP beneficiaries' prior authorization data and other standardized data available through standards-based APIs would ultimately lead to these beneficiaries accessing that information in a convenient, timely, and portable way. This improved access would help to ensure that services are effectively and efficiently administered in the best interests of beneficiaries, consistent with the requirements in section 2101(a) of the Act. We believe making patient data available in this format would result in better health outcomes and patient satisfaction and improve the cost effectiveness of the entire healthcare system, including CHIP.
These proposals align with section 2101(a) of the Act in that they also would improve the efficiency of CHIP programs. For example, adding information about prior authorization requests to the Patient Access API would allow beneficiaries to easily obtain the status of prior authorization requests made on their behalf. This would in turn allow patients to make scheduling decisions, and provide any missing information needed by a payer to reach a decision, which makes the prior authorization process more efficient, ultimately streamlining the prior authorization process.
Additionally, the safeguards for applicant and beneficiary information at subpart F of 42 CFR part 431 are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As discussed above for Medicaid, giving CHIP beneficiaries access to their prior authorization statuses through the Patient Access API would be related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. Allowing beneficiary access to prior authorization statuses also conforms with provisions for beneficiary access to their records at 42 CFR 457.1110(e). We remind states that when they share beneficiary information through the Patient Access API, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306.
Finally, proposing to require state CHIP agencies and CHIP managed care entities to report Patient Access API
For QHP issuers on the FFEs, we propose these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates.
We believe generally that certifying only health plans that take steps to make enrollees' prior authorization requests and related clinical documentation available through interoperable technology would ultimately lead to these enrollees having access to that information in a convenient, timely, and portable way, which is in enrollees' best interests. Having simple and easy access, without special effort, to their health information also would facilitate enrollees' ability to detect and report fraud, waste, and abuse—a critical component of an effective program. Adding information about prior authorization requests to the Patient Access API would allow enrollees to easily obtain the status of prior authorization requests submitted on their behalf and use that information effectively to make more informed decisions about their healthcare, improve the efficiency of accessing and scheduling services, and, if needed, provide missing information needed by the issuer to reach a decision. This could allow QHP issuers on the FFEs to more promptly address prior authorization requests. This would also facilitate timelier and potentially more successful initial prior authorization requests. We encourage SBEs (including SBE-FPs) to consider whether a similar requirement should be applicable to QHP issuers on SBEs.
Finally, proposing to require QHP issuers on the FFEs to report Patient Access API metrics to CMS annually would help CMS assess the effect this API is having on enrollees and would inform how CMS could either enhance the policy or improve access or use through activities such as additional patient education. These data could help CMS understand how best to leverage this API, and patient access to it, to ensure this requirement is being met efficiently and adding value to CMS operations, including leading to the efficiencies intended.
In the CMS Interoperability and Patient Access final rule, we implemented policies regarding the Patient Access API (85 FR 25558) that would allow patients to access their health information through an app. Patients who do so could then share their information with their provider during an appointment. For example, during a visit with a provider, a patient could share specific diagnoses, procedures, and tests accessed through the Patient Access API and stored on their mobile smart device, which could help inform a discussion with their provider about their health status.
We also discussed the potential benefits of payers sharing patient health information directly with providers in that final rule (85 FR 25555) and encouraged payers to consider an API solution that would enable providers to access appropriate health information through the payers' APIs to support the delivery of care. We sought comment on the feasibility of implementing and maintaining a FHIR API for data exchange between payers and providers and received comments strongly supporting our concept to require data availability through a Provider Access API. Some commenters stated that allowing providers to receive data, including prior authorization information, directly from payers would make FHIR-based data exchange significantly more valuable for patients, providers, and payers. More data could be available to help providers manage an individual's total care and providers could reduce or eliminate duplicate tests, which might avoid diagnostic errors. Payers might also see fewer duplicate requests for services, fewer appeals and, possibly, lower costs. We specifically agreed with commenters that making information about prior authorization decisions available via an API would reduce burden on providers and their staff (85 FR 25541).
While using the Patient Access API is a significant first step toward sharing individual patient health information with providers, it would also be beneficial for payers to make patient data directly available to providers via a FHIR API. In the normal course of business, many providers already maintain EHRs and share data for a variety of purposes authorized by the patient and/or existing law. Therefore, in this rule we propose to require that impacted payers implement and maintain a FHIR API that makes patient data available to providers who have a contractual relationship with the payer and a treatment relationship with the patient. The proposed Provider Access API has the potential to allow payers to build upon their existing systems and processes to enhance access to patient data, while continuing to protect patient privacy and data security.
In the December 2020 CMS Interoperability proposed rule, we proposed to require payers to build a Provider Access API. As discussed in section I.A. of this proposed rule, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates the feedback we received from stakeholders on that proposed rule. We understand that many readers may already be familiar with that proposed rule. To distinguish between that proposed rule and our proposals herein, we refer readers to section I.A. of this proposed rule, which outlines the overarching differences between the two proposed rules.
We are again proposing to require impacted payers to implement and maintain a FHIR API to exchange data with providers, but with changes from the December 2020 CMS Interoperability proposed rule. We are again proposing a FHIR API, but we are now taking a different approach to the standards required for the API, as further described in section II.F. of this proposed rule. We are also proposing a patient opt out (rather than an opt in) policy that would require payers to allow patients to opt out of the Provider Access API proposed herein. Finally, we propose to establish the Provider Access API compliance date as January 1, 2026.
As mentioned in section I.A. of this proposed rule, these proposals do not pertain to Medicare FFS. We seek comment on how each of our proposals discussed below on Provider Access API could be implemented for the Medicare FFS program. We expect that a Medicare FFS implementation would conform to the same proposed requirements that apply to the impacted payers under this proposed rule, as applicable, so Medicare FFS providers and patients enrolled in Medicare FFS could also benefit from this type of data sharing. We seek comment on whether this
In the CMS Interoperability and Patient Access final rule (85 FR 25558), we required impacted payers to make certain health information available to health apps when requested by a patient, through a Patient Access API. We believe it would be valuable for providers to have access to the same patient data, except for provider remittances and enrollee cost-sharing information, through a FHIR API that allows a provider to request data for an individual patient, as needed, thereby providing further insight into the patient's care activity. Research shows that patients achieve better outcomes when their record is more complete and there are more data available to the healthcare provider at the point of care.
Therefore, we are proposing to require that impacted payers implement and maintain a Provider Access API to enable current patients' information to be exchanged from payers to providers that are in that payer's network, at the provider's request. A provider in the payer's network, for purposes of this proposal, would be any provider or healthcare facility that is part of a specific health plan's network of providers with which it has a contract. In the case of Medicaid and CHIP FFS programs, it would be any providers or healthcare facilities that are enrolled with the state as Medicaid or CHIP providers. We note that this requirement would only apply to current patients. Once a patient is no longer enrolled with a payer, the payer would not need to share data with providers under this proposal. However, see section II.C. for the proposed Payer-to-Payer API requirements for transferring a patient's data from a previous payer to a new payer.
The proposed Provider Access API would allow a provider to initiate a request, for example, when the provider needs access to a patient's data prior to or during a patient visit. Both this proposed Provider Access API and the Patient Access API would facilitate the FHIR-based exchange of claims and encounter data, as well as all data classes and data elements included in a content standard adopted at 45 CFR 170.213, such as Immunizations, Procedures, and Assessment and Plan of Treatment, should the payer maintain such information. Both the Patient Access and Provider Access APIs would require payers to share information related to prior authorization requests and decisions (including related administrative and clinical documentation) for items and services (excluding drugs). As discussed in section II.A.2.a of this proposed rule, we are proposing to require that information about prior authorizations (and related administrative and clinical documentation) be available via the Patient Access API for as long as the authorization is active, and at least 1 year after the last status change. We note that we are formulating our proposal for at least 1 year after any status change, but this provision would be particularly relevant to denied and expired prior authorizations, to ensure that they would be available for at least a year after expiring or being denied. We do not propose to require payers to share a patient's full prior authorization history, because that could comprise a significant amount of information that may no longer be clinically relevant.
We believe that sharing claims and encounter information, without provider remittances and enrollee cost-sharing information, would complement the clinical data classes and data elements included in a content standard at 45 CFR 170.213 by providing more information to support treatment and care coordination. Claims and encounter data used in conjunction with clinical data can offer a broader, more complete picture of an individual's interactions with all their providers in the healthcare system. With this proposal, we intend to help providers gain efficient access to more comprehensive data on their patients. Thus, we are proposing to require that impacted payers make available any of the applicable patient data with a date of service on or after January 1, 2016. This proposed timeframe for data to be included is consistent with the requirements of the Patient Access API, as finalized in the CMS Interoperability and Patient Access final rule (85 FR 25567), so payers should already be maintaining and making available data from this timeframe via a FHIR API.
Such disclosures from payers to healthcare providers would be permitted under the HIPAA Privacy Rule as disclosures for treatment purposes,
There are a few notable differences between the requirements for a Patient Access API and our proposals for a Provider Access API. The biggest difference is how and why the end user would access the data. For the Patient Access API, the patient is requesting access to their own data through a health app for their own reference and use. For the Provider Access API proposals, the provider would request and receive access to the patient's information through their EHR, practice management system, or other technology solution for treatment purposes, including care coordination. Providers would securely access their patients' data using at least one of these systems through a FHIR API. Providers would not access patient data through their own health app; rather, the data would flow from the payer to the provider's EHR or practice management system, which would allow them to incorporate the patient data into their records. For example, a provider who is preparing for an upcoming appointment may need more information about the patient than is contained in the patient's record. Under this proposal, the provider would be able to request the additional data from the patient's payer, provided the patient has not opted out (as explained in section II.B.3.b. of this proposed rule). The payer would then be required to share the requested data no later than 1 business day after the provider initiates this request.
Finally, unlike the Patient Access API, we propose that the Provider Access API would not include provider remittances and enrollee cost-sharing information. Many payers consider cost-sharing information proprietary, and we believe that information would have limited benefit for treatment or care coordination. We note that our proposals in section II.C. of this proposed rule would exclude provider remittances and enrollee cost-sharing information from the payer to payer data exchange, and we propose the same for the Provider Access API.
In the CMS Interoperability and Patient Access final rule CMS required standards for the Patient Access API by cross reference to 45 CFR 170.215 (85 FR 25558). In this proposed rule, we are proposing to amend these cross references, as discussed in section II.F. We also propose, at the CFR citations listed in Table 2, that the Provider Access API would require adherence to the same technical standards, API documentation requirements, and standards for denial or discontinuation of access to the API. Additionally, we note that unlike for the Patient Access API, we are proposing to require the FHIR Bulk Data Access Implementation Guide at 45 CFR 170.215(a)(4). For a complete discussion of these requirements, we refer readers to the CMS Interoperability and Patient Access final rule (85 FR 25526) and to section II.F. of this proposed rule.
We acknowledge that it could be helpful for all providers to have access to their patients' data regardless of contractual or enrollment relationships with a patient's payer. However, if a provider does not have a provider agreement or is not enrolled (in the case of Medicaid and CHIP FFS programs) with a payer that holds their patient's data, the payer would not be required to provide patient data to that provider under this proposal, though it may be permissible or even required by other law or regulation. We recognize that this could make it more difficult for an out-of-network provider to create a comprehensive care record for a patient. We considered requiring payers to share the data with all providers, regardless of whether the provider is under contract or enrolled with the payer. However, for reasons we explain in this section of this proposed rule, we are not proposing to do so, and are instead seeking comment on various issues surrounding that possible requirement. Though we are not proposing to require it at this time, we encourage payers to share information via API with out-of-network or unenrolled providers who have a verified treatment relationship with the patient, to the extent permitted by law.
There could be privacy, security, and program integrity concerns with requiring payers to share patient information with out-of-network providers. For example, because MA organizations, Medicaid FFS programs, CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities must ensure they do not enroll or contract with providers that are on the HHS Office of the Inspector General List of Excluded Individuals/Entities (LEIE), limiting data sharing through the Provider Access API to in-network or enrolled providers can help ensure these data are not shared with providers who have already been determined by the Federal Government to present fraud or other program integrity risks. Since these risks exist, if we were to require payers to share patient information with out-of-network providers, we would also have to require payers to establish safeguards to ensure that an out-of-network provider would be a trustworthy recipient of patient information. This could create significant burden for payers who may need to expend resources towards vetting providers with whom they do not have an existing relationship.
The LEIE does not apply to QHPs, but in order to offer coverage through the FFEs, they must comply with certification rules per 45 CFR part 156, which includes requirements to prevent QHP issuers from contracting with providers known to submit fraudulent or wasteful claims. For example, § 156.810(a)(7) specifies that a QHP issuer may be decertified if, based on credible evidence, they have committed or participated in fraudulent or abusive activities, including submission of false or fraudulent data. Section 156.340 provides that a QHP issuer is responsible for its own compliance and the compliance of any of its delegated or downstream entities with all applicable Federal standards related to Exchanges. Per § 156.20, “delegated entity” means any party that enters into an agreement with a QHP issuer to
As we consider imposing a requirement to share patient data with out-of-network providers through future rulemaking, we request comment on how payers do so today, the effectiveness of current processes to validate the treatment relationships between patients and providers when a contractual relationship does not exist between the provider and the payer, and what additional program integrity safeguards might be appropriate when other contractual mechanisms are not in place to ensure that patient data are provided only to qualified, trustworthy providers. We are particularly interested in the following questions: How would out-of-network providers request access to their patients' data and demonstrate that the provider has a treatment relationship with the patient? What processes and verification requirements would we need to require each payer to establish to verify the patient-provider treatment relationship? Should payers consider certain provisions in data use or data exchange agreements? If so, what could those provisions address? What are current best practices for terms of service? What other operational best practices for enabling safe data exchange with out-of-network providers should CMS consider in determining whether to propose a policy requiring this?
We emphasize that all data shared and received via this proposed data exchange would still have to be handled in a way that is consistent with all current and applicable laws and regulations, and our proposals are not intended to modify those other laws. Payers and healthcare providers that are covered entities under HIPAA are subject to the HIPAA Rules. Adherence to the HIPAA Rules would ensure that the provider disclosing patient data through the Provider Access API has appropriate security protocols in place.
We are proposing to require, at the CFR citations identified in Table 2, that impacted payers share certain patient information with in-network and enrolled providers who have a treatment relationship with the payers' patients upon request by the provider. Thus, payers would be required by regulation to make such disclosures if there is a treatment relationship with the individual. The HIPAA Privacy Rule permits a covered entity, such as a health plan, to disclose PHI of the enrolled individual to a health care provider without individual authorization for treatment purposes under 45 CFR 164.506(c)(2) or as required by law per 45 CFR 164.512(a)(1).
Our proposal would not alter any obligation for HIPAA-covered entities to follow the HIPAA Rules or other applicable law, including, but not limited to, standards regarding the use and disclosure of PHI, administrative, physical, and technical safeguards and other security provisions, and breach notification. The security framework of the proposed API, as required via reference to standards at 45 CFR 170.215, would allow payers to verify the requesting provider's identity by using the required authorization and authentication protocols. Authorization refers to the process by which the payer would give the provider permission to access data. The authentication protocols are those that would allow the payer to ensure that the provider that is requesting this access is who they say they are. In addition to using these required protocols, the payer would be required to share the specified data only if it can also attribute the patient to the provider using an attribution process, as discussed in this section of this proposed rule in detail. While FHIR itself does not define security-related functions, used in combination with appropriate security controls (such as authentication and access control), a FHIR API can and should be implemented in compliance with the HIPAA Security Rule for secure data exchange.
HIPAA also requires the Secretary to adopt standards for specific transactions and establish a process for updating those standards. A HIPAA transaction is an electronic transmission of information from a covered entity to carry out financial or administrative activities related to health care (for example, when a health care provider sends a claim to a health plan to request payment for medical services) for which the Secretary has adopted a standard. Under HIPAA, HHS is required to adopt standards for electronically transmitting certain health care information, including:
• Health care claims or equivalent encounter information;
• Health care electronic funds transfers and remittance advice;
• Health care claim status;
• Eligibility for a health plan;
• Enrollment and disenrollment in a health plan;
• Referrals certification and authorization;
• Coordination of benefits;
• Health plan premium payments; and
• Medicaid pharmacy subrogation (not mandated under HIPAA, but, consistent with section 1173(a)(1)(B) of the Social Security Act, a standard has been adopted for this purpose).
The Secretary has adopted a HIPAA transaction standard for transmitting claims or equivalent encounter information. Although our proposals would facilitate sharing claims data from payers to providers, the transmission would not be subject to HIPAA transaction standards because the purpose of the exchange would not be to request or issue a payment.
In summary, we propose that beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period 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 implement and maintain a FHIR API to exchange data with providers conformant to the standards discussed in section II.F and at the CFR citations referenced in Table 9. Individual patient data maintained by the payer with a date of service on or after January 1, 2016, must be made available via that API no later than 1 business day after the payer receives a request for data by an in-network provider, (or in the case of a Medicaid or CHIP FFS program, an enrolled Medicaid or CHIP provider).
We are proposing these requirements for the Provider Access API for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities (excluding Non-Emergency Medical Transportation (NEMT) PAHPs, as explained in this section of this proposed rule), and QHP issuers on the FFEs at the CFR sections identified in Table 2.
For Medicaid and CHIP managed care, we propose that NEMT PAHPs, as defined at 42 CFR 438.9(a) and 457.1206(a) respectively, would not be subject to the requirement to establish a Provider Access API. MCOs, PIHPs, and non-NEMT PAHPs would be subject to this proposed rule. We believe that the unique nature and limited scope of the services provided by NEMT PAHPs, in that they only cover transportation and not medical care itself, justify their exclusion from the requirements of the Provider Access API proposed at 42 CFR 431.61(a). Specifically, we do not believe that providers have routine need for NEMT data; therefore, requiring NEMT PAHPs to implement and maintain a Provider Access API would be an undue burden. However, we propose to include NEMT PAHPs in the scope of most of the other requirements of this proposed rule that apply to all other Medicaid managed care plans listed in Table 2.
We request public comment on the proposal for impacted payers to implement and maintain a Provider Access API to provide access to specified patient information.
In general, the proposals discussed in this section regarding the data that payers must make available through the API, as well as the technical specifications, align with the requirements for the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558) and as proposed in section II.A.2. of this rule. We anticipate that this alignment would provide consistency and help payers build on the work done to comply with the requirements for the Patient Access API, outlined previously. Additional proposed requirements for the Provider Access API regarding attribution, patient opt out process, patient resources, and provider resources are discussed in the sections that follow.
Patient attribution is a method of identifying a patient-provider treatment relationship. Attribution is a critical component to ensure that patient health data are shared only with appropriate providers. For the Provider Access API, we are proposing to require that payers develop an attribution process to associate patients with their providers to help ensure that a payer only sends a patient's data to providers who are requesting that data and who have a treatment relationship with that patient.
We are aware that the process of attribution can have many functions for payers, including managing contracts, payments, financial reconciliation, reporting, and continuity of care. In addition, HL7 has developed a member attribution process and workflow in the Da Vinci Member Attribution List FHIR Implementation Guide (IG), which defines various terms and describes a general process by which a payer and provider can coordinate and reconcile their understanding of which patients associated with a particular payer-provider contract.
A payer may implement a process to generate a provider's current patient roster using claims data, and only permit data exchange through the Provider Access API to providers with whom those patients can be attributed via claims data. For example, payers could accept proof of an upcoming appointment to verify the provider-patient treatment relationship. We know that many providers already verify coverage with the payer before a new patient's first appointment. If an in-network provider is seeing a patient for the first time, the provider's practice can send proof of the upcoming appointment to the payer. Once confirmed, this would then allow the provider to request the patient's data in preparation for the appointment. We further note that the Argonaut Project has developed an implementation guide specifying how to use FHIR's Scheduling and Appointment resources to communicate this information.
CMS has implemented an attribution process in our DPC pilot for Medicare beneficiaries, which is the Medicare FFS version of the Provider Access API. The pilot project requires HIPAA-covered entities or their business associates to agree to certain terms of service
Based on feedback from the industry, the HL7 Da Vinci attribution work group has developed a published Member Attribution List IG.
We do not wish to be overly prescriptive about how payers could generate an attribution list for providers, but it would be necessary for payers to establish a process to meet these proposed attribution requirements for the Provider Access API. Because the standards for the attribution process continue to evolve, we are not specifying how payers should identify whether a specific patient can be attributed to the requesting provider. Instead, we encourage the community to continue to collaborate on viable approaches.
We also recognize that impacted payers may already have multiple arrangements in place with providers to support data exchange, and may even participate in community, local, state, or private health information exchanges (HIEs). In many cases, these HIEs include patient attribution capabilities for which payers may already have a process. Once again, our goal is for payers to avoid having to develop multiple approaches to address attribution, and we encourage collaboration on potential solutions.
In summary, we propose 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 maintain a process to associate patients with their in-network or enrolled providers to enable payer to provider data exchange via the Provider Access API.
We are proposing these attribution requirements for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans other than NEMT PAHPs, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 2.
We solicit comments on our proposal to require payers to develop processes for verifying the patient-provider treatment relationship, including any processes that may be in place today.
We are proposing that all impacted payers would be required to establish and maintain a process to allow patients or their personal representatives to opt out of having the patients' data available for providers to access through the Provider Access API. We note that this differs from our Payer-to-Payer API proposal in section II.C.3.c. of this proposed rule, under which all impacted payers would have an opt in process. Similar to the proposed attribution process, as previously discussed, we do not intend to be prescriptive regarding how this opt out process should be implemented, but payers would be required to make this opt out process available, and give all currently enrolled patients or their personal representatives a chance to opt out, before the first date on which patient information is made available via the Provider Access API. Specifically, we are proposing that impacted payers must maintain a process to allow patients or their personal representatives to opt out of data sharing, or if they have already opted out, to opt back in. The process for opting out and opting back in would have to be available before the first date on which patient information is made available via the API and at any time while the patient is enrolled with the payer. We are not proposing to require specific methods for patients to opt out, but anticipate that payers would make that process available by mobile smart device, website, and/or apps. We also anticipate that mail, fax, or telephonic methods may be necessary alternatives for some patients, which payers would have to accommodate if this policy is finalized as proposed. We invite comments on whether we should establish more explicit requirements regarding patient opt out processes.
Our proposal would require payers to allow patients to opt out of the Provider Access API data exchange for all providers in that payer's network. However, we also encourage payers to implement processes that allow more granular controls over the opt out process, so patients can opt out of having data exchanged with individual providers or groups of providers. We are not proposing implementation of such processes as a requirement in this rulemaking, as we are concerned about the potential administrative and technical burden this may place on some payers. However, we request comments about the technical feasibility of implementing an opt out process that would allow patients to make provider-specific opt out decisions, and whether we should consider proposing such a requirement in future rulemaking.
We are proposing an opt out approach because opt in models of data sharing, as we discuss in this section of this rule, have been shown to inhibit the utilization and usefulness of data sharing efforts between patients and healthcare providers. We acknowledge that there are positives and negatives to both opt in and opt out policies, and many patients may prefer to control or direct their health information via an opt in process because opt in policies require affirmative permission from a patient before their data can be shared. However, patients who are less technologically savvy or have lower health literacy may be less likely to use the Patient Access API, so having an opt out policy for the Provider Access API would facilitate sharing data directly with the provider, without requiring intervention by the patient. We believe this would promote the positive impacts of data sharing between and among payers, providers, and patients to support care coordination and improved health outcomes, which could lead to greater health equity. In formulating our proposal, we carefully weighed the issues related to both opt in and opt out policies, especially as they relate to making data available to providers. We believe that a proposal defaulting to share data with providers, unless a patient opts out, appropriately balances the benefits of data sharing with the right of patients to control their health information. As we propose in more
Opt in models can create greater administrative burden for smaller healthcare organizations, depending on where the responsibility for obtaining and updating the patient's data sharing preference is held. We note that smaller hospitals in states with opt in patient permission requirements for HIE are more likely to report regulatory barriers to data exchange compared with those in states with opt out policies, though more technologically advanced hospitals reported no difference.
Within the Department of Veterans Affairs (VA), the Veterans Health Administration, Office of Health Informatics, Veterans Health Information Exchange (VHIE) Program Office, leads interoperability and HIE between VA facilities and private sector providers. Until April 2020, VA operated with an opt in model. Between 2013 and 2017, the VHIE Program Office collected information on the opt in process, and in 2017 reported collecting patient permissions from only 4 percent of the enrolled veterans.
In the December 2020 CMS Interoperability proposed rule, we proposed an opt in patient permission model for the Provider Access API and requested comments on opt in versus opt out approaches. In response, commenters overwhelmingly supported an opt out model and cited clinical and operational hurdles associated with an opt in approach. Support for an opt out approach came from both provider associations and payers, while patient commenters did not oppose such a proposal. We also believe that an opt out model could address equity issues by ensuring that patients from lower socioeconomic and minority groups, who are more likely to have limited health literacy,
This proposed opt out option is specific to the data we are proposing payers be required to share via the Provider Access API. As discussed previously, this proposed rule would not alter any other requirements under applicable privacy and security laws and regulations. If there is other authority to share patient information with respect to which a patient may not opt out, such as disclosures required by law, nothing in this proposal would change the payer's obligation to disclose that information. However, if finalized, we would encourage payers and providers to use the proposed Provider Access API as a technical solution to transmit data between payers and providers beyond the scope of these proposals, provided such disclosure is consistent with all other applicable requirements, such as the HIPAA Rules. We also note that the HIPAA Rules permits health plans to disclose PHI, without an individual's authorization, to providers via the Provider Access API for certain permitted purposes under the HIPAA Rules, such as, for example, treatment, payment, or health care operations
We value the importance of safeguarding the quality and integrity of patient health information. We acknowledge that there may be potential program integrity risks associated with sharing patient data under both an opt in and opt out model. We believe that payers already have program integrity protocols through which they determine if a data exchange has resulted in potential fraud and coordinate investigations of any potential fraud with the relevant programmatic authorities or state laws. We expect that if payers identify any vulnerabilities, they would work to make changes to their operations to address risks that could lead to potential fraud and to limit the impact on patient information.
In summary, we propose 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 must maintain a process for patients or their personal representatives to opt out of and subsequently opt into having the patient's health information available
We are proposing this requirement for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 2.
We request comments on our proposal for a patient opt out framework for the Provider Access API. We additionally request comments on whether patients should be able to exercise more granular controls over which data they permit the payer to share, including permitting the sharing of certain data from only specific timeframes.
To ensure that patients understand the implications of the opt out option for the Provider Access API, we are proposing to require payers to provide information to their patients about the benefits to the patient of the Provider Access API requirements, their opt out rights, and instructions both for opting out of the data exchange and for opting in after previously opting out. Payers would have to provide this information, in non-technical, simple, and easy-to-understand language, at the time of enrollment and annually. Payers would also be required to make this information available at all times, in an easily accessible location on payers' public websites. We are not proposing specific text or format of this information, but we request comments on whether there are benefits or burdens to requiring that this information be provided in a specific format or to include specified content. In particular, we are interested in comments on language regarding how patient data could be used and shared through the API. We anticipate payers would include information about patients' ability to opt out of (and opt back in to) this data sharing in their regular communications, such as annual enrollment information, privacy notices, member handbooks, or newsletters. However, we request comment on the most appropriate and effective communication channel(s) for conveying this information to patients. We also request comment on whether providing this information at the time of enrollment and annually is appropriate, or whether we should require that this information be provided directly to the patient more frequently.
We believe it is important to honor patient privacy preferences, and believe it is important for providers to have access to patient information to be able to provide treatment and coordinate care effectively. We also believe that more informed patients are more empowered patients, which we believe leads to increased engagement with their care and ultimately improved health outcomes. Offering patients educational materials about their right to opt out of data sharing via the proposed Provider Access API is thus fundamental to empowering patients with their data.
In summary, we propose 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 must provide information in non-technical, simple, and easy-to-understand language to their patients about the benefits of API data exchange with their providers, their opt out rights, and instructions both for opting out of data exchange and for opting in after previously opting out. We are proposing that these payers must make this information available to currently enrolled patients before the Provider Access API is operational and shares any of their data. We are proposing that thereafter, payers provide this information at enrollment and at least annually. We are also proposing that this information be available in an easily accessible location on payers' public websites.
We are proposing this requirement for annual information for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 2.
We are proposing to require payers to develop non-technical and easy-to-understand educational resources for providers about the Provider Access API. These educational resources should explain how a provider can request patient data using the payer's Provider Access API. The resources would have to include information about the process for requesting patient data from the payer using the API and how to use the payer's attribution process to associate patients with the provider. We are proposing that impacted payers provide these resources to providers through the payer's website and other appropriate provider communications, such as annual contract updates or handbooks. Non-technical resources would help providers understand how they can use the API to access patient data, thus realizing the expected benefit of the proposed API.
Specifically, we propose 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 provide educational resources in non-technical and easy-to-understand language on their websites and through other appropriate mechanisms for communicating with providers, explaining how a provider may make a request to the payer for patient data using the FHIR API. We also propose that those resources must include information about the mechanism for attributing patients to providers.
We are proposing this requirement for provider resources for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP Issuers on the FFEs at the CFR sections identified in Table 2.
We request comment on this proposal, including whether CMS should develop guidance regarding, or address in future rulemaking the specific content of these educational materials about the Provider Access API.
Should our proposals regarding the Provider Access API be finalized as proposed, we would strongly encourage state Medicaid and CHIP FFS programs to implement the Provider Access API as soon as possible, due to the many anticipated benefits of the API as discussed in this section. However, we also recognize that state Medicaid and CHIP FFS agencies may face certain circumstances that would not apply to other impacted payers. To address these concerns, we are proposing a process through which states may seek an extension of, and, in specific circumstances, an exemption from, the Provider Access API requirements. We propose the following:
At the regulation citations identified in Table 2, we propose to provide state Medicaid FFS and CHIP FFS programs the opportunity to request a one-time
Should the proposal for this API be finalized as proposed, states would be permitted to submit a written application for a one-time, one-year extension as a part of their annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures. The state's request would have to include the following: (1) a narrative justification describing the specific reasons why the state cannot reasonably satisfy the requirement(s) by the compliance date, and why those reasons result from circumstances that are unique to the agency operating the Medicaid and/or CHIP FFS program (versus other types of impacted payers); (2) a report on completed and ongoing state implementation activities that evidence a good faith effort towards compliance; and (3) a comprehensive plan to meet the Provider Access API requirements no later than 1 year after the compliance date.
Under this proposal, CMS would approve an extension if, based on the information provided in the APD, CMS determines that the request adequately establishes a need to delay implementation, and that the state has a comprehensive plan to implement the proposed requirements no later than 1 year after the compliance date. We also solicit comments on whether our proposal would adequately address the unique circumstances that affect states and that might make timely compliance with the proposed API requirement difficult for states.
At the CFR sections identified in Table 2, we propose to permit state Medicaid FFS programs to request an exemption from the Provider Access API requirements when at least 90 percent of the state's Medicaid beneficiaries are enrolled in Medicaid managed care organizations as defined at 42 CFR 438.2. Likewise, we propose that separate CHIP FFS programs could request an exemption from the Provider Access API requirements if at least 90 percent of the state's separate CHIP beneficiaries are enrolled in CHIP managed care entities, as defined at 42 CFR 457.10. In this circumstance, the time and resources that the state would need to expend to implement the Provider Access API requirements for a small FFS population may outweigh the benefits of implementing and maintaining the API. Unlike other impacted payers, state Medicaid and CHIP FFS programs do not have a diversity of plans to balance implementation costs for those plans with low enrollment. If there is low enrollment in a state Medicaid or CHIP FFS program, there is no potential for the technology to be leveraged for additional beneficiaries. States, unlike other payers, do not maintain additional lines of business.
We acknowledge that the proposed exemption could mean that most beneficiaries enrolled with exempted Medicaid or CHIP FFS programs would not receive the full benefits of having this API available to facilitate health information sharing with providers. To address this, we propose that states that are granted an exemption would be expected to implement an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means, to help ensure that Medicaid or CHIP services are provided with reasonable promptness and in a manner consistent with simplicity of administration and in the best interests of those beneficiaries who are served under the FFS program.
We propose that a state could submit a written request for an exemption from the requirements for the Provider Access API as part of its annual APD for MMIS operations expenditures prior to the date by which the state would otherwise need to comply with the requirements (which may be extended by 1 year if the state receives an extension). For Medicaid exemption requests, the state would be required to include documentation that it meets the criteria for the exemption based on enrollment data from the most recent CMS “Medicaid Managed Care Enrollment and Program Characteristics” report. For a CHIP FFS exemption, the state's request would have to include enrollment data from Section 5 of the most recently accepted state submission to the CHIP Annual Report Template System (CARTS). The state would also be required to include in its request information about an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect. CMS would grant the exemption if the state establishes to CMS's satisfaction that it meets the criteria for the exemption and has established such an alternative plan. We note that the same considerations for beneficiary opt out, as previously explained, would still be required.
Once an exemption has been approved, we propose that the exemption would expire if either of the following two scenarios occurs: (1) based on the 3 previous years of available, finalized Medicaid Transformed Medicaid Statistical Information System (T-MSIS) and/or CHIP CARTS managed care and FFS enrollment data, the State's managed care enrollment for 2 of the previous 3 years is below 90 percent; or (2) CMS has approved a State plan amendment,
For the first scenario, CMS recognizes that there may be circumstances where a state's managed care enrollment may fluctuate slightly below the 90 percent threshold in 1 year, and yet return to above 90 percent the next year. To help reduce the possible burden on exempted states experiencing this type of temporary fluctuation in managed care enrollment, CMS would consider data from the 3 previous years of available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data. We propose that if the state's managed care enrollment for 2 of the previous 3 years is below 90 percent, the state's exemption would expire.
We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the Provider Access API exemption when data confirm that there has been a shift from managed care enrollment to FFS enrollment resulting in the State's managed care enrollment falling below the 90 percent threshold for 2 of the previous 3 years. We propose that the written notification be submitted to CMS within 90 days of the finalization of the annual Medicaid T-MSIS managed care enrollment data and/or the CARTS report for CHIP confirming that there has been the requisite shift from managed care enrollment to FFS enrollment in 2 of the 3 previous years.
For the second scenario, we recognize that there may be state plan amendments, waivers, or waiver amendments that would result in a shift from managed care enrollment to FFS enrollment. Additionally, there may be instances where anticipated enrollment shifts may not be fully realized due to other circumstances. We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the Provider Access API when data confirm that there has been a shift from managed care enrollment to FFS enrollment as anticipated in the state plan amendment or waiver approval. We propose that the written notification be submitted to CMS within 90 days of the finalization of the first annual Medicaid T-MSIS managed care enrollment data and/or the CARTS report for CHIP confirming that there has been the requisite shift from managed care enrollment to FFS enrollment.
Regardless of why the exemption expires, if it expires, the state would be required to obtain CMS's approval of a timeline for compliance with the Provider Access API requirements for the state's Medicaid FFS and/or CHIP FFS population(s) within two years of the expiration of the exemption.
For Medicaid and CHIP managed care, we are not proposing an extension process because we believe that managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the existing requirements at 42 CFR parts 438 and 457 and because many of them might benefit from efficiencies resulting from the variety of plan types that they offer. Many managed care plans are part of parent organizations that maintain multiple lines of business, including Medicaid managed care plans and plans sold on the Exchanges. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25607, 25612, and 25620), work done by these organizations can benefit all lines of business and, as such, we do not believe that the proposals in this rule impose undue burden or cannot be achieved by the compliance date. We are soliciting comments on our assumptions regarding the scope of resources and ability of managed care parent organizations to achieve economies of scale when implementing the proposed API.
Further, we seek comment on whether an extension process would be warranted for certain managed care plans to provide additional time for the plan to comply with the proposed requirement at 42 CFR 431.61(a) (which cross references at 42 CFR 438.242(b)(7)) for Medicaid managed care plans) and at proposed 42 CFR 457.731(a) (which cross references at 42 CFR 457.1223(d)) for CHIP managed care entities. While we are not proposing such a process for managed care plans and entities and do not believe one is necessary, we are open to evaluating options for possible future rulemaking. Were we to adopt an extension process for these managed care plans and entities, what criteria should a managed care plan or entity meet to qualify for an extension? Should the criteria include enrollment size, plan type, or certain unique characteristics that could hinder their achievement of the proposed requirements by the proposed compliance date? We also seek comment on whether, were we to propose such a process for Medicaid managed care plans or CHIP managed care entities, the entity responsible for evaluating the criteria and exception evaluation process should be the state and whether states could implement the exception evaluation process with available resources. Consistent with the exception process proposed for QHP issuers on the FFEs at 45 CFR 156.222(c), we would expect managed care plans seeking extensions to provide, at a minimum, a narrative justification describing the reasons why a plan or entity cannot reasonably satisfy the requirements by the proposed compliance date, an explanation of the impact of non-compliance upon enrollees, an explanation of the current or proposed means of providing electronic health information to providers, and a comprehensive plan with a timeline to achieve compliance.
We request comment on the proposed extension and exemption processes.
For QHP issuers on the FFEs, we propose an exception to the Provider Access API proposal at the regulation citations identified in Table 2. We propose that if an issuer applying for QHP certification to be offered through an FFE believes it cannot satisfy the proposed requirements at 45 CFR 156.222(a) for the Provider Access API, the issuer would have to include as part of its QHP application a narrative justification describing the reasons why the issuer could not reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon providers and enrollees, the current or proposed means of providing health information to providers, and solutions and a timeline to achieve compliance with the requirements of this section. We propose that the FFE may grant an exception to the requirements at 45 CFR 156.222(a) for the Provider Access API if it determines that making qualified health plans of such issuer available through such FFE is in the interests of qualified individuals in the state or states in which the FFE operates, and an exception would be warranted to permit the issuer to offer qualified health plans through the FFE. This proposal would be consistent with the exception for QHP issuers on the FFEs we finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule (85 FR 25552). For instance, as noted in that final rule, that exception could apply to small issuers, financially vulnerable issuers, or new entrants to the FFEs that demonstrate that deploying FHIR API technology consistent with the required interoperability standards would pose a significant barrier to the issuer's ability to provide coverage to patients, and not certifying the issuer's QHP or QHPs
In summary, we propose to permit certain impacted payers (state Medicaid and CHIP FFS programs and QHP issuers on the FFEs) to apply for an extension, exemption, or exception, as applicable, from implementing the proposed Provider Access API. We propose that these programs would submit and be granted approval for an extension or exemption as a part of applicable established processes. We propose that submission requirements would include certain documentation identified in the regulatory citations in Table 2.
Should our proposals be finalized as proposed, states operating Medicaid and CHIP programs might be able to access Federal matching funds to support their implementation of the Provider Access API. This proposed API is expected to lead to more efficient administration of the Medicaid and CHIP state plans, consistent with sections 1902(a)(4) and 2101(a) of the Act.
We would not consider state expenditures for implementing this proposal to be attributable to any covered Medicaid item or service within the definition of “medical assistance.” Thus, in Medicaid, CMS would not match these expenditures at the state's regular Federal medical assistance percentage (FMAP). However, were this proposal to be finalized as proposed, Federal financial participation (FFP) under section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper and efficient administration of the Medicaid state plan, might be available for state expenditures related to implementing this proposal for their Medicaid programs. We believe that using the Provider Access API would help the state more efficiently administer its Medicaid program, by ensuring that providers could access data that could improve their ability to render Medicaid services effectively, efficiently, appropriately, and in the best interest of the patient.
States' expenditures to implement these proposed requirements could also be eligible for 90 percent enhanced FFP under section 1903(a)(3)(A)(i) of the Act, if the expenditures can be attributed to the design, development, or installation of mechanized claims processing and information retrieval systems. Additionally, 75 percent enhanced FFP under section 1903(a)(3)(B) of the Act might be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with this proposed requirement.
States can request Medicaid enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act through the APD process described at 45 CFR part 95, subpart F. States are reminded that 42 CFR 433.112(b)(12) and 433.116(c) in part require that any system for which they are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act align with and incorporate the ONC's Health Information Technology standards adopted at 45 CFR part 170, subpart B. The Provider Access API would complement this requirement because the API would further interoperability by using standards adopted by ONC at 45 CFR 170.215.
Similarly, 42 CFR 433.112(b)(13) and 433.116(c) require states to promote sharing, leverage and re-use of Medicaid technologies and systems as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. CMS interprets that requirement to apply to technical documentation associated with a technology or system, such as technical documentation for connecting to a state's APIs. Making the needed technical documentation publicly available so that systems that need to can connect to the APIs proposed in this rule would be required as part of the technical requirements at 42 CFR 431.60(d) for all proposed APIs in this rule, including the Provider Access API.
Separately, for state CHIP agencies, section 2105(c)(2)(A) of the Act and 42 CFR 457.618, limiting administrative costs to no more than 10 percent of a state's total computable expenditures for a fiscal year, would apply to administrative claims for developing the APIs proposed in this rule.
We note that the temporary Medicaid FMAP increase available under section 6008 of the Families First Coronavirus Response Act (Pub. L. 116-127) does not apply to administrative expenditures.
Most states have Medicaid Expansion CHIP programs, in which a state receives Federal funding to expand Medicaid eligibility to optional targeted low-income children that meet the requirements of section 2103 of the Social Security Act. We are proposing at 42 CFR 457.700(c) that for states with Medicaid expansion CHIP programs, the proposals in this rule for Medicaid would apply to those programs rather than our proposals for separate CHIP programs. Functionally, our proposals are the same; however, for clarity, we are making explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 would apply to those programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732.
For MA organizations, we are proposing these Provider Access API requirements under our authority at sections 1856(b)(1) of the Act to promulgate regulations that adopt standards to implement provisions in Part C of Title XVIII of the Act (such as
In implementing section 1852(d)(1)(A) of the Act, we previously adopted a regulation, at 42 CFR 422.112(b), that requires MA organizations to ensure the continuity of care and integration of services through arrangements with providers that include procedures to ensure that the MA organization and the contracted providers have access to the information necessary for effective and continuous patient care. This proposal aligns with, and provides a means for, MA organizations to comply with that existing regulatory requirement. Our proposal for MA organizations to implement and maintain a Provider Access API would facilitate exchanges of information about enrollees that are necessary for effective and continuous patient care, which is consistent with the requirement at section 1852(d)(1)(A) of the Act for continuing the provision of benefits. The Provider Access API proposal, which would support sharing claims, all data classes and data elements included in a content standard adopted at 45 CFR 170.213, as well as prior authorization decisions (sections II.B.2. and II.B.3. of this proposed rule) and a requirement for MA organizations to offer provider educational resources (section II.B.3.d. of this proposed rule), would give providers tools to support continuity of care and care coordination for enrollees. Were a provider able, through a Provider Access API established by an MA organization, to gather information for their patient, the provider could make more informed decisions and coordinate care more effectively. In addition, if a patient moves from one provider to another, the new provider would be able to ensure continuity of care if they are able to access relevant health information for the patient from the MA organization in an efficient and timely way. A Provider Access API could support this; thus, the proposal would carry out and be consistent with the Part C statute.
This proposal would complement and align with MA organization obligations at 42 CFR 422.112(b)(4) by providing a means, through a Provider Access API, for the exchange of information that could support effective and continuous patient care. This API would help MA organizations share information with providers in an effective and efficient way that would help them fulfill program requirements. A Provider Access API could increase the efficiency and simplicity of administration. It could give providers access to a significant amount of their patients' information with limited effort, and it could reduce the amount of time needed during provider visits to establish a patient's prior history, which could introduce efficiencies and improve care. These proposals would also be expected to allow for better access to other providers' prior authorization decisions, which could give a provider a more holistic view of a patient's care and reduce the likelihood of ordering duplicate or misaligned services. Ultimately, we anticipate that sharing patient information would ensure that providers receive patient information in a timely manner and could lead to more appropriate service utilization and higher patient satisfaction. In addition, the proposal that MA organizations make available educational resources and information would increase access to and understanding of this Provider Access API, leading to more efficient use and integration of the API as a means for providers to access patient information. Thus, the proposed Provider Access API would be necessary and appropriate for the MA program and consistent with existing requirements.
Our proposed requirements in this section for Medicaid managed care plans and Medicaid FFS programs fall generally under the authority in the following provisions of the statute:
• Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan;
• Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals; and
• Section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients.
These proposals are authorized under these provisions of the Act because they would help ensure that Medicaid providers can access data that could improve their ability to render Medicaid services effectively, efficiently, and appropriately. The proposals would be expected to help states fulfill their obligations to operate their state plans efficiently and to ensure that Medicaid services are furnished with reasonable promptness and in a manner consistent with the best interest of the recipients.
In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to uses or disclosures of information that are directly connected with the administration of the Medicaid state plan. The implementing regulations for this section of the Act list purposes that CMS has determined are directly connected to Medicaid state plan administration at 42 CFR 431.302 and provide safeguards states must apply to uses and disclosures of beneficiary data at 42 CFR 431.306. CHIP programs are subject to the same requirements through a cross reference at 42 CFR 457.1110(b). Our proposal to require that the data described in this section be shared via the Provider Access API would be consistent with the requirement that states may share these data only for purposes directly connected to the administration of the Medicaid state plan, since this data sharing would be related to providing services for beneficiaries, a purpose listed in § 431.302(c). As mentioned previously, a provider could better manage a patient's total care when they have access to more of that patient's data because the data would provide a more in-depth medical history, enable more informed decision making, and potentially prevent the provision or ordering of duplicative services. More details about how the proposals could be implemented in a manner consistent with state Medicaid and CHIP agencies' requirements under 42 CFR part 431, subpart F, are discussed in section II.B.2.
Proposing to require states to implement a Provider Access API to share data with enrolled Medicaid providers about certain claims, encounter, and clinical data, including data about prior authorization decisions, for a specific individual beneficiary, could improve states' ability to ensure that care and services are provided in a manner consistent with simplicity of
For CHIP, we are proposing these requirements under the authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. We believe this proposed policy could strengthen states' abilities to fulfill these statutory obligations under Title XXI of the Act in a way that would recognize and accommodate the use of electronic information exchange in the healthcare industry today and would facilitate a significant improvement in the delivery of quality healthcare to CHIP beneficiaries.
When providers have access to patient utilization and authorization information from payers or other health IT systems, they can provide higher quality care. Improving the quality of care aligns with section 2101(a) of the Act, which requires states to provide CHIP services in an effective and efficient manner. The more information a provider has to make informed decisions about a patient's care, the more likely it is that patients will receive care that best meets their needs. Additionally, providers could be more effective and efficient in their delivery of CHIP services by having direct access to patient utilization and authorization information. If a provider has information about a patient prior to or at the point of care, the provider will be able to spend more time focused on the patient, rather than on their need to collect information. In addition, the information providers do collect would not be based solely on patient recall. This could save time, improve the quality of care, and increase the total amount of direct care provided to CHIP beneficiaries. When data are standardized, and able to be incorporated directly into the provider's EHR or practice management system, they can be leveraged as needed at the point of care by the provider and also can be used to support coordination across providers and payers. This is inherently more efficient, and ultimately, more cost-effective, as the information does not have to be regularly repackaged and reformatted to be shared or used in a valuable way. As such, the Provider Access API proposals also align with section 2101(a) of the Act in that these proposals could improve coordination between CHIP and other health coverage. For these reasons, we believe this proposal is in the best interest of the beneficiaries and within our long-established statutory authorities.
Finally, the safeguards for applicant and beneficiary information at subpart F of 42 CFR part 431 are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As discussed above for Medicaid, giving CHIP providers access to attributed beneficiary data through the Provider Access API is related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share beneficiary information through the Provider Access API, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306.
For QHP issuers on the FFEs, we are proposing these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates. We believe the benefits would outweigh any additional burdens this might impose on issuers. By using the proposed technologies, patients could experience improved health, payers could see reduced costs of care, and providers could see better compliance with care regimens. We also do not believe that premiums would significantly increase because some of the infrastructure necessary to implement the proposed technology has been completed to comply with the May 2020 Interoperability Rule. Furthermore, QHP issuers on the FFEs might combine investments and staff resources from other programs for implementation efforts, avoiding the need to increase premiums.
We believe that certifying only health plans that make enrollees' health information available to their providers via the Provider Access API is in the interests of enrollees. Giving providers access to their patients' information supplied by QHP issuers on the FFEs would ensure that providers are better positioned to provide enrollees with seamless and coordinated care and help ensure that QHP enrollees on the FFEs are not subject to duplicate testing and procedures, and delays in care and diagnosis. Access to the patient's more complete medical information could also maximize the efficiency of an enrollee's office visits. We encourage SBEs, including SBE-FPs, to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchanges.
Research shows that the more complete a patient's record is and the more data that can be available to healthcare providers at the point of care, the better patient outcomes can be.
In the CMS Interoperability and Patient Access final rule (85 FR 25565), we highlighted numerous benefits for payers to maintain a longitudinal record (that is, long-term) of their current patients' health information. If payers are at the center of the exchange, they can make information available to patients and their providers and can help ensure that a patient's information follows them as they move from provider to provider and payer to payer. In the final rule we finalized a requirement that certain impacted payers would be required to exchange, at a minimum, all data classes and data elements included in a content standard adopted at 45 CFR 170.213 (85 FR 25568) at a patient's request. This policy applied to MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. It did not include Medicaid or CHIP FFS programs. We did not specify an API standard for payer to payer data exchange in that final rule, because, at the time, there were a variety of transmission solutions that payers could employ to meet this requirement. We encouraged impacted payers to consider using a FHIR API consistent with the larger goal of leveraging FHIR APIs to support a number of interoperability use cases for improving patient, provider, and payer access to healthcare data to reduce burden, increase efficiency, and ultimately facilitate better patient care. In addition, we signaled our intent to consider a future requirement to use FHIR APIs for payer to payer data exchange, envisioning the increasing implementation of FHIR APIs for different purposes within the industry.
Since the CMS Interoperability and Patient Access final rule was finalized in May 2020, multiple impacted payers have expressed to CMS that the lack of technical specifications for the payer to payer data exchange requirement in the final rule (85 FR 25565) is creating challenges for implementation. This lack of a standard may lead to differences in implementation across the industry, poor data quality, operational challenges, and increased administrative burden. Differences in implementation approaches may create gaps in patient health information that conflict with the intended goal of interoperable payer to payer data exchange.
In the December 2020 CMS Interoperability proposed rule, we attempted to address these challenges by proposing the use of a FHIR API for the payer to payer data exchange. We also proposed to extend the Payer-to-Payer API policies to Medicaid and CHIP FFS programs. As stated in section I.A. of this proposed rule, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates the feedback we received from stakeholders, including this proposal to address the payer to payer data exchange. We refer readers to the discussion in section I.A. outlining the overarching differences between the two proposed rules.
Moreover, in order to respond to stakeholder concerns about implementing the payer to payer data exchange requirement finalized in the CMS Interoperability and Patient Access final rule, and noting that we did not finalize the proposals outlined in the December 2020 CMS Interoperability proposed rule, we published a
In this proposed rule, we are again proposing to require 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) to implement and maintain a payer to payer data exchange using a FHIR API, but with changes from our proposals in the December 2020 CMS Interoperability proposed rule. We are again proposing that the data exchange take place via a FHIR API at the start of coverage, but we are now taking a different approach to the standards required for the API, as further described in section II.F. of this proposed rule. We are again proposing to establish a patient opt in policy for this data exchange for all impacted payers, for the reasons explained below. Furthermore, we propose to extend the compliance deadline for the Payer-to-Payer API to January 1, 2026.
We note that our payer to payer data exchange proposals discussed below involve transactions and cooperation between payers, which in many cases may include payers that would not be impacted by our proposals. We emphasize that under our proposals, each impacted payer would be responsible only for its own side of the transaction. For instance, if our proposal would require an impacted payer to request patient data from another payer, it would have to do so regardless of whether the other payer is an impacted payer (a status that may or may not be evident to the requesting payer). Similarly, if an impacted payer receives a request for patient data that meets all the proposed requirements, the impacted payer would be required to share those data, regardless of whether the requesting payer is an impacted payer (which, again, may or may not be evident). In this way, non-impacted payers who implement the Payer-to-Payer API and their patients would benefit from the data exchange proposed in this proposed rule.
In this section, we talk about data exchange between payers. When we refer to a patient's new payer, we are referring to the payer that a patient is newly enrolled with and the party responsible for requesting and receiving the patient's data. When we refer to the patient's concurrent payers, we are referring to the parties (two or more) that are providing coverage at the same time and responsible for exchanging data with each other as discussed
We are exploring steps for Medicare FFS to participate in Payer-to-Payer API data exchange with all interested payers and we would encourage other payers that would not be impacted by these proposals, if finalized, to do the same. If our proposals are finalized, we intend to implement the Payer-to-Payer API capability for Medicare FFS in conformance with the requirements for impacted payers, as feasible. We seek comment on whether this could be implemented as proposed for the Medicare FFS program, how we could apply each of these proposals below and if there would be any differences for implementing the Payer-to-Payer API in the Medicare FFS program as a Federal payer. We strongly encourage all payers that would not be subject to the proposed requirements to consider the value of implementing a Payer-to-Payer API as described in this proposal, so that all patients, providers, and payers in the U.S. healthcare system may ultimately experience the benefits of such data exchange.
CMS strongly believes that data exchange among payers is a powerful way to help patients accumulate their data over time and to improve information sharing that would allow patients and providers to have more complete access to health information, which can help to promote better patient care. However, given the concerns raised by stakeholders regarding the lack of technical specification in our final policy, we are now proposing to rescind the payer to payer data exchange policy previously finalized in the CMS Interoperability and Patient Access rule (85 FR 25568) at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi) and (vii) and 45 CFR 156.221(f)(1). We are doing so to prevent industry from developing multiple systems, and to help payers avoid the costs of developing non-standardized, non-API systems, and the challenges associated with those systems. In the following sections, we are proposing a new policy that would, instead, require impacted payers to implement and maintain a Payer-to-Payer API using the FHIR standard, as described later in this section. We anticipate that the proposed use of FHIR APIs would ensure greater uniformity in implementation and ultimately lead to payers having more complete information available to share with patients and providers.
In the CMS Interoperability and Patient Access final rule we finalized a requirement to implement, maintain, and use API technology conformant with 45 CFR 170.215 for the Patient Access API. However we did not require the use of an API or related standards for payer to payer data exchange.
We are now building on the technical standards, base content and vocabulary standards used for the Patient Access API, as finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558), for this proposed Payer-to-Payer API. The degree of overlap between the requirements for the Patient Access API (discussed in section II.A.2. of this proposed rule) and the Provider Access API (discussed in section II.B.2. of this proposed rule) should ease the API development and implementation process for payers.
The Patient Access API would provide the foundation necessary to share all data classes and data elements included in a standard adopted at 45 CFR 170.213, adjudicated claims, and encounter data as well as the patient's prior authorization requests and decisions. Because the same data classes and elements included in the standards in 45 CFR 170.213 and adjudicated claims, and encounter data are already required for the Patient Access API, payers have already formatted these data elements and prepared their systems to share these standardized data via a FHIR API. As a result, we believe payers have already devoted the development resources to stand up a FHIR API infrastructure when they implemented the Patient Access API, which could be adapted for expanded interoperability use cases.
We are also proposing to require the use of certain IGs adopted under 45 CFR 170.215 that are applicable to the Payer-to-Payer API. This includes OpenID Connect Core at 45 CFR 170.215(b) for authorization and authentication. We are proposing that the Payer-to-Payer API must include the authorization and authentication protocols at 45 CFR 170.215(b) to authenticate the identity of the payer requesting access to data through the API. This would create a standardized and trusted method for payers to determine whether the payer who is requesting the data is whom they say they are. We refer readers to section II.F. of this proposed rule for further discussion of the required and recommended standards for the Payer-to-Payer API.
We note that when exchanging data with another payer through the Payer-to-Payer API, payers may find it more efficient to share data for multiple patients at a time. It is likely that impacted payers with a fixed enrollment period would have many patients' data to share at one time, especially if other payers share that enrollment period (such as QHPs offered on an FFE). In such a situation, it could require significant resources and time for payers to send each patient's data individually through an API. The FHIR Bulk Data Access (Flat FHIR) IG for exchanging multiple patients' data at the same time has been adopted by ONC at 45 CFR 170.215(a)(4), which is discussed further in section II.F. of this proposed rule and is a proposed required standard for the Payer-to-Payer API.
In summary, we propose 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 must implement and maintain a Payer-to-Payer API that is compliant with the same technical standards, documentation requirements, and denial or discontinuation policies as our Patient Access API requirements. In addition, we propose that the API must be conformant with the standards at 45 CFR 170.215, including support for FHIR Bulk Data Access and OpenID Connect Core as further discussed in section II.F.
We are proposing these technical specification requirements for the Payer-to-Payer API for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 3.
We request comments on these proposals.
We are proposing to require that impacted payers implement and maintain a FHIR Payer-to-Payer API to
The data we are proposing to include in the API would be consistent with the proposals discussed in sections II.A. (Patient Access API) and II.B. (Provider Access API) of this proposed rule, which would require impacted payers to share the same types of data with patients and providers via those respective FHIR APIs. We also note that much of the data included in this proposal, except for provider remittances, enrollee cost-sharing information and prior authorizations, as discussed below, would also be consistent with the requirements for the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25559). That final rule requires that impacted payers make data available from a date of service of January 1, 2016. Therefore, payers should already be maintaining and making available patient data back to that date. Using the same data content standards across the APIs in this proposed rule would add efficiencies for payers and maximize the value of the work being done to implement APIs, reducing the overall burden for all impacted payers.
We are proposing to exclude provider remittances and enrollee cost-sharing information from Payer-to-Payer API data exchange because that information is often considered proprietary by payers. Therefore, we are not proposing to require payers to exchange those data with each other. While there could be value to patients in having provider remittances and enrollee cost-sharing information available via the Patient Access API, we believe that sharing provider remittances and enrollee cost-sharing information between payers would have only a limited beneficial impact on care. We believe that sharing claims and encounter information without the cost details would complement the data classes and data elements included in a content standard adopted at 45 CFR 170.213, by providing more information about the patient's care history to support care coordination and efficient operation.
When we refer to prior authorizations in the context of payer to payer data exchange, we propose that this would include any pending, active, denied, and expired prior authorization requests or decisions. We refer readers to section II.A. of this proposed rule where prior authorization data content for the APIs in this proposed rule is discussed in further detail. Our proposals in this section for the inclusion of prior authorization data mirror our proposals for prior authorization data in the Patient Access API and Provider Access API. We believe that it would be valuable for payers to make information about prior authorization requests and decisions available via the Payer-to-Payer API, particularly when a patient enrolls with a new payer. Prior authorization is a significant focus of this proposed rule, and information about these requests and decisions could be beneficial to patients, providers, and payers. As noted throughout, this proposed rule does not apply to any prior authorization processes or standards related to any drugs.
Currently, when a patient changes payers, information about prior authorization decisions the previous payer made or was in the process of making, about the patient's ongoing care is inconsistently sent to the new payer. While some payers will make this information available to the new payer upon request, most new payers do not request such information. Instead, most payers with a newly enrolled patient require the treating provider to request a new prior authorization, even for items or services for which a patient had a valid and current prior authorization approval under the previous payer. When this happens, the burden of repeating the prior authorization process with the new payer falls on the provider and patient, which can impede the continuity of care or delay patient care, impacting patient outcomes and complicating care coordination. In addition, it adds burden for payers, who must expend time and effort to review a potentially unnecessary and duplicative prior authorization request.
We discuss prior authorization and our proposals regarding prior authorization processes in more depth in section II.D. of this proposed rule. As part of this Payer-to-Payer API proposal, consistent with the proposals for the Patient Access API in section II.A. and the Provider Access API in section II.B. of this proposed rule, we propose to add prior authorization requests and decisions and related administrative and clinical documentation to the set of data that impacted payers must make available via the Payer-to-Payer API. We propose that this documentation would include 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, and the quantity used to date. Furthermore, as outlined in section II.D., we propose that the specific reason why the request was denied should also be included in the case of a prior authorization denial.
We propose that impacted payers would be required to make information about prior authorizations available via the Payer-to-Payer API for the duration that the authorization is active and, for at least 1 year after the prior authorization's last status change. We note that we are formulating our proposal for at least 1 year after any status change, but this provision would be particularly relevant to denied and expired prior authorizations, to ensure that they would be available for at least a year after expiring or being denied.
While CMS is not proposing at this time to require payers to review, consider, or honor the active prior authorization decision of a patient's former payer, CMS believes payers may gain efficiencies by doing so. In this section, we seek comment on some of the considerations around sharing prior authorization data between payers. Under our payer to payer data exchange proposal, prior authorization information would be included as part of the patient's longitudinal record received from the previous payer. The prior authorization information would thus be available for consideration as part of the patient's historical record. Should a payer consult this information, even to make a prior authorization decision under its own rules, it could, over time, reduce payer, provider, and patient burden, and possibly healthcare costs.
We understand that there is potential for a gap in prior authorization for ongoing services when changing payers, which can be challenging for patients. If a new payer consults the previous payer's prior authorization information, it could mean that the provider might not need to send a new, duplicative request to the new payer and that the new payer might not need to process that new request. Patients might not have to wait for a new prior authorization for an item or service that a provider and previous payer had already determined the patient needs. This could be particularly helpful for patients with chronic conditions and individuals with disabilities, social risk factors, and limited English proficiency who are changing payers. If a new payer reviews and considers the prior authorization decisions of a patient's previous payer, based on information the previous payer already had from the patient's providers, that might reduce
We understand that payers may use different criteria to make prior authorization decisions. The new payer may not have insight into the criteria used by the previous payer, which could understandably make it challenging for the new payer to accept the previous payer's decision. With that in mind, we request comments for possible future rulemaking on whether prior authorizations from a previous payer should be honored by the new payer, and if so, should the prior authorizations be limited to a certain period of time based on the type of prior authorization or patient's medical condition? If so, what should that timeframe be? Should prior authorization from a previous payer be honored in certain instances regarding specific medical conditions? If so, which conditions and for what timeframe?
In summary, we propose 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 must implement and maintain a FHIR Payer-to-Payer API to make available all data classes and data elements included in a content standard adopted at 45 CFR 170.213, claims and encounter data (excluding provider remittances and enrollee cost-sharing information), and prior authorization requests and decisions (and related administrative and clinical documentation) that the payer maintains with a date of service on or after January 1, 2016.
We propose that this would include the status of the prior authorization, the date the prior authorization was approved or denied, the date or circumstance under which the prior authorization ends, the items and services approved, and the quantity used to date. If this information includes prior authorization decisions that are denied, we propose that impacted payers must include specific information about why the denial was made. We propose that impacted payers would be required to make information about prior authorizations available via the Payer-to-Payer API for the duration that the authorization is active and, for at least 1 year after the prior authorization's last status change.
We are proposing these Payer-to-Payer API data content requirements for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 3.
We request comment on these proposals.
We propose that all impacted payers must develop and maintain processes to identify a patient's previous and/or concurrent payer(s) and to allow patients or their personal representatives to opt into payer to payer data exchange (both with previous and concurrent payers) prior to the start of coverage. Payers would also need similar processes for current enrollees who are continuing enrollment with their same payer to ensure those patients have the ability to opt in prior to the data being shared through the API.
Concurrent coverage means that an individual has coverage provided by two or more payers at the same time. This could include, for example, individuals dually eligible for Medicare and Medicaid who are enrolled in both an MA plan and a Medicaid managed care plan. Another example of concurrent coverage is when different services are covered by different Medicaid managed care plans for the same Medicaid beneficiary.
We use the term “start of coverage” in this section to mean when coverage begins or when the patient enrolls and benefits become effective. We note that in some cases a payer may provide coverage retroactively; that is, a payer that provides coverage starting on a date prior to enrollment (as happens in Medicaid, for example). In that case, the payer would be required to have processes to collect permission for Payer-to-Payer API data exchange and to identify a new patient's previous and/or concurrent payer(s) prior to the date the patient's enrollment is processed. In Medicaid, this would be the date the beneficiary is enrolled in the state's MMIS (or equivalent process), not the date coverage takes retroactive effect.
We emphasize that obtaining a patient's opt in permission and identifying the previous and/or concurrent payer(s) cannot delay an applicant's eligibility determination or start of coverage with any impacted payer. We note that the proposed requirement to identify a patient's previous and/or concurrent payer(s) and obtain a patient's opt in permission will not always be feasible before the start of coverage, for instance, if a patient does not provide enough information to identify their previous payer. We emphasize that payers must begin this process before the start of coverage, but it may take longer than enrollment. In that case, the impacted payer would be required to continue to engage with the patient to gather their permission and identify any previous and/or concurrent payer(s). Only once the impacted payer has received permission and identified those other payers would they be required to request patient data, as outlined below. Using Medicaid as an example, if a state has all of the information necessary to determine an individual's eligibility before it has identified the previous payer, the state must determine the individual's eligibility and enroll the individual in Medicaid coverage, if determined eligible, while continuing to follow the proposed Payer-to-Payer API requirements outlined here as expeditiously as possible post-enrollment.
We propose that payers would be required to gather information about the patient's previous and/or concurrent payer(s) that would allow them to identify and request data from those payers. This could include the payer's name and a patient ID number or similar identifier. An impacted payer would be required to allow a patient to report multiple previous and/or concurrent payers if they had (or continue to have) concurrent coverage. If that is the case, under our proposals, impacted payers would be required to request the patient's data from all previous and/or concurrent payers. We are not being prescriptive in these proposals regarding specific information to be gathered from patients, as we believe that this requirement can be implemented in multiple ways. However, we expect that payers would only collect as much information as necessary to identify the previous and/or concurrent payer(s) and make a successful request in accordance with our proposals, if finalized. For instance, we do not believe specific plan information (as opposed to the payer organization name) or dates of coverage would be necessary to effectuate our proposals. We believe that requesting additional information from patients beyond that which is necessary would impose barriers on patients' ability to take advantage of our proposed policies
We request comments on which data elements would be necessary or extraneous to make that Payer-to-Payer API request.
Patients enrolled in ongoing coverage on the compliance date with an impacted payer should be given the same opportunity to have their data shared with their current, ongoing payer by previous and/or concurrent payers. To do so, impacted payers would have to give currently-enrolled patients notice and the opportunity to provide their previous and/or concurrent payer(s) information, as well as to opt in to the proposed payer to payer data exchange. Therefore, we are proposing that no later than the compliance date for the Payer-to-Payer API, impacted payers must establish and maintain a process to gather permission and identify previous and/or concurrent payer(s) from all patients who are currently enrolled.
Some payers may want to have a soft launch, rolling implementation or pilot for their Payer-to-Payer API before the proposed compliance date. We want to allow that option and therefore are tying our proposal to require payers to gather permission from currently-enrolled patients to the proposed compliance date, 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), rather than when a payer implements their API. That would allow payers to sequentially target specific plans, populations or enrollee categories for operational rollout, as long as all currently-enrolled patients are given the opportunity to opt in to payer to payer data exchange by that compliance date.
For new patients enrolling on or after the compliance date, we are proposing to require impacted payers to maintain a process for patients to opt in to the Payer-to-Payer API data exchange and to identify their previous and/or concurrent payer(s) prior to the start of their coverage. Below, in section II.C.4.b., we discuss the possible incorporation of these proposed requirements into state applications for Medicaid or CHIP eligibility. Making this process available to patients during the enrollment process, or immediately thereafter, would allow the proposed data exchange to take place as quickly as possible once the patient is enrolled with the new payer. For example, where there may not be communication during the enrollment process such as during the QHP enrollment on the FFE, this process should be done immediately following enrollment. We solicit comment on incorporation of the proposed requirements into the FFE QHP enrollment process as described at 45 CFR 156.265. In addition, 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.
We are proposing an opt in approach for the data exchange through the Payer-to-Payer API for the reasons discussed below, even though, as discussed in section II.B.3.b. of this proposed rule, we believe that an opt out approach to patient data exchange generally would promote the positive impacts of data sharing to support care coordination and improved health outcomes, which could lead to greater health equity. Furthermore, systems with opt in patient permission requirements are more likely to report regulatory barriers to data exchange compared to those without. However, for a variety of legal and operational reasons, we are proposing an opt in permission policy for our payer to payer data exchange proposal. An opt in framework means that the patient or their personal representative would need to affirmatively permit the payer to share data within the proposed Payer-to-Payer API framework discussed in this section, and without that permission, the payer may not engage in the payer to payer data exchange for that patient. We note that this permission (or lack thereof) would only apply to the data exchange proposals discussed here and not to any other obligations under HIPAA or other law.
Certain operational considerations support an opt in framework for this API. As discussed, to request a patient's data from their previous and/or concurrent payer(s), a new payer must identify those payers by gathering information from the patient. While there may be other ways for payers to collect this information, we believe that patients themselves are the best source for sufficient and accurate information necessary for the payer to make the request. Patients would not be required to provide this information. However, should they choose to, providing this information would require an affirmative act from the patient, so we believe that the burden of asking a patient to opt in would not create a significant additional barrier to patient participation.
In contrast, our proposed policy for the Provider Access API would allow payers to exchange patient data with providers unless a patient has opted out. We are proposing an opt out policy for the Provider Access API, in part, based on the existence of a treatment relationship between the patient and provider, a contractual relationship between the payer and the provider, and a coverage relationship between the payer and patient. Specifically, our proposals to require the Provider Access API data exchange only with providers in the payer's network and require a process to attribute a patient to that provider before data can be exchanged creates a level of assurance for the payer that it is sending patient data to an appropriate party. In contrast, two payers exchanging information do not have a direct relationship but would be exchanging data based on a patient's separate relationship with each payer. Therefore, it may make sense for the patient to have a larger gatekeeping role within this proposed policy.
Furthermore, specific statutory and regulatory requirements applicable to state Medicaid and CHIP programs would prevent those programs from establishing an opt out process, or from sharing information with other payers on the basis of a patient's failure to opt out of the other payer's data exchange. Specifically, 42 CFR 431.306(d), a regulation implementing section 1902(a)(7) of the Act, prohibits Medicaid programs from sharing beneficiary information with outside sources before obtaining permission to do so from the individual or family, with limited exceptions. This regulation also applies to CHIP programs under 42 CFR 457.1110(b). This regulation does not conflict with the proposed opt out policy for the Provider Access API because Medicaid and CHIP enrolled providers are not outside sources. However, other payers would typically be outside sources and thus, the regulation would apply to the data shared through the Payer-to-Payer API. For further discussion of data exchange between state Medicaid or CHIP agencies and managed care entities, see section II.C.4.b. below.
Additionally, we are proposing that the requesting payer would obtain the permission of the patient for this data exchange, not a Medicaid or CHIP program that would be sharing the data. Accordingly, the payer requesting the data would also need to follow the permission requirements applicable to Medicaid and CHIP programs so that the Medicaid and CHIP programs could share information through this API in a manner that is consistent with 42 CFR 431.306(d). Rather than creating different permission rules for different payers, which would add significant complexity to the payer to payer data
We request comments on our proposal for an opt in process for gathering patients' permission for payer to payer data exchange. Is there any way, such as through any regulatory changes that we should consider, either in this rulemaking or in the future, that would instead allow for an opt out process while protecting patient privacy in accordance with the considerations above? Are there any policy approaches or technical requirements that could provide all impacted payers with the assurance that they have gathered appropriate permission from patients within the statutory and regulatory framework outlined here? Are there any barriers to interoperability with an opt in approach for patient data exchange for all impacted payers that we are not considering?
We emphasize that all data maintained, used, shared, or received via this proposed Payer-to-Payer API must be maintained, used, shared, or received in a way that is consistent with all applicable laws and regulations. For example, the HIPAA Privacy Rule does not require a covered entity, such as a health plan, to obtain authorization from the enrolled individual or provide an opportunity for the individual to agree or object, in order to share PHI under 45 CFR 164.512(a)(1)
In summary, we propose 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 must maintain a process to identify a new patient's previous and/or concurrent payer(s) to facilitate data exchange using the Payer-to-Payer API. As part of this process, impacted payers would be required to allow a patient to report multiple previous and/or concurrent payers if they had (or continue to have) concurrent coverage. If a patient does report multiple previous payers, impacted payers would be required to request that patient's data from all previous and/or concurrent payers.
Furthermore we propose that, prior to the start of coverage, impacted payers must establish and maintain a process to gather patient permission for payer to payer data exchange, as described in this section. That permission process would have to use an opt in framework whereby a patient or personal representative must affirmatively agree to allow that data exchange. In addition, we propose that impacted payers must have a process for patients to opt into this data exchange at any time, after the start of coverage, or, if they have already opted in, to opt back out, at any time.
Finally, we propose to require impacted payers to establish and maintain a process to gather permission and previous and/or concurrent payer(s) information from patients who are currently enrolled on the Payer-to-Payer API compliance date. For new patients enrolling on or after that date, we are proposing to require impacted payers to maintain a process for patients to provide previous payer information and opt in to the Payer-to-Payer API data exchange prior to the start of coverage.
We are proposing the permission and previous and/or concurrent payer identification requirements for the Payer-to-Payer API for MA organizations, state Medicaid and CHIP agencies, and QHP issuers on the FFEs at the CFR sections identified in Table 3.
We request comment on these proposals.
We are proposing to require impacted payers to request a patient's data from their previous and/or concurrent payer(s) no later than 1 week after the start of coverage. We believe 1 week is sufficient time to allow payers to complete their process for identifying patients' previous and/or concurrent coverage and to initiate this request for data from the other payer(s). If after the start of coverage a patient opts in to the data exchange or provides previous and/or concurrent payer information, or requests data exchange for another reason, we propose that the current payer would be required to request data from the previous and/or concurrent payer(s) no later than 1 week after the payer has the necessary permission and information, or the patient makes the request. We acknowledge that the obligation is contingent on the patient supplying the necessary information about a previous and/or concurrent payer to enable the new payer to conduct the required exchange. An impacted payer cannot comply with these requirements if the patient has not provided timely or accurate information about their previous and/or concurrent payer. This applies throughout the proposals in this section of the proposed rule.
Other than in the context of concurrent payers, we generally expect our proposal to be a one-time data exchange between a previous and new payer. Once the new payer has received the patient's data, we do not expect there to be additional information added to the patient record from the previous payer. However, we want to allow patients to request subsequent data exchange to account for any outlier situations. We are also aware that claims take time to process and may be processed after patients have transitioned to a new payer, thus creating additional data within the patient's record for some time period after the patient has transitioned payers. We considered proposing a policy where, if the patient permits, previous payers would be required to send any additional data within the required dataset to the new payer within 1 week of receiving additional data. However, keeping in mind the frequency and burden this could impose on payers, we seek comment on whether such a policy would be beneficial or overly burdensome. Would additional data be helpful for the new payer for weeks or months after enrollment? Would
We propose that impacted payers would be required to use the OpenID Connect authorization and authentication protocols at 45 CFR 170.215(b) to authenticate the identity of the requesting payer. Like our proposal for the Provider Access API, discussed in section II.B.2., to protect patient data, we want to ensure payers do not send data unless they are confident that the requesting payer is who it says it is. Because these are the same authorization and authentication protocols that are proposed for Patient Access and Provider Access APIs, we believe that payers are already familiar with this requirement for implementation.
To assure the payer receiving the request, we propose to require the requesting payer to include an attestation with the request for data affirming that the patient has enrolled with the requesting payer and has opted in to the data exchange in a manner that meets the necessary legal requirements. As explained in section II.F., we recommend the use of certain HL7 implementation guides to support the exchange of data between impacted payers for the Payer-to-Payer API. The HL7 PDex IG has been developed to ensure that both the technical and business processes of capturing and sharing a patient's permission for data exchange preferences are included in the payer to payer data request. Therefore, using the PDex IG would meet the requirements of this proposal. Because that IG is recommended and not required, impacted payers could also exchange an attestation regarding patient permission with other implementations that meet or exceed the requirements of the PDex IG.
We propose that the previous and/or concurrent payer, if an impacted payer, would be required to respond to a current payer's request, if it meets the requirements, within 1 business day of receipt. We believe 1 business day is the appropriate timeframe to complete this process to send the data, as payers need timely access to previous and/or concurrent payer data to facilitate care coordination and create a longitudinal record that could be helpful to the patient should they wish to access their information for care planning with any new provider(s) they may see. We note that this timeframe also would align with the 1 business day response time for the Patient Access API and proposed Provider Access API.
We seek comment on whether the proposed timeframes for a new payer to request patient data, and for the previous and/or concurrent payer to send these data, are appropriate or whether other timeframes would better balance the benefits and burdens. We seek comment on whether payers could accommodate a shorter period for the data request at the start of coverage, such as 1 to 3 business days, and whether payers need more than 1 business day to respond to a request. If so, what is a more appropriate timeframe for payers to respond to data requests? We believe it is important for patient data to move to the new payer as soon as possible to compile a longitudinal record, as well as obtain information on active prior authorizations.
We note that if a previous and/or concurrent payer is not an impacted payer, they would not be subject to our proposed requirements and, therefore would not be required to send data through the Payer-to-Payer API under this proposal. For example, when a patient moves from a QHP on an FFE to an employer-based plan, the employer-based plan would not be impacted by this rulemaking. The new impacted payer would not be obligated to determine whether the previous payer is an impacted payer under this proposed rule. Therefore, an impacted new payer would be required to request the data from the patient's previous and/or concurrent payer, regardless of whether the other payer is an impacted payer or not. If the previous and/or concurrent payer is not an impacted payer, they would not be subject to our proposed requirements to respond to the request. Conversely, we propose that if an impacted payer receives an appropriate request for patient data under this proposal, they would be required to respond by sending all required data under this proposal, regardless of whether the requesting payer is or is not an impacted payer (which they payer may or may not know).
In summary, we propose 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 must request the appropriate data, as described earlier in this section, from any previous and/or concurrent payers through the Payer-to-Payer API, provided that the patient has permitted the data exchange as proposed in section II.C.3.c. We propose that impacted payers would be required to include an attestation with the request for data affirming that the patient has enrolled with that requesting payer and has opted in to the data exchange. We propose that impacted payers must request these data from any previous payer(s) no later than 1 week after the start of coverage or after a patient's request. If a patient who did not opt in or provide previous payer information subsequently opts in to the payer to payer data exchange and shares that previous payer information, we are proposing that the impacted payer would be required to request the patient's data from the patient's previous payer no later than 1 week after the patient opts in or provides that information.
We propose that if an impacted payer receives a request from another payer to make data available for former patients who have enrolled with the new payer or a current patient who has concurrent coverage, the impacted payer must respond by making the required data available via the Payer-to-Payer API within 1 business day of receiving the request if the requesting payer has been authenticated according to the requirements of 45 CFR 170.215(b), demonstrated that the patient has permitted the data exchange through an opt in process with the requesting payer, and disclosure of the data is not prohibited by law.
We are proposing these payer to payer data exchange timeframe requirements for MA organizations, state Medicaid and CHIP FFS agencies, and QHP issuers on the FFEs at the CFR sections identified in Table 3.
We request comment on these proposals.
For individuals who have concurrent coverage with multiple payers, we propose to require impacted payers to collect information about any concurrent payer(s) from patients before
Specifically, we are proposing to require impacted payers, within 1 week of the start of a patient's coverage, to exchange data with any concurrent payers that the patient reports. Additionally, we propose that should an impacted payer receive a request for a current patient's data from a known concurrent payer for that patient, the receiving payer must respond with the appropriate data within 1 business day of receiving the request. Operationally, this proposed exchange would function the same as the data exchange with a patient's previous payer.
Because all payers will update patient records during the period when a patient is enrolled with those payers, we propose that when a patient has concurrent coverage with two or more payers, the impacted payers must exchange the patient's data available to every other concurrent payer at least quarterly. This proposal would create requirements for impacted payers to both request patients' data from other concurrent payers and to respond to requests from other payers to share patients' data.
Some patients may be concurrently enrolled with payers that would not be subject to our proposed requirements because they are not impacted payers. As discussed above, if a non-impacted concurrent payer does not have the capability or refuses to exchange the required data with an impacted concurrent payer through a FHIR API, the impacted payer is not required to exchange data with that non-impacted payer under this proposal and would not be required to continue to request data exchange quarterly. However, we encourage all payers to implement a Payer-to-Payer API to support data exchange with concurrent payers, even if they are not subject to our proposed requirements. We expect that this data exchange among concurrent payers would support better care coordination and more efficient operations. If a non-impacted payer requests data in conformance with the proposed requirements of this section via an API that meets the requirements proposed for the Payer-to-Payer API, an impacted payer would be required to respond, as if the requesting payer were subject to the rule. As explained above, impacted payers would not need to spend resources determining whether other payers are impacted by these proposals, but would be required to request patient data and respond to all requests that are made within the requirements of this proposed rule.
We also considered whether to propose more frequent exchange (weekly or monthly), or less frequent exchange (semi-annually or annually); however, we believe a quarterly data exchange would strike the right balance between providing accurate, timely data and payer burden. CMS believes sharing data quarterly would be frequent enough to allow time for new health data to accumulate and still be timely, but not so frequently that it causes unnecessary burden on the payers required to provide the information. We request comment on this proposal, including on the appropriate frequency for this payer to payer exchange for patients with concurrent coverage.
We note that when a patient has concurrent coverage, the payers must often communicate regularly to ensure that the proper payer is responsible for that patient's claims. Nothing in this proposed rule, including a patient not opting in to the Payer-to-Payer API data exchange, is intended to alter payers' ability to exchange data as they do today for that purpose, in accordance with applicable law.
In summary, we propose 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, within 1 week of the start of a new patient's coverage, to request initial data exchange from any concurrent payers that the patient reports, and thereafter to request data exchange with those payers no less frequently than once per calendar quarter. We propose that should an impacted payer receive a request for a current patient's data from that patient's concurrent payer, the receiving payer must respond with the appropriate data within 1 business day of receiving the request. Impacted payers would be required to exchange the same data proposed in section II.C.3.b.
We are proposing these requirements for concurrent coverage data exchange for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 3.
We request comment on these proposals.
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. In this way, a patient's cumulative record would follow them between payers and be available to them and their providers. While this proposal would not obligate payers to review, utilize, update, validate, or correct data received from another payer, we encourage impacted payers to do so, at least to the extent doing so might benefit the patient's ongoing care. As previously explained in the CMS Interoperability and Patient Access final rule for the payer to payer data exchange (85 FR 25568), 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. Regardless, all data maintained, used, shared, or received via the proposed Payer-to-Payer API would be required to be maintained, used, shared, or received in a way that is consistent with all applicable laws and regulations.
We note that our proposals would not impact any payer's data retention requirements. Specifically, we are not proposing to require impacted payers to maintain data for unenrolled patients any longer or differently than they do today under current law, regulation, or policy. We understand that if a patient is uninsured or moves to a non-impacted payer that does not request information from the previous payer, after a period of time, the old payer may discard information, which would make it unavailable to the patient or other payers in the future.
However, we believe that imposing requirements that would require payers to alter their data retention policies based on the actions of other payers
In summary, we propose 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), any information received by an impacted payer through this data exchange must be incorporated into the patient's record with the new payer.
We are proposing this requirement regarding data incorporation for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 3.
Consistent with our proposals for the Provider Access API, impacted payers would be required to provide patients with educational materials in non-technical, simple, and easy-to-understand language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw a previous opt in decision, and instructions for doing so. Impacted payers would be required to provide these educational materials to patients at or before requesting permission for the Payer-to-Payer API data exchange. As discussed above, currently enrolled patients must be given the opportunity to opt in to payer to payer data exchange and to provide previous and/or concurrent payer information before the API compliance date. Our proposal would require impacted payers to provide these educational materials to those currently enrolled patients at or before requesting their opt in as well. In addition, similar materials would have to be provided annually to all covered patients in mechanisms that the payer regularly uses to communicate with patients. This information would also be required to be provided in an easily accessible location on the payer's public website. We request comment on whether it would reduce payers' burden to only be required to provide these materials annually to any patients who have not opted in and those with known concurrent payers.
We propose that impacted payers would have to provide educational materials regarding the payer to payer data exchange to all patients at or before requesting opt in and at least annually 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).
We are proposing these patient education requirements for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 3.
We did not require state Medicaid and CHIP FFS programs to comply with the payer to payer data exchange policies in the CMS Interoperability and Patient Access final rule (85 FR 25568). State Medicaid and CHIP FFS programs can face unique circumstances that might make it more challenging for them to meet new requirements within the same timeframe as other payers because of state budget cycles and other funding constraints, possible state legislation or regulatory requirements, contracting timeframes, required systems upgrades, and recruiting necessary staff resources. As a result, in our first phase of interoperability policies in the CMS Interoperability and Patient Access final rule (85 FR 25524), we chose to limit the burden on these programs so they could focus their attention and resources on implementing the Patient Access and Provider Directory APIs and did not make the Payer-to-Payer API policies in that rule applicable to state Medicaid and CHIP FFS programs. However, in August 2020, CMS released a letter to state health officials in which we encouraged state Medicaid and CHIP FFS programs to accommodate payer to payer data exchange requests from beneficiaries.
We are now proposing to make the proposed payer to payer data exchange policies in this proposed rule applicable to state Medicaid and CHIP FFS programs. We believe that proposing to require Medicaid and CHIP FFS programs to implement the Payer-to-Payer API data exchange policies in this proposed rule would not be as burdensome as proposing to require them to follow the non-API-based payer to payer data exchange policies that were finalized in the CMS Interoperability and Patient Access final rule (85 FR 25524) and that we are proposing to withdraw in this proposed rule. That is because this new API would be leveraging the same data and technical standards as the Patient Access API. State programs should have already implemented their Patient Access APIs and should thus be able to leverage the work done for that API to make implementing this newly proposed API more manageable.
For state Medicaid and CHIP FFS programs, the state agency is the impacted payer that would share patient data with other impacted payers. As we discuss in more detail in section II.C.3.a. of this proposed rule, using the Payer-to-Payer API could create efficiencies for state Medicaid and CHIP programs, thereby reducing burden for these programs, and potentially leading to better coordinated patient care and improved health outcomes. We expect the proposed Payer-to-Payer API requirement to lead to more effective administration of the state plan, and to better enable Medicaid and CHIP programs to ensure care and services are provided in a manner that is consistent with their beneficiaries' best interests. Ensuring that patient data can follow Medicaid and CHIP beneficiaries as they enter these programs could potentially lead to better care coordination and continuity of care for these patients. It could also reduce burden for patients and providers. The Medicaid and CHIP FFS programs would have additional information from other payers to share via the Patient Access API and the Provider Access API. As a result, Medicaid and CHIP beneficiaries would have more readily available information to support informed decision-making, and Medicaid and CHIP providers would have more information about the care their patients are receiving. This could potentially lead to fewer duplicate tests or less time taken collecting and recollecting information about the patient during a visit. Any effort a state Medicaid or CHIP FFS program takes to evaluate the data from a patient's previous or concurrent payers could potentially allow the program to avoid wasteful, unnecessary, or duplicative action. In this way,
If this proposal is finalized to include state Medicaid and CHIP FFS programs, patients would continue to have access to their health information, creating a longitudinal record, as they move into and out of Medicaid or CHIP FFS. A broader range of information about patients' past care might also be able to follow them to new providers if payers have greater access to data from other payers and can make it available through the Patient Access and Provider Access APIs proposed in this proposed rule.
We know that state Medicaid or CHIP agencies regularly exchange data with their managed care plans. This Payer-to-Payer API proposal would not affect the Medicaid and CHIP programs' ability to share data as they do today. Specifically, Medicaid agencies and their contracted managed care plans may, and in some cases are required to,
As mentioned above, Medicaid managed care plans and CHIP managed care entities are not outside sources, but are part of a state's Medicaid and/or CHIP programs as a whole. Therefore, we do not wish to impose a policy that would require an opt in for patients for state Medicaid and CHIP agencies and their managed care entities to exchange information, as they may do today. Current consent rules and requirements for exchange within a state's Medicaid and CHIP programs (such as between a managed care plan and the state Medicaid or CHIP agency or between two managed care plans contracted with the state Medicaid or CHIP agency), are not affected by our proposals. There is no requirement for a state Medicaid or CHIP agency to obtain an opt in from an individual or family member prior to providing information about a Medicaid or CHIP beneficiary to its own providers or plans, as such entities would not be an outside source as described at 42 CFR 431.306(d) (and as discussed in section II.B., related to our Provider Access API proposals). We do not intend any of our proposals to interfere with or affect this permissible information exchange. Hence, we are proposing that if a Medicaid or CHIP agency is exchanging information per our Payer-to-Payer API proposals with a managed care plan or managed care entity with which they have a contract, the requirement to obtain patient opt in would not apply. The other proposed payer to payer requirements, such as the requirement to use a FHIR API and the authorization and authentication protocols would apply. The exchange must also not be prohibited by law.
We welcome comments, specifically from states and contracted managed care entities, as to how we can establish standards for patient data exchange between state Medicaid and CHIP agencies and their contracted managed care entities without creating additional barriers or burden.
We are proposing that Medicaid and CHIP agencies, like all impacted payers, implement a process to allow currently enrolled beneficiaries a chance to opt in to payer to payer data exchange prior to the State Medicaid or CHIP agency's Payer-to-Payer API compliance date, and prior to the enrollment of new beneficiaries after that date. The opportunity for newly enrolling patients to opt in could take place through the application, or at some later point of contact with the beneficiary prior to the start of coverage, but in no instance would our proposals permit a delay in the enrollment process or a beneficiary's coverage. As discussed above, 42 CFR 431.306 lists certain requirements for sharing beneficiary data. We note that when an individual's Medicaid or CHIP enrollment has ended and another payer is requesting a former Medicaid beneficiary's information, receiving an attestation from a requesting payer that the patient has opted in to data exchange with the requesting payer, consistent with our proposals for all payers, is a permissible way for the state Medicaid or CHIP agency to obtain permission as required under 42 CFR 431.306(d). We are proposing these requirements at the CFR citations in Table 3.
States are also reminded that access to information concerning beneficiaries must be restricted to persons and agencies who are subject to standards of confidentiality that are comparable to that of the Medicaid agency, in accordance with 42 CFR 431.306(b). We do not believe that any of the other requirements of 42 CFR 431.306 are relevant because they cover data release and use in contexts outside of our proposals in this section.
We are specifically proposing that state Medicaid and CHIP agencies, rather than their managed care plans, would be responsible for obtaining the required permission. A Medicaid or CHIP beneficiary may switch between FFS and managed care delivery systems within the same state's Medicaid or CHIP program, but despite these shifts, an eligible beneficiary remains a beneficiary of the state program. States may also change the managed care plans that they contract with. Thus, the patient permission to this data exchange, as a Medicaid or CHIP beneficiary, should be obtained by the state and would apply regardless of the delivery system in which the beneficiary is enrolled. We believe that the state is the appropriate custodian of the patient's permission record, rather than the particular managed care plan or managed care entity through which a patient receives care. We understand that this would require state Medicaid and CHIP agencies to create new processes to share a patient's opt in preference with their managed care plans and managed care entities.
We considered proposing that the Payer-to-Payer API requirements would not apply for beneficiaries moving between or with concurrent coverage with a state Medicaid or CHIP agency and a contracted managed care entity for the reasons outlined above. However, we are concerned that many states today do not exchange data between their Medicaid or CHIP FFS programs and managed care. We request comments on whether there are other ways we can ensure patient data is exchanged in this case in a manner that would reduce burden on states.
We are also proposing that the requirement to identify patients' previous and/or concurrent payers apply to state Medicaid and CHIP agencies rather than managed care plans or managed care entities. For the reasons described above, we believe that having the state maintain that record would allow that information to be retained regardless of any changes to the
Furthermore, we understand that in many states, managed care plans may not have any contact with patients prior to their enrollment in the Medicaid or CHIP managed care plan. We believe the ideal time to allow patients to opt into payer to payer data exchange is during their application for Medicaid or CHIP. However, per 42 CFR 435.907(e)(1), states may only require information from an applicant that is necessary to make an eligibility determination. This means that while an applicant may be asked to provide their permission for the data exchange, they may not be required to respond to the question as a condition of submitting the application. Because we expect higher rates of patients providing permission when they are presented with the option at a time when they are already engaged in providing information (such as at application or plan selection), we highly encourage states to leverage any touchpoints before patients are enrolled in FFS or a managed care plan rather than expecting patients to submit permission in a separate process.
We understand that making changes to applications can be a significant administrative process and there may be other places where a state could obtain a patient's data exchange preference for the Payer-to-Payer API data exchange. For instance, a state could leverage an online portal or app, if beneficiaries frequently use those pathways for other purposes, such as reporting a change in circumstance or providing information for eligibility renewal. However, the option should be equally available for all beneficiaries and if only a small portion of the Medicaid population uses these tools to communicate with the Medicaid agency, that subset would be self-selected for greater technology literacy and taking this approach could exacerbate inequality.
We note that the single streamlined application, which for Medicaid purposes is described at 42 CFR 435.907(b)(1) and is also used for applications through the FFEs, includes questions about concurrent coverage information. We also expect that some states that do not use the single streamlined application already ask for this information for Coordination of Benefits and Third-Party Liability purposes. We believe that it would generally make sense to gather permission for payer to payer data exchange with that concurrent payer at that point. Furthermore, the patient permission provisions in this proposal would apply only to the payer to payer data exchange discussed here and would not affect states' ability to perform Coordination of Benefits or Third-Party Liability activities as they do today.
We request comment on the workflow and data exchanges that occur when a Medicaid or CHIP beneficiary is enrolled into a managed care plan and the feasibility of including the patient permission during the enrollment process. If not included in the application itself, is it feasible to gather permission and previous and/or concurrent payer information in a post-application questionnaire? Are there touchpoints that exist with beneficiaries after the application, but before or during enrollment (such as plan selection) that could be leveraged for this purpose? We considered proposing a policy that would require states to include optional questions to capture a patient's data exchange preference for payer to payer data exchange on their applications (as a non-required field); however, we believe that states have different processes, and a one-size-fits-all approach may not be optimal. Based on comments we receive and implementation across state Medicaid and CHIP programs, we may propose such a policy in the future.
Should our proposals be finalized as proposed, states operating Medicaid and CHIP programs might be able to access Federal matching funds to support their implementation of the Payer-to-Payer API. This proposed API is expected to lead to more efficient administration of the Medicaid and CHIP state plans, consistent with sections 1902(a)(4) and 2101(a) of the Act.
We would not consider state expenditures for implementing this proposal to be attributable to any covered Medicaid item or service within the definition of “medical assistance.” Thus, in Medicaid, CMS would not match these expenditures at the state's regular Federal FMAP. However, were this proposal to be finalized as proposed, FFP under section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper and efficient administration of the Medicaid state plan, might be available for state expenditures related to implementing this proposal for their Medicaid programs. We believe that using the Payer-to-Payer API would help the state more efficiently administer its Medicaid program, by ensuring that payers can access data that could improve care coordination for patients.
States' expenditures to implement these proposed requirements might also be eligible for 90 percent enhanced FFP under section 1903(a)(3)(A)(i) of the Act, if the expenditures can be attributed to the design, development, or installation of mechanized claims processing and information retrieval systems. Additionally, 75 percent enhanced FFP under section 1903(a)(3)(B) of the Act may be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with this proposed requirement.
States can request Medicaid enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act through the APD process described in 45 CFR part 95, subpart F. States are reminded that 42 CFR 433.112(b)(12) and 433.116(c) in part require that any system for which they are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act align with and incorporate the ONC's Health Information Technology standards adopted in 45 CFR part 170, subpart B. The Payer-to-Payer API complements this requirement because these APIs further interoperability by using standards adopted by ONC at 45 CFR 170.215.
Similarly, 42 CFR 433.112(b)(13) and 433.116(c) require states to promote sharing, leverage, and re-use of Medicaid technologies and systems as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. CMS interprets that requirement to apply to technical documentation associated with a technology or system, such as technical documentation for connecting to a state's APIs. Making the needed technical documentation publicly available so that systems that need to can connect to the APIs proposed in this rule would be required as part of the technical requirements at 42 CFR 431.60(d) for all proposed APIs in this rule, including the Payer-to-Payer API.
Separately, for state CHIP agencies, section 2105(c)(2)(A) of the Act and 42 CFR 457.618, limiting administrative
We note that the temporary Medicaid FMAP increase available under section 6008 of the Families First Coronavirus Response Act (Pub. L. 116-127) does not apply to administrative expenditures.
Most states have Medicaid Expansion CHIP programs, in which a state receives Federal funding to expand Medicaid eligibility to optional targeted to low-income children that meet the requirements of section 2103 of the Social Security Act. We are proposing at 42 CFR 457.700(c) that for states with Medicaid expansion CHIP programs, the proposals in this rule for Medicaid would apply to those programs rather than our proposals for separate CHIP programs. Functionally, our proposals are the same; however, for clarity, we are making explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 would apply to those programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732.
Should our proposals regarding the Payer-to-Payer API be finalized as proposed, we would strongly encourage state Medicaid and CHIP FFS programs to implement the Payer-to-Payer API as soon as possible, due to the many anticipated benefits of the API as discussed in this section. However, we also recognize that state Medicaid and CHIP FFS agencies may face certain circumstances that would not apply to other impacted payers. To address these concerns, we are proposing a process through which states may seek an extension of, and, in specific circumstances, an exemption from the Payer-to-Payer API requirements. We propose the following:
At the regulation citations identified in Table 3, we propose to provide state Medicaid FFS and CHIP FFS programs the opportunity to request a one-time extension of up to 1 year to implement the Payer-to-Payer API specified at 42 CFR 431.61(b) and 457.731(b). Some states may be unable to meet the proposed compliance date due to challenges related to securing needed funding for necessary contracting and staff resources in time to develop and implement the API requirements, depending on when the final rule is published in relation to a state's fiscal year, legislative session, budget process, and related timeline. Some states may need to initiate a public procurement process to secure contractors with the necessary skills to support a state's implementation of these proposed API policies. The timeline for an openly competed procurement process, together with the time needed to onboard the contractor and develop the API, can be lengthy for states. A state might need to hire new staff with the necessary skillset to implement this policy. The time needed to initiate the public employee hiring process, vet, hire, and onboard the new staff may make meeting the proposed compliance timeline difficult because, generally speaking, public employee hiring processes include stricter guidelines and longer time-to-hire periods than the other sectors.
Should the proposal for this API be finalized as proposed, states would be permitted to submit a written application for a one-time, one-year extension as part of their annual APD for MMIS operations expenditures. The state's request would have to include the following: (1) a narrative justification describing the specific reasons why the state cannot reasonably satisfy the requirement(s) by the compliance date, and why those reasons result from circumstances that are unique to the agency operating the Medicaid and/or CHIP FFS program (versus other types of impacted payers); (2) a report on completed and ongoing state implementation activities that evidence a good faith effort towards compliance; and (3) a comprehensive plan to meet the Payer-to-Payer API requirements no later than 1 year after the compliance date.
Under this proposal, CMS would approve an extension if, based on the information provided in the APD, CMS determines that the request adequately establishes a need to delay implementation, and that the state has a comprehensive plan to implement the proposed requirements no later than 1 year after the compliance date.
We also solicit comments on whether our proposal would adequately address the unique circumstances that affect states, and that might make timely compliance with the proposed API requirement difficult for states.
At the CFR sections identified in Table 3, we propose to permit state Medicaid FFS programs to request an exemption from the Payer-to-Payer API requirements when at least 90 percent of the state's Medicaid beneficiaries are enrolled in Medicaid managed care organizations as defined at 42 CFR 438.2. Likewise, we propose that separate CHIP FFS programs could request an exemption from the Payer-to-Payer API requirements if at least 90 percent of the state's separate CHIP beneficiaries are enrolled in CHIP managed care entities as defined at 42 CFR 457.10. In this circumstance, the time and resources that the state would need to expend to implement the Payer-to-Payer API requirements for a small FFS population may outweigh the benefits of implementing and maintaining the API. Unlike other impacted payers, state Medicaid and CHIP FFS programs do not have a diversity of plans to balance implementation costs for those plans with low enrollment. If there is low enrollment in a state Medicaid or CHIP FFS program, there is no potential for the technology to be leveraged for additional beneficiaries. States, unlike other payers, do not maintain additional lines of business.
We acknowledge that the proposed exemption could mean that most beneficiaries enrolled with exempted Medicaid or CHIP FFS programs would not receive the full benefits of having this API available to facilitate health information sharing with other payers. To address this, we propose that states that are granted an exemption would be expected to implement an alternative
We propose that a state could submit a written request for an exemption from the requirements for the Payer-to-Payer API as part of its annual APD for MMIS operations expenditures prior to the date by which the state would otherwise need to comply with the requirements (which may be extended by 1 year if the state receives an extension). For Medicaid exemption requests, the state would be required to include documentation that it meets the criteria for the exemption based on enrollment data from the most recent CMS “Medicaid Managed Care Enrollment and Program Characteristics” report. For a CHIP FFS exemption, the state's request would have to include enrollment data from Section 5 of the most recently accepted state submission to CARTS. The state would also be required to include in its request information about an alternative plan to ensure that payers will have efficient electronic access to the same information through other means while the exemption is in effect. CMS would grant the exemption if the state establishes to CMS's satisfaction that it meets the criteria for the exemption and has established such an alternative plan. We note that the exemption would only apply to the API requirements, not the state's permission collection obligations.
Once an exemption has been approved, we propose that the exemption would expire if either of the following two scenarios occurs: (1) based on the 3 previous years of available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data, the State's managed care enrollment for 2 of the previous 3 years is below 90 percent; or (2) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data.
For the first scenario, CMS recognizes that there may be circumstances where a state's managed care enrollment may fluctuate slightly below the 90 percent threshold in 1 year, and yet return to above 90 percent the next year. To help reduce the possible burden on exempted states experiencing this type of temporary fluctuation in managed care enrollment, CMS would consider data from the 3 previous years of available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data. We propose that if the state's managed care enrollment for 2 of the previous 3 years is below 90 percent, the state's exemption would expire.
We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the Payer-to-Payer API exemption when data confirm that there has been a shift from managed care enrollment to FFS enrollment resulting in the State's managed care enrollment falling below the 90 percent threshold for 2 of the previous 3 years. We propose that the written notification be submitted to CMS within 90 days of the finalization of the annual Medicaid T-MSIS managed care enrollment data and/or the CARTS report for CHIP confirming that there has been the requisite shift from managed care enrollment to FFS enrollment in 2 of the 3 previous years.
For the second scenario, we recognize that there may be state plan amendments, waivers, or waiver amendments that would result in a shift from managed care enrollment to FFS enrollment. Additionally, there may be instances where anticipated enrollment shifts may not be fully realized due to other circumstances. We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the Payer-to-Payer API exemption when data confirm that there has been a shift from managed care enrollment to FFS enrollment as anticipated in the state plan amendment or waiver approval. We propose that the written notification be submitted to CMS within 90 days of the finalization of the first annual Medicaid T-MSIS managed care enrollment data and/or the CARTS report for CHIP confirming that there has been the requisite shift from managed care enrollment to FFS enrollment.
Regardless of why the exemption expires, if it expires, the state would be required to obtain CMS's approval of a timeline for compliance with the Payer-to-Payer API requirements for the state's Medicaid FFS and/or CHIP FFS population(s) within two years of the expiration date of the exemption.
For Medicaid and CHIP managed care, we are not proposing an extension process because we believe that managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the existing requirements at 42 CFR parts 438 and 457 and because many of them might benefit from efficiencies resulting from the variety of plan types that they offer. Many managed care plans are part of parent organizations that maintain multiple lines of business, including Medicaid managed care plans and plans sold on the Exchanges. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25607, 25612, and 25620), work done by these organizations can benefit all lines of business and, as such, we do not believe that the proposals in this rule impose undue burden or cannot be achieved by the compliance date. We are soliciting comments on our assumptions regarding the scope of resources and ability of managed care parent organizations to achieve economies of scale when implementing the proposed API.
Further, we seek comment on whether an extension process would be warranted for certain managed care plans to provide additional time for the plan to comply with the proposed requirement at 42 CFR 431.61(b) (which cross references at 42 CFR 438.242(b)(7) for Medicaid managed care plans) and at proposed 42 CFR 457.731(b) (which cross references at 42 CFR 457.1233(d)) for CHIP managed care entities. While we are not proposing such a process for managed care plans and entities and do not believe one is necessary, we are open to evaluating options for possible future rulemaking. Were we to adopt an extension process for these managed care plans and entities, what criteria should a managed care plan or entity meet to qualify for an extension? Should the criteria include enrollment size, plan type, or certain unique characteristics that could hinder their achievement of the proposed requirements by the proposed compliance date? We also seek comment on whether, were we to propose such a process for Medicaid managed care plans or CHIP managed care entities, the entity responsible for evaluating the criteria and exception evaluation process should be the state and whether states could implement the exception evaluation process with available resources. Consistent with the exception process proposed for QHP issuers on the FFEs at 45 CFR 156.222(c), we would expect managed care plans seeking extensions to provide, at a minimum, a narrative justification describing the reasons why a plan or entity cannot reasonably satisfy the requirements by the proposed compliance date, an explanation of the impact of non-compliance upon
We request comment on the proposed extension and exemption processes.
For QHP issuers on the FFEs, we propose an exception to the Payer-to-Payer API proposal at the regulation citations identified in Table 3. We propose that if an issuer applying for QHP certification to be offered through an FFE believes it cannot satisfy the proposed requirements at 45 CFR 156.222(b) for the Payer-to-Payer API, the issuer would have to include as part of its QHP application a narrative justification describing the reasons why the issuer could not reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon providers and enrollees, the current or proposed means of providing health information to payers, and solutions and a timeline to achieve compliance with the requirements of this section. We propose that the FFE may grant an exception to the requirements at 45 CFR 156.222(b) for the Payer-to-Payer API if it determines that making qualified health plans of such issuer available through such FFE is in the interests of qualified individuals in the state or states in which the FFE operates, and an exception would be warranted to permit the issuer to offer qualified health plans through the FFE. This proposal would be consistent with the exception for QHP issuers on the FFEs we finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule (85 FR 25552). For instance, as noted in that final rule, that exception could apply to small issuers, financially vulnerable issuers, or new entrants to the FFEs that demonstrate that deploying FHIR API technology consistent with the required interoperability standards would pose a significant barrier to the issuer's ability to provide coverage to patients, and not certifying the issuer's QHP or QHPs would result in patients having few or no plan options in certain areas. We believe that having a QHP issuer offer QHPs through an FFE generally is in the best interest of patients and would not want patients to have to go without access to QHP coverage because the issuer is unable to implement this API.
In summary, we propose to permit certain impacted payers (state Medicaid and CHIP FFS programs and QHP issuers on the FFEs) to apply for an extension, exemption, or exception, as applicable, from implementing the proposed Payer-to-Payer API. We propose that these programs would submit and be granted approval for an extension or exemption as a part of applicable established processes. We propose that submission requirements would include certain documentation identified in the regulatory citations in Table 3.
For MA organizations, we are proposing these Payer-to-Payer API requirements under our authority at section 1856(b) of the Act by which the Secretary may adopt by regulation standards to implement provisions in Part C of Title XVIII of the Act (such as section 1852(d)(1)(A)), section 1852(h) of the Act that requires MA organizations to provide their enrollees with timely access to medical records and health information insofar as MA organizations maintain such information; and section 1857(e)(1) of the Act by which the Secretary may incorporate contract terms and conditions for MA organizations that we determine are necessary, appropriate, and not inconsistent with the statute.
We note that in regulations establishing the MA program,
Section 1856(b) of the Act requires the Secretary to establish regulatory standards for MA organizations and plans that are consistent with, and carry out, Part C of the Medicare statute, Title XVIII of the Act. The Payer-to-Payer API proposals support one payer sharing certain claims, encounter, and clinical data, as well as prior authorization requests and decisions with another payer identified by the patient. Such exchanges of data about enrollees could facilitate continuity of care and enhance care coordination. As discussed for the Provider Access API in section II.B. of this proposed rule, allowing payers to share health information for one or more patients at once could increase efficiency and simplicity of administration. Though we are not proposing to require payers to share data for more than one patient at a time, we believe there are efficiencies to doing so, both for communicating information and for leveraging available technology.
Thus, the proposal for payers to share information could apply as well to data exchanges using the Payer-to-Payer API. It could give payers access to all their enrollees' information with limited effort and enable the payer to then make that information available to providers and to enrollees through the Provider Access and Patient Access APIs. And it could reduce the amount of time needed to evaluate a patient's current care plan and possible implications for care continuity, which could introduce efficiencies and improve care. As discussed earlier, if a new payer is able to receive information and documentation about prior authorization requests from a previous payer, the new payer could review this information and determine that a new prior authorization may not be necessary for an item or service that was previously approved. Instead, the same care could be continued, reducing burden on both payers and providers and improving patient care. While the statutory provisions governing the MA program do not explicitly address sharing data with other payers that cover or have covered an enrollee, we believe that the benefits to be gained by sharing data make adoption of Payer-to-Payer API policies proposed here necessary and appropriate for the MA program. Further, requiring use of the API and the specifications for the data to be shared provides a step toward greater interoperability among payers. Ultimately, using the Payer-to-Payer API is anticipated to ensure that payers receive patient information in a timely manner, which could lead to more appropriate service utilization and higher beneficiary satisfaction, consistent with sections 1856(b) and 1857(e) of the Act.
Section 1852(h) of the Act requires MA organizations to provide their enrollees with timely access to medical records and health information insofar as MA organizations maintain such information. As technology evolves to allow for faster, more efficient methods of information transfer, so do expectations as to what is generally considered “timely.” Currently, consumers across public and private sectors have become increasingly accustomed to accessing a broad range of personal records, such as bank statements, credit scores, and voter registrations, immediately through electronic means and with updates received in near real-time. Thus, we believe that to align our standards with current demands, we must take steps for MA enrollees to have immediate, electronic access to their health information and plan information. The information exchanged via the proposed Payer-to-Payer API would ultimately be accessible to enrollees via the Patient Access API and would therefore improve timeliness to medical records and health information as enrollees would no longer have to spend time contacting previous payers to access their information. These data would be accessible as needed by the enrollee's current payer and would therefore support timely access.
Section 1852(d)(1)(A) requires MA organizations to, as a condition of using a network of providers, make covered benefits available and accessible to enrollees in a manner which assures continuity in the provision of benefits. In implementing section 1852(d)(1)(A) of the Act, we adopted a regulation, at 42 CFR 422.112(b), that requires MA organizations to ensure the continuity of care and integration of services through arrangements with providers that include procedures to ensure that the MA organization and the contracted providers have access to the information necessary for effective and continuous patient care. Consistent with section 1852(d)(1)(A) of the Act, we believe our proposal here for MA organizations to implement and maintain a Payer-to-Payer API would facilitate exchanges of information about enrollees that are necessary for effective and continuous patient care. Under our proposal, the data received from other impacted payers would become part of the data the MA organization maintains and would therefore be available (subject to other law authorizing the disclosure) to providers via the Provider Access API discussed in section II.B. of this proposed rule; the data could then be used for treatment and coordination of care purposes.
Our proposals in this section above fall generally under our authority in the following provisions of the Act.
• Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan.
• Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals.
• Section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients.
We believe these proposals related to the Payer-to-Payer API are authorized by section 1902(a)(4), (a)(8), and (a)(19) of the Act for the following reasons. First, because the Payer-to-Payer API is designed to enable efficient exchange of data between payers, if finalized as proposed, we anticipate that it would help state Medicaid programs improve the efficiencies and simplicity of their own operations, consistent with sections 1902(a)(4) and (a)(19) of the Act. It could give Medicaid and CHIP agencies and their managed care plans access to their beneficiary's information in a standardized manner and enable the state to then make that information available to providers and to patients through the Patient Access and Provider Access API. It could also reduce the amount of time needed to evaluate a patient's current care plan and possible implications for care continuity, which could introduce efficiencies and improve care. Receiving patient information at the start of coverage would help to ensure Medicaid and CHIP agencies and those managed care plans considered impacted payers under this proposed rule could lead to more appropriate service utilization and higher beneficiary satisfaction by supporting efficient care coordination and continuity of care, which could lead to better health outcomes.
As discussed in section II.C.3.a. of this proposed rule, if a state Medicaid program has access to a previous payer's prior authorization decisions, the Medicaid program could choose to accept the existing decision and support continued patient care without requiring a new prior authorization or duplicate tests. This information exchange might also improve care continuity for beneficiaries who have concurrent coverage in addition to Medicaid by improving the coordination of health coverage they receive, reducing gaps, or duplication of coverage.
Our proposals, if finalized, are expected to help states and managed care plans furnish Medicaid services with reasonable promptness and in a manner consistent with beneficiaries' best interests, consistent with section 1902(a)(8) and (a)(19) of the Act. A significant portion of Medicaid beneficiaries experience coverage changes and churn in a given year.
In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to uses or disclosures of information that are directly connected with the administration of the Medicaid state plan. The implementing regulations for this section of the Act list purposes that CMS has determined are directly connected to Medicaid state plan administration at 42 CFR 431.302. We believe that requiring the data described in this section to be shared via the Payer-to-Payer API would be consistent with states' requirements to provide safeguards to share these data since it is related to providing services for beneficiaries, a purpose listed in § 431.302(c). As described above in the section related to authority under sections 1902(a)(8) and 1902(a)(19) of the Act, states that share information about Medicaid beneficiaries or former beneficiaries with their concurrent and next payers, could support opportunities for improved care coordination, reduction in the amount of time needed to evaluate beneficiaries' current care plans, their health risks, and their health conditions at the time they enroll with the Medicaid program, as well as with another payer. This information exchange might be of particular value to improve care continuity for beneficiaries who churn into and out of Medicaid coverage, described in more detail above. When state Medicaid or CHIP agencies share medical records or any other health or enrollment information pertaining to individual beneficiaries, they must comply with 42 CFR 431.306. See discussion above about how the opt in process proposed for this API would help states comply with 42 CFR 431.306.
For Medicaid managed care plans, the proposed exchange of all data classes and data elements included in a content standard adopted at 45 CFR 170.213, adjudicated claims and encounter data, as well as the patient's prior authorization requests and decisions would greatly enhance an MCO's, PIHP's, or PAHP's ability to fulfill its obligations under 42 CFR 438.208(b) which require them to: implement procedures to deliver care to and coordinate services including ensuring that each enrollee has an ongoing source of appropriate care; coordinate services between settings of care, among Medicaid programs, and with community and social support providers; make a best effort to conduct an initial screening of each enrollee's needs; and share with the state or other MCOs, PIHPs, and PAHPs serving the enrollee the results of any identification and assessment of that enrollee's needs to prevent duplication of those activities. The data provided via the Payer-to-Payer API proposed in this rule would give managed care plans the information needed to perform these required functions much more easily, thus enhancing the effectiveness of the care coordination, and helping enrollees receive the most appropriate care in an effective and timely manner.
For CHIP, we are proposing these requirements under our authority in section 2101(a) of the Act, which states that the purpose of Title XXI of the Act is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. We believe the provisions in this proposed rule could strengthen our ability to fulfill these statutory
As with the Medicaid FFS and Medicaid managed care programs, the proposals in this section of the proposed rule for CHIP FFS and CHIP managed care entities, require using a Payer-to-Payer API to exchange claims, encounter, clinical and prior authorization data at a beneficiary's request, or any time a beneficiary changes payers, using a FHIR API. The current payer could use data from the previous payer to respond to a request for a prior authorization more effectively or accurately, because under this proposal, a new payer would have historical claims or clinical data upon which they may review a request with more background data. Access to information about new patients could enable appropriate staff within the CHIP program to coordinate care and conduct care management more effectively because they would have better data available to make decisions for planning. In many cases, patients do not remember what services they have had, what vaccines they have had, or other possibly relevant encounters that could help payers manage their care. This proposal is consistent with the goal of providing more informed and effective care coordination, which could help to ensure that CHIP services are provided in a way that supports quality care, which aligns with section 2101(a) of the Act.
Finally, the safeguards for applicant and beneficiary information at subpart F of 42 CFR part 431 are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As discussed above for Medicaid, CHIP agencies' data exchange through the Payer-to-Payer API would be related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share medical records or any other health or enrollment information pertaining to individual beneficiaries, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306. See discussion above about how the opt in process proposed for this API would help states comply with 42 CFR 431.306.
For QHP issuers on the FFEs, we are proposing these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates.
Requiring QHP issuers on the FFEs to implement and maintain a Payer-to-Payer API would allow the seamless flow of all data classes and data elements included in a standard in 45 CFR 170.213, adjudicated claims and encounter data as well as the patient's prior authorization requests and decisions, from payer to payer. We believe that ensuring a means for an enrollee's new issuer to electronically obtain the enrollee's claims, encounter, and other data, as well as prior authorization information with corresponding medical records, from the previous issuer would reduce administrative burden and result in more timely and efficient care coordination and responses to prior authorization requests.
We believe it is in the interest of qualified individuals that QHP issuers on FFEs have systems in place to send information important to care coordination with departing enrollees, and that QHP issuers on FFEs also have systems in place to receive such information from payer to payer on behalf of new and concurrent enrollees, as appropriate and consistent with the proposals in this section. Therefore, we believe certifying health plans that make enrollees' health information available to other payers in a convenient, timely, and portable way is in the interests of qualified individuals in the state in which an FFE operates. We encourage SBEs to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchange.
Though we are not requiring the exchange of all enrollee's data at one time between issuers, we encourage QHP issuers on the FFEs to use the Bulk Specification for the Payer-to-Payer API once it is available as we believe it would improve the efficiency and simplicity of data transfers between issuers by enabling the exchange of all data for all patients at once. We believe the opportunity to support an exchange of large volumes of patient data, rather than data for one patient at a time, may be cost effective for the issuers. Having patient information at the beginning of a new plan could assist the new payer in identifying patients who need care management services, which could reduce the cost of care. Taking in volumes of data would also enable the QHPs to perform analysis on the types of new patients in their plan if they choose to analyze data for existing patients as well.
This section of the proposed rule addresses the topic of prior authorization and includes both technical and operational proposals that are intended to improve the prior authorization process for payers, providers, and patients. Here we propose to require payers to do the following: implement and maintain an API to support and streamline the prior authorization process; respond to prior authorization requests within certain timeframes; provide a clear reason for prior authorization denials; and publicly report on prior authorization approvals, denials, and appeals. The proposals in this rule would build on the foundation set out in the CMS Interoperability and Patient Access final rule (85 FR 25510) to improve health information exchange and increase interoperability in the healthcare system. These proposals were developed based on input from CMS-sponsored listening sessions and stakeholder meetings which included payers, providers, vendors, and patients, as well as reports prepared and released by HHS or its Federal advisory committees, such as the National Committee on Vital and Health Statistics (NCVHS) and the Health Information Technology Advisory Committee (HITAC).
The proposals would apply to any formal decision-making process through which impacted payers render an approval or denial determination in response to prior authorization requests based on the payer's coverage guidelines and policies before services are rendered or items provided. As discussed in section I.A.1., because the processes and standards for prior authorization applicable to drugs differ from other items and services, this proposed rule would not apply to any drugs, meaning any drugs that could be covered by the impacted payers in this proposed rule. As such, this proposed rule would not apply to outpatient drugs, drugs that may be prescribed, those that may be administered by a physician, or that may be administered in a pharmacy, or hospital. We propose a definition for this exclusion for each impacted payer in the regulation text of this proposed rule, and provide a reference to the CFR sections where
Also, as mentioned in section I.A, Medicare FFS is not directly affected by this proposed rule. However, the Medicare FFS program is evaluating opportunities to improve automation of prior authorization processes. If our proposals are finalized, Medicare FFS would align its efforts for implementation of the requirements as feasible. We seek comment on whether this could be implemented as proposed for the Medicare FFS program, how we could apply the proposals below, and if there would be differences for implementing the PARDD API in the Medicare FFS program as a Federal payer.
We use the term prior authorization to refer to the process by which a provider must obtain approval from a payer before providing care in order to receive payment for delivering items or services. Prior authorization has an important place in the healthcare system, but the process of obtaining prior authorization can be challenging for patients, providers, and payers. Stakeholders, including payers and providers, have claimed that dissimilar payer policies, provider workflow challenges, inconsistent use of electronic standards, and other technical barriers have created an environment in which the prior authorization process is a primary source of burden for both providers and payers, a major source of burnout for providers, and can become a health risk for patients if inefficiencies in the process cause care to be delayed.
HHS has been studying prior authorization processes and their associated burden for several years to identify the primary issues that might need to be addressed to alleviate the burdens of these processes on patients, providers, and payers. For example, to advance the priorities of the 21st Century Cures Act (Pub. L. 114-255),
In 2018, the American Medical Association (AMA) conducted a physician survey that noted issues with prior authorization. In December 2020, the AMA released the results of a second member survey, which indicated that provider burdens related to prior authorization had not improved, but rather had gotten worse, indicating a weekly per-physician average of 41 prior authorization requests, which consume an average of 13 hours of practice time per workweek for physicians and their staff. Additionally, 40 percent of physicians employ staff to work exclusively on prior authorizations.
The burden of prior authorization is not experienced solely by physicians; hospitals are also burdened by prior authorization processes. In a November 4, 2019 letter to the CMS Administrator, the American Hospital Association (AHA) described the ongoing impact of prior authorization on patient care, health system costs, and administrative burdens.
In 2019, CMS conducted several listening sessions with payers, providers, patients, and other industry representatives to gain insight into issues with prior authorization processes and identify potential areas for improvement. While providers and payers agreed that prior authorization provides value to the healthcare system for cost control, utilization management, and program integrity, some stakeholders explained that certain steps in prior authorization processes present an undue burden. For example, the information payers require from providers to evaluate or review a prior authorization can be inconsistent from payer to payer, and it can be difficult for providers to determine the rules for items or services that require prior authorization, or to identify what documentation is needed to obtain approval. Furthermore, documentation requirements are not standardized across payers, and access to the requirements may require the use of proprietary portals. These same types of challenges were described in ONC's 2020 Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs, which reported that “[e]ach payer has different requirements and different submission methods, and clinicians report finding it burdensome and time-consuming trying
In March and November of 2019, two Federal advisory committees, the HITAC
In early 2020, NCVHS and HITAC convened another task force, the Intersection of Clinical and Administrative Data (ICAD) Task Force. The overarching charge to the Task Force was to bring together industry experts and produce recommendations related to electronic prior authorizations.
The first guiding principle in the ICAD report is that the patient is at the center of care and emphasis should be on process solutions that remove roadblocks to care and support the coordination of timely care while reducing burdens, improving the patient experience, and ultimately improving outcomes.
The HITAC and NCVHS Federal advisory committee reports, as previously mentioned, describe the need for process improvements for prior authorization, which echo the input CMS received from its payer and provider stakeholder meetings and industry surveys. We believe our proposals, if finalized as proposed, would make meaningful progress to improve prior authorization processes, alleviate burdens, facilitate more equitable access to care, and support efficient operations for providers and payers.
As discussed in section I.A. of this proposed rule, in December 2020, CMS published the December 2020 CMS Interoperability proposed rule, in which we made proposals to streamline the prior authorization process. In general, payers and providers supported the intent of the proposed rule, however, they also requested that CMS include the Medicare Advantage program as an impacted payer and evaluate the implementation dates for the APIs. As stated in section I.A., we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates the feedback we received from stakeholders. We understand that many readers may already be familiar with that proposed rule, and to distinguish the differences between the proposals, we refer readers to the discussion in section I.A. which outlines the overarching differences between this proposed rule and the prior proposed rule.
There are additional differences specific to proposals in this section. First, we have modified the name and description of the standards-based APIs intended to support prior authorization processes but have not changed the purpose of those APIs. In this proposed rule, we refer to two of the previously proposed APIs collectively as the Prior Authorization Requirements, Documentation, and Decision (PARDD) API. In the December 2020 CMS Interoperability proposed rule, we
While there is a standard available for electronic prior authorization transactions, adopted by HHS under the provisions of the Health Insurance Portability and Accountability Act of 1996 (HIPAA), many payers and providers do not use this adopted standard (the X12 278 Version 5010). Instead, payers build proprietary interfaces and web portals through which providers submit their requests, and both still frequently resort to phone calls or faxes to complete the process for a response. The process may remain inefficient, burdensome, and create service issues for patients. As previously explained, providers indicate that the main hurdle is knowing which services require prior authorization, and what documentation is necessary to support that service or item. The current processes or standard do not address this barrier.
In section II.B.2. of this proposed rule, we reference the transactions for which the Secretary must adopt standards for use by HIPAA-covered entities (for example, health plans, health care clearinghouses, and certain health care providers), and list the transactions for which a standard must be adopted. The HIPAA-adopted standards for referral certifications and authorizations, also referred to as the prior authorization transaction standards (45 CFR 162.1302), are the—
• National Council for Prescription Drug Programs (NCPDP) Telecommunication Standard Implementation Guide Version D.0 for retail pharmacy drugs; and
• ASC X12 Version 5010x217 278 (X12 278) for dental, professional, and institutional requests for review and response.
While the prior authorization proposals in this proposed rule do not apply to any drugs, we reference the NCPDP standard for retail pharmacy transactions to acknowledge it as one of the two mandated standards for prior authorization adopted under HIPAA. The X12 278 standard was adopted for the prior authorization of medical items and services. Though payers are required to use the X12 278 version 5010 standard for electronic prior authorization transactions and providers are encouraged to conduct the transaction electronically, the X12 278 has not achieved a high adoption rate by covered entities. The Council for Affordable and Quality Health Care (CAQH) releases an annual report, the CAQH Index, which includes data on health plan and provider adoption of HIPAA standard transactions. In the 2019 report, among the seven transactions benchmarked, prior authorization using the X12 278 standard was the least likely to be supported by payers, practice management systems, vendors, and clearinghouse services.
Enhancements to the electronic prior authorization process could support greater use of the HIPAA X12 278 standard through automation, which could also reduce the time for submission of the request and response. In the following discussion, we propose to require impacted payers to implement an HL7 FHIR API that would work in combination with the adopted HIPAA transaction standard to conduct the prior authorization process. It is important to note that we are not proposing changes to the requirement for covered entities to use the adopted HIPAA transaction standard but are proposing to require that impacted payers develop and implement an API that works together with that standard, and may support greater use of the X12 278 standard.
As previously noted, section 1104 of the Affordable Care Act amended HIPAA to also require that HHS adopt operating rules for the HIPAA standard transactions. “Operating rules” are defined at 45 CFR 162.103 as the “necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard or its implementation specifications as adopted for purposes of HIPAA Administrative Simplification.” The NCVHS reviews potential HIPAA operating rules and advises the Secretary as to whether HHS should adopt them (section 1173(g) of the Act). The Secretary adopts operating rules through regulation in accordance with section 1173(g)(4) of the Act. To date, HHS has adopted operating rules for three of the HIPAA standard transactions: eligibility for a health plan and health care claim status (76 FR 40457), health care Electronic Funds Transfer (EFT), and remittance advice (77 FR 48007). In February 2020, CAQH, which develops operating rules for some of the HIPAA standards, submitted two operating rules for NCVHS review regarding HIPAA referral certification and authorization transaction. NCVHS held a hearing to discuss those operating rules in August 2020 and submitted a letter to the HHS Secretary in November 2020 recommending pilot testing to evaluate the proposed operating rules rather than immediate adoption. At this time, NCVHS has not recommended that HHS adopt operating rules for the HIPAA referral certification and authorization transaction. Should NCVHS make such a recommendation, we would evaluate the effect, if any, on the policies included in this proposed rule. Even if this rule is finalized as proposed we would continue to evaluate the impact of an NCVHS recommendation and any separate actions by HHS in that regard.
In March 2021, HHS approved an application
To help address prior authorization process challenges and continue following our roadmap to interoperability, we propose to require that, beginning January 1, 2026, certain payers implement and maintain a FHIR Prior Authorization Requirements, Documentation, and Decision (PARDD) API to be used by providers to facilitate the prior authorization process.
We note that in section II.A.2.a., we are proposing that payers make information about prior authorization decisions available to patients through the Patient Access API to help them be more informed decision makers and partners in their healthcare. The proposals in this section are specific to improving the prior authorization process between payers and providers using the PARDD API. These policies taken together help to facilitate a more streamlined and better-informed healthcare team in which patients, providers, and payers have access to the status of prior authorizations.
The PARDD API would streamline the prior authorization process for the provider or office staff by automating certain tasks, thereby mitigating some of the obstacles of the existing prior authorization process. The API would allow a provider to query the payer's system to determine whether a prior authorization was required for certain items and services and identify documentation requirements. The API would also automate the compilation of necessary data for populating the HIPAA-compliant prior authorization transaction and enable payers to provide the status of the prior authorization request, including whether the request has been approved or denied. Covered entities would continue to send and receive the HIPAA-compliant prior authorization transactions while using the FHIR PARDD API. In the following discussion, we propose to require certain standards and recommend several others that would support the build of this API, while maintaining compliance with the mandated HIPAA standard for prior authorization.
To implement the API, we propose to require the use of certain IGs adopted at 45 CFR 170.215. We also propose that impacted payers would use the same documentation requirements and the same discontinuation and denial of access requirements as we are proposing for the Patient Access API (discussed in section II.A.2), the Provider Access API (section II.B.2), and the Payer-to-Payer API (section II.C.3). We believe that consistency in applying these requirements to all proposed APIs would minimize the cost and burden of implementation and support payer risk mitigation strategies. Should this proposal be finalized as proposed, we would also recommend using certain HL7 FHIR Da Vinci IGs which have been developed specifically to support the functionality of the PARDD API. These include:
• The HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide.
• The HL7 FHIR Da Vinci Documentation Templates and Rules (DTR) Implementation Guide.
• The HL7 FHIR Da Vinci Prior Authorization Support (PAS) Implementation Guide.
The CRD IG provides information about whether an authorization is required for certain items or services and provides transparency into the payers' prior authorization coverage rules, so the provider knows what information is necessary to support a request. The DTR IG provides the means to ensure the completion of documentation needed to demonstrate medical necessity for a proposed item or service, based on payer requirements.
The PAS IG uses the FHIR standard as the basis for (1) assembling the information necessary to substantiate the clinical need for a particular treatment, and (2) submitting the assembled information and prior authorization request to an intermediary before it is sent to the intended recipient. Under the workflow specified in the PAS IG, to meet regulatory requirements for the HIPAA standard transactions discussed previously, the FHIR interface communicates with an intermediary (for example, a clearinghouse) that converts the FHIR requests to a HIPAA-compliant X12 278 request transaction for submission to the payer. In some cases, the payer may act as the intermediary or clearinghouse and convert the request to a HIPAA-compliant X12 278 transaction. Under the workflow specified in the PAS IG, the response from the payer would then flow back through the intermediary using X12 278 and would be made available to the provider's health IT system using the FHIR standard. The response would indicate whether the payer approves (and for how long), or denies (and the reason), the prior authorization request, or request more information from the provider to support the prior authorization request. This IG also defines capabilities around the management of prior authorization requests, including checking on the status of a previously submitted request, revising a previously submitted request, and canceling a request. The goal is to provide information about prior authorization, where possible, in the provider's clinical workflow. We refer to section II.F. of this proposed rule for further discussion of the required and recommended standards to support the PARDD API.
To reiterate, for the reasons explained in section I.A., we are not proposing to apply the proposals for the PARDD API to any drugs.
Based on a review of Medicare FFS policies and prior authorization requirements, as well as industry pilots and demonstrations, we understand payers may have hundreds of policies that could be included in the PARDD API. The initial phase of identifying and evaluating all the policies may be a significant effort. We also recognize that payers would need to evaluate their prior authorization policies for each plan type, analyze coverage requirements, and program those requirements for the PARDD API. We acknowledge that such efforts would require staff time for evaluation, development, and testing of the API
Given the effort that would be required to implement the PARDD API, we considered proposing that the API be implemented in a phased approach. Specifically, we considered and are seeking comment on whether to require payers to make prior authorization rules and documentation requirements available through the API incrementally, beginning January 1, 2026. In this alternative, Medicaid managed care plans and CHIP managed care entities would be required to comply with the approach described (in this section of this document) by the rating period beginning on or after January 1, 2026, and QHP issuers on the FFEs for plan years beginning on or after January 1, 2026.
Under the proposal we considered, in the first phase, impacted payers would have been required to make 25 percent of their prior authorization rules and documentation requirements available through the API, prioritized by the highest number of requested items and services. We would have proposed that the first phase begin by January 1, 2026. The second phase would have required impacted payers to make available at least 50 percent of their prior authorization rules and documentation requirements, prioritized by the highest number of requested items and services. We would have proposed that this phase begin by January 1, 2027. Finally, beginning January 1, 2028, impacted payers would have been required to make available 100 percent of their prior authorization rules and documentation requirements through the API. Though this alternative approach could have provided additional time for payers to test their implementations and assess the benefits with providers, there was also a potential risk that a phased approach could have added complexity to the process for providers, rather than improving efficiency and reducing burden. If each payer's highest volume of requirements is unique, provider staff could have been required to spend considerable time alternating between the API and prior methods of researching prior authorization requirements. We opted against proposing this lengthy phased-in option because of the challenges we believe it could have created for providers continuing to navigate different implementation of payer rules. However, we request comments on this phased-in approach, our assumptions, and other potential options for an implementation strategy. For example, we request comment on whether payers would need a phased-in implementation to codify their rules and ensure that they are in a structured format (for example, quantifiable and machine-readable) for purposes of the API. If an alternative approach of this type were to be considered, how could CMS structure such an implementation strategy and timeframe without introducing additional burden? What are the operational and technical challenges involved in converting prior authorization rules into structured, machine-readable documents? Do payers have estimates of the amount of time that would be required for converting the most frequently requested prior authorizations into structured documents?
For purposes of this proposed rule, rather than pursue a phased implementation process to maximize the benefits of electronic prior authorization, we propose that payers would be required to implement the PARDD API for all prior authorization rules and requirements for items and services, excluding drugs, by 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). We do not believe it necessary to propose a phased implementation strategy because we are not certain such an approach would reduce burden on either impacted payers, or providers, and believe in some cases it could increase the burden during the initial implementation. For example, as we previously outlined, for a phased approach, in the first phase, impacted payers would have been required to make 25 percent of their prior authorization rules and documentation requirements available through the API. Because prior authorizations vary by payer, that could mean that some payers would make one set of items or services available for prior authorization via the PARDD API, and another payer would have another set of items and services available. Providers seeking to utilize the PARDD API would then have conflicting methods of prior authorization available for different types of items or services based on each payer's implementation decisions. This could be confusing, particularly during the initial rollout of a new API such as this one. We also believe that a phased approach could delay the availability of electronic prior authorization for certain items and services, which may in turn reduce the overall adoption of the PARDD API by providers who do not see their specialties and services represented in the initial rollout of the available PARDD API for items and services.
We believe current industry pilots of alternatives for electronically exchanging prior authorization rules and requirements for documentation have already successfully demonstrated that payers may be able to meet the objectives in this proposed rule to improve prior authorization processes through the proposed API. The HL7 Community Roundtable recordings provide examples of these industry pilots and implementation of the HL7 IGs.
Even if finalized as proposed, our proposal would provide a window of several years for implementation of the PARDD API. We acknowledge that payers might elect to maintain their existing prior authorization processes until the proposed implementation date, but we would encourage them to develop short-term mechanisms to make prior authorization information more easily understandable and publicly available to providers and patients. Some payers publish their prior authorization requirements on their individual websites or make them available through proprietary portals. However, these payer-specific portals and websites may be cumbersome because they each require individual access, login, and passwords. Furthermore, a provider may require a certain amount of patient and plan data to find the relevant detail for a specific item or service to determine prior authorization requirements. These portals or website options may be viable solutions until the PARDD API is built, made widely available, and providers gain experience using the tool. We invite readers of this proposed rule to provide information about other electronic, public-facing resources and
This PARDD API proposal could help both payers and providers mitigate some of the burdens of the prior authorization process and streamline the overall process. Payers that implement and maintain the proposed PARDD API might experience process improvements, fewer unnecessary requests or follow-up inquiries, and a decrease in denials or appeals. Such improvements could contribute to burden reduction for providers by reducing manual tasks and decreasing the volume of denials or appeals made.
We acknowledge that the new functionality of the API may require changes to the payer's customer service operations and procedures for providing support to patients during and after implementation. There may be questions about the required documentation, authorizations or denials about which both staff members and patients may need additional training and resources. We encourage payers to evaluate the procedural and operational changes as part of their implementation strategy, and to make appropriate resources available when the API is launched. While there are a number of resources available to ensure that patients receive quality services when accessing new technologies in health care, we invite feedback from commenters about available resources, such as the recent White House Blueprint for an AI Bill of Rights
Finally, the anticipated benefits of the PARDD API are in part contingent upon providers using health IT products that can interact with payers' APIs. In section II.E. of this proposed rule, we propose a new measure for the MIPS Promoting Interoperability performance category for MIPS eligible clinicians and the Medicare Promoting Interoperability Program for eligible hospitals and CAHs that would require healthcare providers to request a prior authorization electronically using data from certified electronic health record technology (CEHRT) using a payer's PARDD API. We request comment on additional steps CMS could take to encourage providers and health IT developers to adopt the technology necessary to access payers' PARDD APIs. In addition, we note that on January 24, 2022, ONC published an RFI titled “Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria” (87 FR 3475) requesting comment on how updates to the ONC Health IT Certification Program could support electronic prior authorization. We continue to work with ONC on ways to facilitate the adoption of standards to streamline data exchange, support interoperability, and increase efficiencies.
In summary, we propose 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), these impacted payers would be required to implement and maintain a FHIR PARDD API using technology conformant with certain standards and implementation specifications in 45 CFR 170.215. We propose to require that the PARDD API be populated with the payer's list of covered items and services, excluding drugs, for which prior authorization is required and accompanied by any documentation requirements. We further propose that the PARDD API would be required to include functionality to determine requirements for any other data, forms, or medical record documentation required by the payer for the items or services for which the provider is seeking prior authorization and while maintaining compliance with the HIPAA standard. Finally, the PARDD API responses from the payer to the provider would be required to include information regarding payer approval (and for how long) or denial (with a specific reason) of the request, or request more information from the provider to support the prior authorization request (see discussion in section II.D.4.a.). We are proposing these requirements for the proposed PARDD API at the CFR sections identified in Table 7.
We request comment on the proposal to require implementation of a Prior Authorization Requirements, Documentation, and Decision API.
Should our proposals be finalized as proposed, states operating Medicaid and CHIP programs may be able to access Federal matching funds to support their implementation of the proposed PARDD API. This proposed API is expected to lead to more efficient administration of Medicaid and CHIP state plans by supporting a more efficient prior authorization process, consistent with sections 1902(a)(4) and 2101(a) of the Act.
We would not consider state expenditures for implementing this proposal to be attributable to any covered Medicaid item or service within the definition of “medical assistance.” Thus, in Medicaid, CMS would not match these expenditures at the state's regular Federal medical assistance percentage (FMAP). However, Federal financial participation (FFP) under section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper and efficient administration of the Medicaid state plan, might be available for state expenditures related to implementing this proposal for their Medicaid programs. We believe that using the PARDD API would help the state more efficiently administer its Medicaid program by increasing the efficiencies in the prior authorization process. For instance, using the PARDD API would enable administrative efficiencies by improving accuracy, and by helping reduce the number of denied and appealed prior authorization decisions.
States' expenditures to implement these proposed requirements could also be eligible for 90 percent enhanced FFP under section 1903(a)(3)(A)(i) of the Act, if the expenditures can be attributed to the design, development, or installation of mechanized claims processing and information retrieval systems. Additionally, 75 percent enhanced FFP, under section 1903(a)(3)(B) of the Act, could be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with this proposed requirement.
States can request Medicaid enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act through the APD process described in 45 CFR part 95, subpart F. States are reminded that 42 CFR 433.112(b)(12) and 433.116(c) in part require that any system for which they are receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act align with and incorporate the ONC Health Information Technology standards adopted in 45 CFR part 170, subpart B. The PARDD API would complement this requirement because this API would further interoperability by using standards adopted by ONC at 45 CFR 170.215.
Similarly, 42 CFR 433.112(b)(13) and 433.116(c) require the states to promote sharing, leverage, and re-use of Medicaid technologies and systems as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. CMS interprets that requirement to apply to technical documentation associated with a technology or system, such as technical documentation for connecting to a state's APIs. Making the needed technical documentation publicly available so that systems that need to can connect to the APIs proposed in this rule would be required as part of the technical requirements at 42 CFR 431.60(d) for all proposed APIs in this rule, including the PARDD API.
Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act and 42 CFR 457.618, limiting administrative costs to no more than 10 percent of a state's total computable expenditures for a fiscal year, would apply to administrative claims for developing the APIs proposed in this rule.
We note that the temporary Medicaid FMAP increase available under section 6008 of the Families First Coronavirus Response Act (Pub. L. 116-127) does not apply to administrative expenditures.
Most states have Medicaid Expansion CHIP programs, in which a state receives Federal funding to expand Medicaid eligibility to optional targeted low-income children that meet the requirements of section 2103 of the Social Security Act. We are proposing at 42 CFR 457.700(c) that for states with Medicaid Expansion CHIP programs, the proposals in this rule for Medicaid would apply to those programs rather than our proposals for a separate CHIP program. Functionally, our proposals are the same; however, for clarity, we are making explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 would apply to those programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732.
Based on the stakeholder input described in this proposed rule, we believe the prior authorization process could be improved through better communication between payers and providers. One of the opportunities for better communication is timely and specific information about the reason for denying a prior authorization. Payers deny prior authorizations for different reasons. For example, a payer might deny a prior authorization because the payer does not consider the items or services to be medically necessary, the patient may have exceeded limits on allowable covered care for a given type of item or service, or documentation to support the request was missing or inadequate. Providing an understandable reason for a denial could allow a provider to take appropriate actions such as re-submitting the request with updated information, identifying alternatives for the patient, appealing the decision, or communicating the decision to the patient. As noted in the 2021 AMA provider survey, 83 percent of providers report that prior authorization process issues lead to treatment abandonment, while 93 percent reported that process issues led to delays in care.
Impacted payers currently have the capability to send information to providers about the reason a prior authorization request has been denied either electronically or through other communication methods. For denials sent using the X12 278 standard, payers must use the codes from the designated X12 code list. For responses sent through portals, via fax or other means, payers may use proprietary codes or text to provide denial reasons. Consistent use of both technology and terminology (codes) to communicate denial information could mitigate some of the operational inefficiencies for providers so that they could more consistently interpret and react to a denied prior authorization request. This proposal to send a specific denial reason is one approach to address current inefficiencies.
Specifically, we propose 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 provide a specific reason for denied prior authorization decisions, excluding prior authorization decisions for drugs, regardless of the method used to send the prior authorization request. As stated under the proposal for the PARDD API, we are also proposing that responses about a prior authorization decision sent through the PARDD API from the payer to the provider would have to include information regarding whether the payer approves (and for how long) or denies the prior authorization request, or requests more information from the provider to support the request. We are proposing these requirements regarding prior authorization decisions for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 7.
Some payers that would be subject to this proposal are also subject to existing requirements to provide notice to patients or providers, or both, with the specific reasons for denial, and this proposal builds on those existing policies.
Some payers that would be affected by this proposed rule are required by existing Federal and state laws and regulations to notify providers and patients when an adverse decision is made about a prior authorization request. As previously discussed, our proposals to impose requirements on payers to communicate certain information to providers about prior authorization requests are intended to reinforce these existing Federal and state requirements. Our proposals would not alter or replace existing requirements to provide notice to patients, providers, or both. The proposed requirement to use the PARDD API to compile necessary data and populate the X12 278 transaction response to the provider, including whether an authorization request has been approved (and for how long), denied, with a reason for the denial, or
This section of this proposed rule addresses additional denial notice requirements for certain impacted payers in the MA program, as well as Medicaid, and includes information on existing Medicaid beneficiary notice and fair hearing regulations in the context of prior authorization decisions in section II.D.6.b.
For Medicaid managed care plans and CHIP managed care entities,
We also remind all Medicaid managed care plans and CHIP managed care entities that would be subject to this proposed rule that their existing obligations to provide these required notices to enrollees would not be changed by the proposals in this proposed rule. These payers would still have to provide a separate written notice to the enrollee as required in 42 CFR 438.210(c) and (d) and 438.404.
Under the MA program, the actions that constitute an “organization determination” at 42 CFR 422.566(b) include a prior authorization (or “pre-service”) decision, as paragraph (b)(3) refers to an MA organization's refusal to provide or pay for services, in whole or in part, including the type or level of services, that the enrollee believes should be furnished or arranged by the MA organization. Under existing § 422.566(b), an organization determination would include a request for prior authorization using the PARDD API under the proposed provisions at 42 CFR 422.122. Existing MA program regulations are specific as to the form and content of the written notice to enrollees in the event of a partial or full denial. For example, existing regulations at 42 CFR 422.568(e) regarding written notices for enrollees for standard organization determinations require that a notice for any denial for a covered service or item under 42 CFR 422.568(d) must: (1) use approved notice language in a readable and understandable form; (2) state the specific reasons for the denial; (3) inform the enrollee of their right to a reconsideration; (4) describe both the standard and expedited reconsideration processes, including the enrollee's right to, and conditions for, obtaining an expedited reconsideration and the rest of the appeal process; and (5) comply with any other notice requirements specified by CMS. Under the rules at 42 CFR 422.572 related to timeframes and notice requirements for expedited organization determinations, an MA organization must send a written denial notice to the enrollee, and physician involved as appropriate, whenever an MA plan's determination is partially or fully adverse to the enrollee. The rules at 42 CFR 422.572(a)(1) related to expedited organization determinations state that an MA organization that approves a request for expedited determination must make its determination and notify the enrollee, and the physician involved as appropriate, of its decision whether adverse or favorable and as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving the request. Either an enrollee or a physician, regardless of whether the physician is affiliated with the MA organization, may request that an MA organization expedite an organization determination. Given that a physician is often involved in requesting an expedited organization determination on behalf of an enrollee, the rules related to notices explicitly require an MA plan to notify the enrollee and the physician involved, as appropriate, of its decision, whether adverse or favorable. The content of a notice of expedited determination must state the specific reasons for the determination in understandable language and if the determination is not completely favorable to the enrollee, the notice must also: (1) inform the enrollee of their right to a reconsideration; (2) describe both the standard and expedited reconsideration processes, including the enrollee's right to request, and conditions for obtaining, an expedited reconsideration, and the rest of the appeal process; and (3) comply with any other requirements specified by CMS.
Because applicable integrated plans may be either MA plans for individuals with special needs who are dually eligible for Medicare and Medicaid, or Medicaid MCOs, the regulations regarding prior authorization processes that we are proposing for MA plans and Medicaid managed care plans would apply to applicable integrated plans as well. Similar rules at 42 CFR 422.631(d) already govern denial notices issued by applicable integrated plans to their enrollees. Integrated organization determination notices must be written in plain language, available in a language and format that is accessible to the enrollee, and explain: (1) the applicable integrated plan's determination; (2) the date the determination was made; (3) the date the determination will take effect; (4) the reasons for the determination; (5) the enrollee's right to file an integrated reconsideration and the ability for someone else to file an appeal on the enrollee's behalf; (6) procedures for exercising an enrollee's rights to an integrated reconsideration; (7) the circumstances under which expedited resolution is available and how to request it; and (8) if applicable, the enrollee's rights to have benefits continue pending the resolution of the integrated appeal process. As with the notices required from MA plans, our proposal would not change the content requirements for these written denial notices to enrollees but would supplement these notices by requiring applicable integrated plans to notify the provider of the reason for a denial of a prior authorization request.
QHP issuers on the FFEs that offer individual health insurance must provide the specific reason for an adverse benefit determination, which
During the CMS listening sessions and other public meetings, we heard, largely from providers, that excessive wait time for prior authorization decisions could cause delays to patient care and may create medical risks in some cases. In most examples cited, providers face delays for the approval of the initial request, or, secondarily, for the resolution of a request “in process,” often meaning the payer is reviewing requested documentation. A 2017 AMA study reported that 39 percent of physicians stated that for those patients whose treatment requires prior authorization, the process can delay access to care. In that same study, between 19 and 57 percent of physicians reported that for those patients whose treatment requires prior authorization, the process may lead to patients abandoning their recommended course of treatment.
In this proposed rule, we use the term “standard” prior authorization to refer to non-expedited, non-urgent requests for prior authorization and the term “expedited” prior authorization to indicate an urgent request. These terms are used, as described here, in the provisions in 42 CFR 422.568, 422.570, 422.572, and 422.631 for MA organizations and applicable integrated plans, and 42 CFR 438.210(d) for Medicaid managed care plans, and we will use these terms for all regulated payers to whom the proposed policy in this section applies.
Under existing regulations for standard prior authorization decisions, MA organizations and applicable integrated plans must make a decision and send notice of that decision as expeditiously as the enrollee's condition requires, but may not exceed 14 calendar days following receipt of the request for an item or service.
Under these programs, if a provider indicates or the payer determines that following the standard timeframe could seriously jeopardize the patient's life, health or ability to attain, maintain, or regain maximum function, the MA plan, applicable integrated plan, Medicaid managed care plan, or CHIP managed care entity must make an expedited authorization decision and provide notice as expeditiously as the beneficiary's health condition requires, but no later than 72 hours after receiving the request.
Under existing Federal regulations for these payers, the enrollee may request an extension of up to 14 additional calendar days from the standard and expedited timeframes for the payer to make a decision on a prior authorization request for an item or service. Also, the payer may initiate the extension up to 14 additional calendar days if the payer needs additional information and the extension is in the enrollee or beneficiary's interest.
Under existing Federal CHIP regulations for FFS programs, prior authorization of health services must be completed within 14 days after receiving a request for services or in accordance with existing state law regarding prior authorization of health services.
Table 4 provides a summary of current Federal requirements for prior authorization decision timeframes that apply to the payers that would be affected by this proposed rule.
Given our interest in improving patient care outcomes, and ensuring that patients have more timely access to services, we are proposing to establish, improve, or shorten Federal prior authorization timeframes for certain payers to respond to requests. We acknowledge that many of the payers that would be affected by this proposed rule have different requirements for prior authorization decision notice and appeal timeframes, and we are proposing to align prior authorization decision timeframes across these payers.
We are proposing that, beginning January 1, 2026, MA organizations and applicable integrated plans, Medicaid FFS programs, and CHIP FFS programs must provide notice of prior authorization decisions as expeditiously as a patient's health condition requires, but no later than 7 calendar days for standard requests. We also propose that Medicaid FFS and CHIP FFS programs must provide notice of prior authorization decisions as expeditiously as a patient's health condition requires, but no later than 72 hours for expedited requests unless a shorter minimum time frame is established under state law.
Assuming these proposals are finalized as proposed, we believe the 7-calendar day timeframe for standard decisions could be achieved when payers implement their APIs with improved access to documentation requirements, which could support greater use of electronic prior authorization, and more efficient business processes once implemented. For MA organizations, on or after January 1, 2026, items and services covered by the proposals in 42 CFR 422.122 would be affected by this proposal if finalized; for all other items and services existing timeframes would remain applicable.
Our proposal would not change the 72-hour deadline required by current Federal regulations, or the authority for an extension of that deadline, for expedited decisions made by MA organizations, applicable integrated plans, Medicaid managed care plans, and CHIP managed care entities. In addition, we do not propose to change existing Federal timeframes for standard and expedited determinations on requests for Part B drugs for MA organizations and applicable integrated plans; current regulations require notice to the enrollee as expeditiously as the enrollee's health condition requires, but no later than 72 hours after receiving the request for a standard determination and as expeditiously as the enrollee's health condition requires, but no later than 24 hours after receiving an expedited request.
For MA plans and applicable integrated plans, the timeframes would continue to apply to the notice that must be provided to the enrollee, while for Medicaid managed care plans and CHIP managed care entities, existing regulation requires that notices must be provided to both the provider and to the enrollee.
We are not proposing to change timeframes for prior authorization processes for QHPs on the FFEs, in part because existing regulations at 45 CFR 147.136 establish internal claims and appeals processes, external review processes, and pre-service claims requirements for all non-grandfathered group and individual market plans or coverage. Specifically, individual health insurance issuers are required to meet minimum internal claims and appeals standards.
We are not proposing to require that impacted payers approve a request for prior authorization should that payer not meet the required standard or expedited decision timeframe. If a payer fails to meet the timeline for approval or other decision, providers should contact the payer to obtain the status of the request and determine if supporting documentation is needed to complete processing of the authorization or if there are other reasons for the delay in a decision. We do not believe it is practical to require payers to default to an approval for prior authorization requests for which a timely response has not been provided. Therefore, impacted payers may choose to evaluate process improvements to meet the proposed timeframes and API in this proposed rule, and consider how to efficiently support provider inquiries on status should responses or timeframes be missed. However, we note that some programs, such as Medicare Advantage, have regulations which include provisions for the failure to provide timely notice of an organization determination, which constitutes an adverse decision that may be appealed.
We seek comment on what administrative, regulatory, technical, governance, operational, and workflow solutions would need to be addressed, for and by payers, to comply with the proposed timeframes for handling prior authorization review and approval activities. We also seek comment on what operational or procedural changes payers or providers would need to make in their workflows or systems to reduce decision timeframes from 14 days to 7 calendar days (for standard prior authorization requests) and from 72 hours to 1 day or 24 hours (for expedited prior authorization requests). Based on comments we received in response to the December 2020 CMS Interoperability rule (85 FR 82586), many providers wish to see further improvements in the timeliness of the decision process for prior authorizations. Some commenters, including payers, believe it is possible, given advances in technology, that responses to certain types of prior authorization requests could be made within 24 hours. Some payer and provider commenters agree that shorter prior authorization decision timeframes than those in this proposed rule could help to improve patient care, reduce burden, and improve equity. We wish to learn more about the process and technology barriers which prevent payers from meeting shorter timeframes than those in this proposed rule, and request input on whether MA organizations, applicable integrated plans, Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities might be able to provide notice of standard and expedited prior authorization decisions within, for example, 5 calendar days and 48 hours, respectively, and if not, what specific issues and obstacles prevent that.
We believe that as prior authorization processes become more efficient, shorter timeframes may be possible for certain types of requests. For example, if early adopters voluntarily implement and test the proposed PARDD API, and if some impacted payers voluntarily implement process improvements in methods of provider communication, automation, and documentation submission requirements, those payers may be able to accommodate shorter timeframes for certain types of prior authorization requests. Therefore, we solicit comments on whether implementation of the PARDD API as described in this proposed rule could yield process improvements of sufficient magnitude to support shorter decision timeframe requirements for prior authorization requests as suggested by many stakeholders, including payers, providers, vendors, and other interested parties, and described in reports cited earlier. We also seek comment on anticipated operational challenges of implementing the API that might affect a payer's ability to meet the proposed timeframes. Finally, we request comment from the public regarding the costs, benefits, and operational impact on providers and payers, as well as the impact on patients, of making and communicating prior authorization
In summary, to address prior authorization decision timeframes, we are proposing to require, beginning January 1, 2026, that MA organizations and applicable integrated plans, Medicaid FFS programs, and CHIP FFS programs must provide notice of prior authorization decisions as expeditiously as a beneficiary's health condition requires (for CHIP FFS, alternatively stated as in accordance with the medical needs of the patient), but no later than 7 calendar days for standard requests. We are proposing that Medicaid FFS and CHIP FFS programs must provide notice of prior authorization decisions as expeditiously as a beneficiary's health condition requires (for CHIP, alternatively stated as in accordance with the medical needs of the patient) but no later than 72 hours for expedited requests unless a shorter minimum time frame is established under state law. We are proposing to require that the same maximum timeframes apply to standard authorization decisions by Medicaid managed care plans and CHIP managed care entities beginning with the rating period that starts on or after January 1, 2026. Because Medicaid managed care plans at 42 CFR 438.210(d)(2) and CHIP managed care entities at § 457.1260(c)(3) respectively must already make an expedited authorization decision and provide notice as expeditiously as the beneficiary's health condition requires but no later than 72 hours after receipt of the request for service, we are not proposing to change those specific timeframes. However, for consistency with Medicaid FFS, we propose to add “unless a shorter minimum time frame is established under State law” to 42 CFR 438.210(d)(2).
We are proposing to amend 42 CFR 438.210(d)(2)(i) to clarify that the MCO, PIHP, or PAHP must make these decisions on shorter timeframes if required by the state. These proposals for the impacted payers in this proposed rule are being made at the CFR sections identified in Table 7.
If state law imposes a shorter timeframe for these decisions, that shorter time frame would govern for Medicaid FFS, CHIP FFS, Medicaid managed care plans, and CHIP managed care entities. If our proposed regulation is finalized as proposed, and state law imposes a longer time frame, payers could comply with both the Federal and state regulations by complying with the shorter Federal time frame. State laws would not apply to MA plans, based on preemption language at 42 CFR 422.402 which states that the standards established for MA plans supersede any state law or regulation (other than state licensing laws or state laws relating to plan solvency) with respect to the MA plans that are offered by MA organizations. Therefore, MA plans would not be required to comply with timeframes imposed by the states, but rather with the time frames set by this proposed rule.
We are not proposing to change any existing Federal timeframes that might apply to expedited authorization decisions made by any of the impacted payers, especially given that many of these payers already apply a 72-hour maximum timeframe for such requests. To ensure consistency and correctly describe the new timeframes being proposed for these payers to provide notice of standard determinations, we are proposing a corresponding amendment to the CFR sections identified in Table 7. Specifically, an MA plan must automatically transfer a request to the standard timeframe if the MA plan denies a request for an expedited organization determination or an applicable integrated plan denies a request for an expedited integrated organization determination. This step to automatically transfer expedited requests to the standard timeframe does not apply to the Medicaid and CHIP managed care provisions listed in Table 7 since the provision at 42 CFR 438.210(d)(2) requires managed care plans to make an expedited authorization decision no later than 72 hours after receipt of the request if the provider requesting the authorization indicates that following the standard timeframe could seriously jeopardize the beneficiary's life or health or ability to attain, maintain, or regain maximum function.
This section proposes requirements for the timing of notifications sent by certain payers to patients regarding prior authorization decisions. This proposal also applies to most impacted payers. However, we are not proposing to address proposals for notifications to the QHPs on the FFEs, for the same reasons we provided in section II.D.5.b.
MA organizations are currently required to provide notifications to enrollees of decisions regarding coverage, called organization determinations, which includes decisions regarding prior authorizations. To support more timely decisions and communication of those decisions, we propose to amend the CFR sections identified in Table 5 to require MA organizations to notify the enrollee of its determination as expeditiously as the enrollee's health condition requires, but no later than 7 calendar days after the organization receives the request for a standard pre-service organization determination for a medical item or service. We are also proposing to revise 42 CFR 422.568 and move the existing language at 42 CFR 422.568(b)(1)(i) and (ii) to 42 CFR 422.568(b)(2). We propose to move the language previously at 42 CFR 422.568(b)(2) to new paragraph (b)(3). We emphasize that this proposed change to the regulation text structure does not change current requirements and that this proposed 7 calendar day timeframe would remain subject to the existing requirements (currently at 42 CFR 422.568(b)(1)(i), proposed to be at 42 CFR 422.568(b)(2)) related to the limited circumstances under which an MA organization may extend the adjudication timeframe by up to 14 additional calendar days. We are not proposing to change the current 72-hour decision timeframe for expedited requests or the availability of the 14-calendar day extension to make a determination under 42 CFR 422.568 for standard requests and 42 CFR 422.572 for expedited requests.
Other than the proposal to require an MA plan to send notification of prior authorization decisions to providers electronically in section II.D.3.a. of this proposed rule, we are not proposing changes to the requirements for an MA plan to notify enrollees of decisions on organization determinations. For example, should an MA plan deny a prior authorization request, it must send written notice to the enrollee under the requirements for standard requests at 42 CFR 422.568(d) and (e) and for expedited requests at 42 CFR 422.572(e).
Consistent with policies for MA organizations, we are proposing enrollee notification requirements for the integrated organization determination process described at 42 CFR 422.631. Specifically, we propose to amend the CFR sections identified in Table 5 to state that when a provider makes a request for an item or service, the applicable integrated plan must notify the enrollee of its determination as expeditiously as the enrollee's health condition requires, but no later than 7 calendar days after the organization receives the request for a standard pre-service organization determination regarding coverage for a medical item or service. We are not proposing to change the current 72-hour requirement for decisions and notice on expedited requests at 42 CFR 422.631(d)(2)(iv)(A). Under our proposal, the authority for a
For the Medicaid FFS program we are proposing, at the CFR sections identified in Table 5, to specify regulatory timeframes to provide notice of decisions on both expedited and standard prior authorization requests. The new requirements would apply to prior authorization decisions beginning January 1, 2026.
Under this proposal for Medicaid FFS, which would appear at 42 CFR 440.230(e)(1), notice of the state Medicaid program's decision regarding an expedited request for prior authorization would have to be communicated as expeditiously as a beneficiary's health condition requires, but no later than 72 hours after receiving a provider's request for an expedited determination, unless a shorter minimum time frame is established under state law. Notice of a decision on a standard request for a prior authorization would have to be communicated to the requesting provider as expeditiously as a beneficiary's health condition requires, but no later than 7 calendar days after receiving the request, unless a shorter minimum time frame is established under state law. If the state determines that it needs additional information from a provider to make a decision, or if the beneficiary or provider requests an extension, the proposed decision-making and communication timeframe for a standard request could be extended by up to 14 calendar days. Such extensions may be justified and in the beneficiary's interest if medical evidence from outside providers is needed to support the request, or there are other circumstances identified by either the provider or the beneficiary.
Independent of this proposed rule's API proposals and their application to Medicaid prior authorization requests, Medicaid has longstanding beneficiary notice and fair hearing regulations. CMS has interpreted these existing regulations to apply to prior authorizations requests for Medicaid FFS, and expects to do so in the future. These existing Medicaid beneficiary notice and fair hearing requirements will remain in full effect without change, regardless of how or if the API proposals are finalized.
Specifically, the current Medicaid notice regulations at 42 CFR 435.917 apply to all prior authorization decisions and require a state to provide the beneficiary with timely and adequate written notice of any decision regarding the beneficiary's prior authorization request, as any such decision would cause a “denial or change in benefits and services.”
Existing regulations at 42 CFR 431.220(a)(1) require the state to provide beneficiaries the opportunity to request a fair hearing if the state fails to act on a claim with reasonable promptness. We consider a prior authorization request a type of claim. Therefore, beneficiaries have the right to a fair hearing when the state fails to make prior authorization decisions with reasonable promptness.
Existing regulations at 42 CFR 431.220(a)(1) require that states grant Medicaid beneficiaries the opportunity for a fair hearing whenever a state takes an action as defined in 42 CFR 431.201. This definition includes “a termination, suspension of, or reduction in covered benefits or services,” which, in turn, includes any termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization. Under existing regulations at 42 CFR 431.211, a state must provide an individual at least 10 days advance notice prior to taking an action and must afford the beneficiary the right to the continuation of services pending the resolution of the state fair hearing, in accordance with 42 CFR 431.230. Therefore, the state must provide advance notice to beneficiaries of any termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization and must afford the beneficiary the right to request a fair hearing, in accordance with 42 CFR part 431, subpart E. This advance notice requirement would not be affected by any of the proposed changes in this proposed rule.
To make it explicit that existing Medicaid beneficiary notice and fair hearing rights apply to Medicaid FFS prior authorization decisions, independent of the notification timeframe proposals elsewhere in this proposed rule, we are proposing several clarifying updates to the existing regulations at 42 CFR 431.201, 431.220, and 431.917, and a new 42 CFR 440.230(e)(2). These proposed changes, if finalized as proposed, would not change Medicaid notice or fair hearing policy or operational requirements for states. Additionally, these proposed changes, if finalized as proposed, would be applicable upon the effective date of the final rule, and thus would take effect sooner than the proposed timeframes for issuing provider notice of a prior authorization decision in 42 CFR 440.230(e)(1). Finally, we note that these proposed Medicaid beneficiary notice and fair hearing regulation changes seek only to clarify, not change, existing policy. Therefore, our interpretation of how existing regulations apply to Medicaid FFS prior authorization decisions, as previously described, applies today and will continue to apply in the future,
We propose the following changes to clarify how existing Medicaid beneficiary notice and fair hearing regulations apply to Medicaid FFS prior authorization decisions:
• Modification of the headers in 42 CFR 435.917 to clarify that the information in this section relates broadly to eligibility, benefits, and services notices. Specifically, we propose to remove the word “eligibility” from the headers of paragraphs (a) and (b) of 42 CFR 435.917 to reflect the content of these paragraphs more accurately.
• Revision of the definition of an “action” at 42 CFR 431.201 to include termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization. We also propose to revise the definition of the term “action” to improve readability by numbering the components of the definition, rather than listing them in a single paragraph.
• Modification of 42 CFR 431.220 to add a new paragraph (a)(1)(vi) to add prior authorization decisions to the list of situations in which a state must provide the opportunity for a fair hearing in circumstances where the beneficiary believes the agency has taken an action erroneously, denied their claim for eligibility or for covered benefits or services, or issued a determination of an individual's liability, or has not acted upon the claim with reasonable promptness.
• Revision of 42 CFR 435.917(b)(2) to include, among the types of notices that need to comply with the requirements of 42 CFR 431.210, a reference to denials of, or changes in, benefits and services for beneficiaries receiving medical assistance. This would ensure that individuals receiving medical assistance who are denied benefits or services would receive a notice that includes the content at 42 CFR 431.210, which requires that notices include a clear statement of the specific reasons supporting the intended action.
• Addition of a new 42 CFR 440.230(e)(2) to specify that states must provide beneficiaries with notice of the Medicaid agency's prior authorization decisions in accordance with 42 CFR 435.917 and provide fair hearing rights, including advance notice, in accordance with 42 CFR part 431, subpart E.
We make these proposed changes at the CFR sections identified in Table 6.
Readers are reminded that the Medicaid beneficiary notice requirements at 42 CFR 435.917 and 431.210 through 431.214, including all proposed revisions and additions, such as the proposal at 42 CFR 440.320(e)(2) previously discussed, apply to the written notice provided by the state to the beneficiary. These requirements, including the provision of fair hearing rights, are long-standing and exist independently of the proposed PARDD API provisions of this proposed rule, which represents an interaction between the payer and the provider. Nor do the Medicaid beneficiary notice requirements conflict with the communication of denial reasons to the provider under the proposals in section II.D.4.a. of this proposed rule.
The current application of existing notice and fair hearing requirements to Medicaid FFS prior authorization decisions, including the proposed clarifications as previously discussed, is consistent with current regulations for notice and appeal rights for managed care prior authorization decisions. These are sometimes referred to as service authorizations or adverse benefit determinations.
In summary, our existing Medicaid beneficiary notice and fair hearing regulations apply to Medicaid FFS prior authorization decisions. We propose several revisions and additions to these regulations that would clarify, but not change, their application to Medicaid FFS prior authorization decisions. These include revisions to the definition of “action” and making explicit that prior authorization denials are subject to the same notice and fair hearing rights as other denials of services. These revisions would become applicable upon the effective date of the final rule. We are proposing these clarifications regarding the application of existing Medicaid beneficiary notice and fair hearing requirements at the CFR sections identified in Table 6. We seek comments both on our proposals and on how states currently apply these notice and fair hearing rights to prior authorization decisions.
To implement the proposed authorization timeframes for Medicaid managed care, we also propose to revise the CFR sections identified in Table 5. Under our proposal, the new timeframes for Medicaid managed care plans to provide notice of decisions on standard (non-expedited) prior authorization requests would apply beginning with the rating period that starts on or after January 1, 2026.
We propose to revise 42 CFR 438.210(d)(1) to reflect that, beginning with the rating period that starts on or after January 1, 2026, managed care plans must provide notice of standard authorization decisions within state-established timeframes that may not exceed 7 calendar days following the plan's receipt of the request for service. We propose to specify the standard authorization requirements by compliance date by leaving the section header “Standard authorization decisions” as 438.210(d)(1) and redesignating standard authorization timeframes as 438.210(d)(1)(i)(A) and (B). We also proposed to redesignate authorization decision timeframe extensions from § 438.210(d)(1)(i) and (ii) to § 438.210(d)(1)(ii)(A) and (B) and proposed to make slight revisions to the text for readability. Our proposal would not change the current provisions for how failure to issue a decision within the required timeframe constitutes an adverse benefit determination that can be appealed under 42 CFR 438.404(c)(5). Section 438.404 and other regulations governing appeal rights in 42 CFR part 438, subpart F, would continue to apply. This is also consistent with how the definition of “adverse benefit determination” in 42 CFR 438.400(b) includes a Medicaid managed care plan failing to make an authorization decision within the regulatory timeframes. We note that under current regulations at 42 CFR 438.3(s)(1) and (6) and 438.210(d)(3), Medicaid managed care plans must also comply with the requirements in section 1927 of the Act regarding coverage and prior authorization of covered outpatient drugs. Nothing in this proposed rule would change these requirements. Finally, because some Medicaid MCOs are applicable integrated plans as defined in 42 CFR 438.2, our proposal related to 42 CFR 422.631(d) would apply to those plans.
We are not proposing to change the required timeframes for expedited decisions at 42 CFR 438.210(d)(2), but we are proposing to amend the CFR sections identified in Table 5 to clarify that the MCO, PIHP, or PAHP must make these decisions on shorter timeframes if the state requires shorter timeframes. However, as described previously, we are soliciting comment on the possible alternative of a shorter time frame of 48 hours maximum, and would use that information to determine if expedited decisions should be required in less time, and as expeditiously as the beneficiary's condition requires. We are not proposing any changes to the authority
To implement the proposed prior authorization timeframes for CHIP, we propose to revise certain policies affecting the timing for making decisions on prior authorization requests under the CHIP Fee-for-Service and Managed Care program. These changes are summarized in Table 5. Beginning on January 1, 2026, decisions related to prior authorization of health services would be required to be completed in accordance with the medical needs of the patient, but no later than 7 calendar days after receiving the request for a standard determination and 72 hours after receiving the request for an expedited determination, unless an alternative option is preferred by industry based on public comments. If a beneficiary requests an extension of a prior authorization review, or if the provider or health plan determines that additional information is needed for such review, an extension of up to 14 calendar days may be granted. We propose to remove the option for states to follow existing state law regarding prior authorization of health services, requiring states to instead follow these updated timeframes. However, if state laws are more stringent than our proposal, states would be allowed to apply and enforce those shorter timeframes for prior authorization responses. We believe timely prior authorization decisions are an important beneficiary protection, and CHIP beneficiaries should be afforded the same decision timeframes as Medicaid and Medicare beneficiaries.
Existing CHIP regulations at 42 CFR 457.1130(b) require a state to ensure that a beneficiary has an opportunity for external review of health services matters, including a delay, denial, reduction, suspension, or termination of health services, in whole or in part, including a determination about the type or level of service. Under this regulation, CHIP beneficiaries must have an opportunity for external review of prior authorization decisions. We are not proposing any changes to this requirement, as it already applies to decisions related to the prior authorization of services.
Overall, we believe that the decision and notification timeframes proposed for certain impacted payers in this rule would help ensure that prior authorization processes do not inappropriately delay patient access to necessary services. Introducing prior authorization decision timeframes that are the same across these impacted payers for items and services that require prior authorization would also help providers better organize and manage administrative resources and thus may make more time available for providers to render patient-centered care. We believe these proposals would make substantive improvements to the care experience for patients and lead to better health outcomes. In turn, better health outcomes would contribute to more efficient use of program resources.
We request comments on these proposals, specifically comments that would provide insight on any unintended consequences of these proposed policies to improve the decision or notification timeframes for prior authorizations.
Should our proposals regarding the PARDD API be finalized as proposed, we would strongly encourage state Medicaid and CHIP FFS programs to implement the PARDD API as soon as possible, due to the many anticipated benefits of the API discussed in this section. However, we also recognize that state Medicaid and CHIP FFS agencies may face certain unique circumstances that would not apply to other impacted payers. To address these concerns, we are proposing a process through which states may seek an extension of, and, in specific circumstances, an exemption from, the PARDD API requirements. We propose the following:
At the regulation citations identified in Table 7, we propose to provide state Medicaid FFS and CHIP FFS programs the opportunity to request a one-time extension of up to 1 year to implement the PARDD API specified at 42 CFR 431.80(b) and 457.732(b). Some states may be unable to meet the proposed compliance date due to challenges related to securing needed funding for necessary contracting and staff resources in time to develop and implement the API requirements, depending on when the final rule is published in relation to a state's fiscal year, legislative session, budget process, and related timeline. Some states may need to initiate a public procurement process to secure contractors with the necessary skills to support a state's implementation of these proposed API policies. The timeline for an openly competed procurement process, together with the time needed to onboard the contractor and develop the API, can be lengthy for states. A state might need to hire new staff with the necessary skillset to implement this policy. The time needed to initiate the public employee hiring process, vet, hire, and onboard the new staff may make meeting the proposed compliance timeline difficult because, generally speaking, public employee hiring processes include stricter guidelines and longer time-to-hire periods than other sectors.
Should the proposal for this API be finalized as proposed, states would be permitted to submit a written application for a one-time, one-year extension as a part of their annual APD for MMIS operations expenditures. The state's request would have to include the following: (1) a narrative justification describing the specific reasons why the state cannot reasonably satisfy the requirement(s) by the compliance date, and why those reasons resulted from circumstances that are unique to the agency operating the Medicaid and/or CHIP FFS program (versus other types of impacted payers); (2) a report on completed and ongoing state implementation activities to evidence a good faith effort toward compliance; and (3) a comprehensive plan to meet the PARDD API requirements no later than 1 year after the compliance date.
Under this proposal, CMS would approve an extension if, based on the information provided in the APD, CMS determines that the request adequately establishes a need to delay implementation, and that the state has a comprehensive plan to implement the proposed requirements no later than 1 year after the compliance date. We also solicit comments on whether our proposal would adequately address the unique circumstances that affect states and that might make timely compliance with the proposed API requirement difficult for states.
At the CFR sections identified in Table 7, we propose to permit state Medicaid FFS programs to request an exemption from the PARDD API requirements when at least 90 percent of the state's Medicaid beneficiaries are enrolled in Medicaid managed care organizations as defined in 42 CFR 438.2. Likewise, we propose that separate CHIP FFS programs could request an exemption from the PARDD API requirements if at least 90 percent of the state's separate CHIP beneficiaries are enrolled in CHIP managed care entities as defined at 42 CFR 457.10. In this circumstance, the time and resources that the state would need to expend to implement the PARDD API requirements for a small FFS population may outweigh the benefits of
We acknowledge that the proposed exemption could mean that most beneficiaries enrolled with exempted Medicaid or CHIP FFS programs, would not receive the full benefits of having this API available to facilitate the prior authorization exchange between payers and providers. To address this, we propose that states that are granted an exemption would be expected to implement an alternative plan to enable the efficient electronic exchange and accessibility of prior authorization information for those beneficiaries who are served under the FFS program and to ensure that enrolled providers will have efficient electronic access to the same information through other means, to help ensure that Medicaid or CHIP services are provided with reasonable promptness and in a manner consistent with the simplicity of administration and in the best interests of those beneficiaries who are served under the FFS program.
We propose that a state could submit a written request for an exemption from the requirements for the PARDD API as part of its annual APD for MMIS operations expenditures prior to the date by which the state would otherwise need to comply with the requirements (which may be extended by 1 year if the state receives an extension). For Medicaid exemption requests, the state would be required to include documentation that it meets the criteria for the exemption based on enrollment data from the most recent CMS “Medicaid Managed Care Enrollment and Program Characteristics” report. For a CHIP FFS exemption, the state's request would have to include enrollment data from Section 5 of the most recently accepted state submission to the CARTS. The state would also be required to include in its request, information about an alternative plan to ensure that providers will have efficient electronic access to the same information through other means while the exemption is in effect. CMS would grant the exemption if the state establishes to CMS's satisfaction that it meets the criteria for the exemption and has established such an alternative plan.
Once an exemption has been approved, we propose that the exemption would expire if either of the following two scenarios occurs: (1) based on the 3 previous years of available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data, the State's managed care enrollment for 2 of the previous 3 years is below 90 percent; or (2) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data.
For the first scenario, CMS recognizes that there may be circumstances where a state's managed care enrollment may fluctuate slightly below the 90 percent threshold in 1 year, and yet return to above 90 percent the next year. To help reduce the possible burden on exempted states experiencing this type of temporary fluctuation in managed care enrollment, CMS would consider data from the 3 previous years of available, finalized Medicaid T-MSIS and/or CHIP CARTS managed care and FFS enrollment data. We propose that if the state's managed care enrollment for 2 of the previous 3 years is below 90 percent, the state's exemption would expire.
We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the PARDD API exemption when data confirm that there has been a shift from managed care enrollment to FFS enrollment resulting in the State's managed care enrollment falling below the 90 percent threshold for 2 of the previous 3 years. We propose that the written notification be submitted to CMS within 90 days of the finalization of the first annual Medicaid T-MSIS managed care enrollment data and/or the CARTS report for CHIP confirming that there has been the requisite shift from managed care enrollment to FFS enrollment in 2 of the 3 previous years.
For the second scenario, we recognize that there may be state plan amendments, waivers, or waiver amendments that would result in a shift from managed care enrollment to FFS enrollment. Additionally, there may be instances where anticipated enrollment shifts may not be fully realized due to certain circumstances. We propose that a state would be required to provide written notification to CMS that the state no longer qualifies for the PARDD API exemption when data confirm that there has been a shift from managed care enrollment to FFS enrollment as anticipated in the state plan amendment or waiver approval. We propose that the written notification be submitted to CMS within 90 days of the finalization of the first annual Medicaid T-MSIS managed care enrollment data and/or the CARTS report for CHIP confirming that there has been the requisite shift from managed care enrollment to FFS enrollment.
Regardless of why the exemption expires, if it expires, the state would be required to obtain CMS's approval of a timeline for compliance with the PARDD API requirements for the state's Medicaid FFS and/or CHIP FFS populations within two years of the expiration date of the exemption.
For Medicaid and CHIP managed care, we are not proposing an extension process because we believe that managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the existing requirements at 42 CFR parts 438 and 457 and because many of these plans might benefit from efficiencies based on the variety of plan types that they offer. Many managed care plans are part of parent organizations that maintain multiple lines of business, including Medicaid managed care plans and plans sold on the Exchanges. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25607, 25612, and 25620), work done by these organizations can benefit all lines of business and, as such, we do not believe that the proposals in this rule impose undue burden or could not be achieved by the compliance date. We are soliciting comments on our assumptions regarding the scope of resources and ability of managed care parent organizations to achieve economies of scale when implementing the proposed API.
Further, we seek comment on whether an extension process would be warranted for certain managed care plans to provide additional time for the plan to comply with the proposed requirement at 42 CFR 438.80(b) (which cross references 42 CFR 438.242(b)(7)) for Medicaid managed care plans and at proposed 42 CFR 457.732(b) (which would cross reference 42 CFR 457.1233(d)) for CHIP managed care entities. While we are not proposing such a process for managed care plans and entities and do not believe one is necessary, we are open to evaluating options for possible future rulemaking. Were we to adopt an extension process for these managed care plans and entities, what criteria should a managed care plan or entity meet to qualify for an extension? Should the criteria include
We request comment on the proposed extension and exemption processes.
For QHP issuers on the FFEs, we propose an exception process to the PARDD API proposal at the regulation citations identified in Table 7. We propose that if an issuer applying for QHP certification to be offered through an FFE believes it cannot satisfy the proposed requirements at 45 CFR 156.223(b) for the PARDD API, the issuer would have to include as part of its QHP application a narrative justification describing the reasons why the issuer could not reasonably satisfy the requirements for the applicable plan year, the effect of non-compliance upon providers and enrollees, the current or proposed means of providing health information to providers, and solutions and a timeline to achieve compliance with the requirements of this section. We propose that the FFE may grant an exception to the requirements at 45 CFR 156.223(b) for the PARDD API if it determines that making qualified health plans of such issuer available through such FFE is in the interests of qualified individuals in the state or states in which the FFE operates, and an exception would be warranted to permit the issuer to offer qualified health plans through the FFE. This proposal would be consistent with the exception for QHP issuers on the FFEs that we finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule (85 FR 25552). For instance, as noted in that final rule, that exception could apply to small issuers, financially vulnerable issuers, or new entrants to the FFEs that demonstrate that deploying FHIR API technology consistent with the required interoperability standards would pose a significant barrier to the issuer's ability to provide coverage to patients, and not certifying the issuer's QHP or QHPs would result in patients having few or no plan options in certain areas. We believe that having a QHP issuer offer QHPs through an FFE generally is in the best interest of patients and would not want patients to have to go without access to QHP coverage because the issuer was unable to implement this API.
In summary, we propose to permit certain impacted payers (state Medicaid and CHIP FFS programs and QHP issuers on the FFEs) to apply for an extension, exemption, or exception, as applicable, from implementing the proposed PARDD API. We propose that these programs would submit and be granted approval for an extension or exemption as part of applicable established processes. We propose that submission requirements would include certain documentation identified in the regulatory citations in Table 7.
We are proposing to require impacted payers to publicly report certain aggregated metrics about prior authorization by posting them directly on the payer's website or via a publicly accessible hyperlink(s). This proposed reporting would be at the organizational level for MA, the state level for Medicaid and CHIP FFS, the plan level for Medicaid and CHIP managed care, and the issuer level for QHP issuers on the FFEs. We propose these levels of reporting for each impacted payer because we believe these represent the appropriate organizational level for which aggregated data would be meaningful to a patient or provider to understand an entity's performance on timeframes for approvals, on volumes of denials and appeals for prior authorization.
For example, an MA organization will generally have multiple contracts and it is not uncommon for these organizations to have more than one contract for the same service area. Ideally, reports would present true aggregate figures, which would be at the organizational level. Medicaid and CHIP managed care would be reported at the plan level so that beneficiaries could compare and states could evaluate plans within the state. QHP issuers report on quality improvement strategies consistent with standards of section 1311(g) of the Affordable Care Act (45 CFR 156.20), which is at the issuer level, and would include information for the plans under their purview. Such reporting of prior authorization data at the issuer level would be consistent with their quality reports.
Prior authorization data would be compiled from multiple sources, on multiple measures and individuals, and compiled into aggregate data, or summary data, for purposes of public reporting and statistical analysis. Payers may use the detailed information to assess their internal performance, understand trends and determine where improvements may be necessary. At the same time, they would be able to share the aggregate data for all programs with the public. We believe the availability of such data from the payers could contribute to improvements in the prior authorization process. Should this proposed rule be finalized as proposed, we believe that, as payers create and analyze these reports, there would use the data to learn about their own performance. Additionally, we believe that the public availability of prior authorization decision data would further transparency in consumer information. When some patients are looking for a new plan, they may compare several factors including, but not limited to, access to care or authorizations, premiums, benefits, and cost sharing or coinsurance. Both access to care and transparency regarding prior authorization processes could be important considerations.
Some providers may find metrics about prior authorization approvals or appeals useful when selecting payer networks, or to be aware of the trends in performance of different payers. Providers should have access to information about how they will be able to treat their patients, and whether it will be possible to do so in a manner they believe will support value-based care and services that are appropriate and necessary for each patient's health. The legal authority for requiring such public reporting is discussed further in section II.D.10. of this proposed rule.
We propose that for each metric listed, data would be reported in aggregate for all items and services. We are not proposing that payers report on categories of items and services, but rather aggregate the information as totals or percentages of total items and services, as outlined in each proposed requirement listed in this section of this rule. Aggregate data could allow each organization to examine trends and obtain insight into their own
• A list of all items and services that require prior authorization.
• The percentage of standard prior authorization requests that were approved, aggregated for all items and services.
• The percentage of standard prior authorization requests that were denied, aggregated for all items and services.
• The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.
• The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.
• The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.
• The percentage of expedited prior authorization requests that were denied, aggregated for all items and services.
• The average and median time that elapsed between the submission of a request and a determination by the payer, plan, or issuer, for standard prior authorizations, aggregated for all items and services.
• The average and median time that elapsed between the submission of a request and a decision by the payer, plan or issuer, for expedited prior authorizations, aggregated for all items and services.
We do not propose a format for how payers would present the aggregated data in the reports, but we encourage them to consider readability, and accessibility in preparing the data for viewing and comprehension. We request comments from all stakeholders, including payers, providers, and consumers, on how the information might be displayed on payer websites in a useful and meaningful manner for patients and providers, including which data would be most useful.
By having access to the requirements for prior authorization of items and services, and data about prior authorization decisions, patients and providers would have a better understanding of a payer's prior authorization review and approval processes. Such information may be helpful for some patients when making decisions at the time of open enrollment, special enrollment, or plan selection throughout the year.
The first set of data to be publicly available under our proposal would reflect current practices, rather than payer behavior based on compliance with this proposed rule. However, we anticipate that, over time, data might show improvements after implementation of our proposals regarding the PARDD API and timeframes for prior authorization decisions. In addition, year-over-year comparisons could demonstrate positive, or negative, trends, which alone could be useful information for patients who are making enrollment decisions. We acknowledge that not all patients have a choice in enrolling with payers, such as with the Medicaid and CHIP FFS programs. Nonetheless, publicly available data would aid interested providers and patients to generally understand payer performance with respect to prior authorization processes for decisions, approvals, denials, and appeals.
CMS would enforce the requirements based on the existing compliance policies for the impacted payers. To facilitate the incorporation of such data more directly into a consumer-friendly comparison tool, we may propose in future rulemaking to use these data to help develop quality measures to incorporate into quality star ratings across certain payer programs, specifically for MA and QHP issuers on the FFEs.
In summary, we propose that, beginning in 2026, and by March 31 of that year, impacted payers must annually report certain aggregated prior authorization metrics from the previous year. These reports must be posted on websites or publicly available hyperlinks. We are making this proposal at the CFR sections identified in Table 7.
For Medicaid managed care, we propose to replace the current provision at the CFR sections identified in Table 7 which addresses the applicability date for the provisions in that section, with this new requirement. The current provision was added in 2016 to clarify that the previous requirements would remain in effect until the new provisions began starting with rating periods beginning on or after July 1, 2017. As several rating periods have passed since July 1, 2017, we do not believe this clarifying text is needed. Our proposal would apply to CHIP managed care entities through operation of the cross-reference to 42 CFR 438.210, which is currently in 42 CFR 457.1230(d). We propose to accomplish this by removing the current exception for complying with paragraph 42 CFR 438.210(f). As such, the prior authorization metrics policies would be applicable to CHIP managed care through the cross-reference at 42 CFR 457.1230(d) to 42 CFR 438.210.
We request comments on the proposal for reporting metrics on prior authorization, for example, on the proposed types of data to be included in the report, on the proposal to report data in aggregate by items and services, on the proposed reporting timeframe, the number of reports, and if there are any other types of data that could be useful to payers, providers, and patients. Given that use of the PARDD API would develop over time, we also request comment on the timing for adding a metric similar to those proposed for the Patient Access API in section II.A, for the total number of prior authorization requests received via the PARDD API. This information could be useful for evaluating the degree to which API-facilitated requests would grow over time.
During the CMS listening sessions, we heard about the potential for additional opportunities for payers to support efficiencies in the prior authorization process, including discretion about when to require prior authorization and basing such decisions on data and provider performance. For example, prior authorization is sometimes required for certain items and services that are almost always approved. Some providers have demonstrated a consistent history of complying with all payer requirements for the submission of documentation to support a request. Some payers have implemented what they term “gold-carding” or similar programs to relax or reduce prior authorization requirements for providers that have demonstrated a consistent pattern of compliance. In such programs, providers are relieved of requirements to submit prior authorization requests based on data indicating their adherence to submission requirements, appropriate utilization of items or services, or other evidence-driven criteria. Stakeholders said that the prior authorization process could be significantly more efficient and cost-effective for all parties if these programs were more broadly implemented.
Under the MA program, MA organizations may develop and apply prior authorization policies, make prior authorization decisions, and have the discretion to implement gold-carding programs within each contracted plan. CMS uses a similar approach to gold-carding in the Medicare FFS Review Choice Demonstration for Home Health Services, under which home health agencies in demonstration states that select certain review choice options and have a review affirmation rate or claim approval rate of 90 percent or greater over 6 months are given the option to continue in the pre-claim review option or choose a selective post-payment review or spot check review process.
We believe the use of gold-carding and similar prior authorization reduction programs could help alleviate provider burden. We are also aware that some states have begun to enact gold-carding programs to address provider and patient complaints about access to healthcare services. We encourage payers to adopt gold-carding approaches that would allow prior authorization exemptions or more streamlined reviews for certain providers who have demonstrated compliance with requirements. By taking this step, payers could join CMS in helping to build an infrastructure that would allow clinicians to deliver care in a timely and value-based manner. We seek comment for consideration for future rulemaking on how to measure whether and how such gold-carding or prior authorization exemption programs could reduce provider and payer burden, and improve services to patients. In particular, we seek comment on how CMS and other payers could ensure that such programs benefit diverse populations, including individuals in rural areas, individuals with disabilities, individuals with chronic illnesses, small and minority providers, and providers who disproportionately serve minority and underserved communities.
To further encourage the adoption and establishment of gold-carding programs, we are considering including a gold-carding measure as a factor in quality ratings for MA organizations and QHPs as a way for these payers to raise their scores in the quality star ratings. We seek comment for potential future rulemaking on the incorporation of such a measure into star ratings for these organizations. We also considered proposing gold-carding as a requirement in payer's prior authorization policies and seek comment on how such programs could be structured to meet such a potential requirement.
Section 1856(b) of the Act directs the Secretary to establish regulatory standards for MA organizations that are consistent with, and carry out, Part C of the Medicare statute, including the provisions in section 1852 of the Act. Section 1852(a) and (d) of the Act provide for MA plans to cover medically necessary Part A and Part B benefits, including by making benefits available and accessible with reasonable promptness. Section 1852(c)(1)(G) of the Act requires that MA organizations disclose to their enrollees any rules regarding prior authorization or other review requirements that could result in nonpayment. Section 1852(g)(1)(A) of the Act requires an MA plan to have a procedure for making determinations about whether an enrollee is entitled to receive a health service, how much the enrollee is required to pay for such service and to provide an enrollee with a written notice if the plan denies coverage. Section 1852(g)(1)(A) of the Act also requires that coverage determinations be made on a timely basis. Section 1852(g)(3)(B)(iii) of the Act requires that the organization notify the enrollee (and physician involved, as appropriate) of an expedited determination under time limitations established by the Secretary, but not later than 72 hours of the time of receipt of the request. This proposal serves to ensure that MA organizations carry out their responsibilities under section 1852 of the Act in a consistent and standardized fashion.
In the interest of ensuring that MA organizations continue to use appropriate standards, process organization determinations in a timely manner, and provide enrollees with appropriate access to care under the authorities referenced earlier, we are proposing to require that MA organizations implement certain APIs that provide information about the coverage and documentation requirements for prior authorization, that they respond to prior authorization requests with the status of that request, and that they meet certain timeframes for making decisions on prior authorization requests.
We are proposing that MA organizations implement the PARDD API, using certain implementation specifications as discussed in section II.D.3.a. of this proposed rule. These implementation specifications would be expected to improve the overall prior authorization process by addressing deficiencies that exist in the process today with respect to providers' access to information about the prior authorization rules and documentation requirements. The PARDD API would communicate the coverage and documentation requirements for a prior authorization, indicating if an authorization is required for a specific item or service and what documentation is required to support an authorization request. The PARDD API would be consistent with the disclosure obligation on MA organizations in section 1852(c)(1)(G) of the Act by disclosing to providers the same information that generally must be provided to enrollees about which covered benefits are subject prior authorization and would serve the same larger purpose of ensuring access to coverage by communicating the limits and rules for covered services.
Additionally, the proposed PARDD API would be a mechanism for receiving and responding to requests for coverage determinations before the services are
Finally, section 1857(e)(1) of the Act explicitly authorizes the adoption of additional reporting requirements by MA organizations where necessary and appropriate. Our proposal to require MA plans to publicly report prior authorization metrics would enable CMS to assess implementation of the policies and attempt to determine the impact of these proposals on payers and providers. Review of these metrics could help CMS and the plans understand the impact of the proposed policies, including use of the APIs, and improved decision timeframes. The data could help plans evaluate operations, implementation of new policies and the APIs and determine what changes may be appropriate.
For Medicaid, most of these proposals are authorized by sections 1902(a)(4), (8), and (19) of the Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan; section 1902(a)(8) of the Act requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals; and section 1902(a)(19) of the Act requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients. Some proposals are also authorized by additional sections of the Act as discussed in this section of this rule.
Additionally, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to uses or disclosures that are directly connected with the administration of the program or plan. One of the implementing regulations for this section of the Act, at 42 CFR 431.302(c) states that purposes directly connected to plan administration include providing services for beneficiaries. CHIP programs are subject to the same requirements through a cross-reference at 42 CFR 457.1110(b). Medicaid and CHIP programs must also determine which programs require safeguards to apply to uses and disclosures of beneficiary data at 42 CFR 431.306. In order to meet the requirements of that regulation, states must have consistent criteria for release and use of information (which should conform to the proposed requirements for the PARDD API, if finalized). See 42 CFR 431.306(a). Access to information concerning beneficiaries must be restricted to persons who are subject to standards of confidentiality that are comparable to that of the Medicaid agency, in accordance with 42 CFR 431.306(b). The permission provision at § 431.306(d) is not relevant to the API functionality proposed in this section, in part because it pertains to a well-established administrative process conducted extensively between the enrolled providers and states currently, and the provider would not be considered an outside source. The services include those for which the state requires that a provider submit a prior authorization request, and thus needs to communicate about that prior authorization with providers enrolled with, or authorized by the state to provide care to its beneficiaries. Prior authorization can be an integral part of the Medicaid program, and facilitates access to care as well as provider payment processes. A provider enrolled with the state must meet privacy and security standards to protect the confidentiality of patient information. When requesting approval to provide certain services from the state using the state's PARDD API as described in section II.D.3.a., the provider would be able to determine if a prior authorization is required, and what supporting documentation is necessary to obtain approval for that care.
The proposed requirement for state Medicaid FFS programs and Medicaid managed care plans to implement the PARDD API is expected to improve the
The proposals to require states and Medicaid managed care plans to provide specific information to providers about the status of prior authorization requests are expected to enable providers to plan care for their patients after submitting a prior authorization request. As discussed in section II.D.4.a. of this proposed rule, providers would receive a response to an electronic prior authorization request to indicate that the request is approved, denied, or if additional information is needed. If a prior authorization has been denied, the provider would be provided information about why, so that they can either re-submit the request with updated information, identify alternatives for the patient, or appeal the decision. These proposals would improve the timeliness, clarity, and consistency of information for providers regarding prior authorization requests, help providers determine next steps for timely patient care, and reduce payer, provider, and patient burden by eliminating the need for repeated inquiries.
As discussed in section II.D.5 of this proposed rule, delayed prior authorization decisions may directly affect patient care by delaying access to treatment, services, and supplies, as well as transfers between hospitals and post-acute-care facilities. The proposed timeframes for making prior authorization decisions about items and services that require prior authorization in Medicaid FFS and managed care programs would help providers better manage administrative resources, make more time available for providers to render patient care, and facilitate faster access to services. We believe these proposals would make substantive improvements to the care experience for Medicaid beneficiaries and lead to better health outcomes. In turn, better health outcomes would contribute to more efficient use of Medicaid program resources.
We believe that the proposal to shorten the maximum amount of time for a Medicaid managed care plan to make a prior authorization decision from 14 calendar days to 7 calendar days would improve the efficient operation of the Medicaid program by facilitating faster receipt of services or filing of appeals.
Our proposal to make explicit in regulation text that current notice and fair hearing requirements apply to Medicaid FFS prior authorization decisions is authorized under section 1902(a)(3) of the Act. Section 1902(a)(3) of the Act requires that a Medicaid state plan provide for an opportunity for a fair hearing to any individual whose claim for medical assistance under the plan is denied or is not acted upon with reasonable promptness. These proposed amendments are also supported by the 14th Amendment to the United States Constitution and case law on due process, specifically,
Currently, and under our proposal, 42 CFR 438.210 applies the same appeal and grievance requirements for PIHPs and PAHPs as for MCOs; for this proposal, we rely on our authority in section 1902(a)(4) of the Act to adopt these standards for PIHPs and PAHPs. This is consistent with our prior practice for adopting standards for Medicaid managed care plans (81 FR 27507).
Additionally, section 1902(a)(17) of the Act requires state Medicaid plans to include reasonable standards for determining the extent of medical assistance under the plan that are consistent with the objectives of title XIX of the Act. As set forth at 42 CFR 440.230, the standards states establish under section 1902(a)(17) of the Act could include appropriate limits on a service based on such criteria as medical necessity or on utilization control procedures, so long as each service is sufficient in amount, duration, and scope to reasonably achieve its purpose. Items and services covered under Title XIX benefit authorities are subject to 42 CFR 440.230, unless statute or regulation expressly provides for an exception or waiver. This would include covered items and services described in sections 1905(a), 1915(c), 1915(i), 1915(j), 1915(k), 1915(l), 1937, and 1945 of the Act, and any other authorities as established by Congress. The standards that states establish under section 1902(a)(17) of the Act and 42 CFR 440.230 could include prior authorization requirements. Our proposals to establish timeframes for prior authorization decisions are authorized under section 1902(a)(17) of the Act, because they would be expected to help ensure that states make prior authorization decisions in a manner that is consistent with the requirements in section 1902(a)(4), (a)(8) and (a)(19) of the Act, thus helping to ensure that states' standards for determining the extent of medical assistance under the plan are consistent with the objectives of title XIX.
For Medicaid managed care plans, these proposals are also authorized by section 1932(b)(4) of the Act, which provides that each Medicaid managed care organization must establish an internal grievance procedure whereby a beneficiary who is eligible for medical assistance may challenge the denial of coverage or payment for such assistance. Reducing plan response time for prior authorization decisions could enable beneficiaries to file appeals if necessary, and receive resolution to those appeals sooner. The earlier an appeal is filed and the disposition known, the sooner the provider and beneficiary can determine whether to request a state fair hearing or to identify treatment alternatives, if necessary. The prior authorization proposals in this rule are also consistent with how section 1932(c)(2)(A)(i) of the Act requires MCO contracts to contain a provision for an
We are also proposing to require Medicaid FFS programs and Medicaid managed care plans to publicly report certain prior authorization metrics by posting them directly on the payer's website or via publicly accessible hyperlink(s). As discussed in section II.D.8. of this proposed rule, publicly reporting these metrics could support more timely access to services by identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action, and for managed care programs, helping beneficiaries select Medicaid managed care plans that best meet their needs, and helping some Medicaid providers make informed decisions on which Medicaid managed care plan networks to join.
Section 1902(a)(4) of the Act authorizes this proposal because enabling more timely access to services by identifying prior authorization deficiencies and facilitating the implementation of corrective action to improve the prior authorization process would support the proper and efficient operation of the state Medicaid plan. Requiring Medicaid managed care plans to publicly report their prior authorization metrics would hold them accountable and enable them to monitor their own performance and identify process improvement opportunities, which could be an integral part of implementing a quality assessment and improvement strategy more easily. This is consistent with the requirements for quality strategies for managed care programs at section 1932(c)(1)(A)(i) of the Act.
Section 1902(a)(8) of the Act authorizes this proposal because identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action as well as helping beneficiaries select a Medicaid managed care plan that best meets their needs may improve the promptness with which services are provided to beneficiaries. Section 1902(a)(19) of the Act authorizes this proposal because identifying prior authorization process weaknesses or deficiencies and enabling the implementation of corrective action would help ensure that care and services are provided in a manner consistent with simplicity of administration. Additionally, implementation of corrective action to improve prior authorization processes, helping beneficiaries select a managed care plan that best meets their needs, and helping providers make informed decisions on which Medicaid managed care plan networks to join is in the best interest of beneficiaries.
For CHIP, we propose these requirements under the authority of section 2101(a) of the Act, which sets forth that the purpose of title XXI is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. This provision authorizes us to adopt these requirements for CHIP to obtain access to program data for analysis. Such analysis supports improvements in the efficacy of CHIP programs and more efficient administration of services.
As discussed previously, we propose to require implementation of the PARDD API in section II.D.3.a. of this proposed rule to improve the prior authorization process for patients, providers, and payers by addressing deficiencies and inefficiencies that exist in the current process. Today, a payer's rules about when a prior authorization is required, and what documentation requirements must be fulfilled to submit the request, are not necessarily easily accessible for providers. The process may require manual activities including phone calls, use of portals, multiple websites, and paper manuals. These inefficient procedures take time away from actual patient care. The PARDD API would enable a provider to determine if a prior authorization was required electronically, in real time, and what the documentation requirements would be regarding such request. While we expect providers would be the primary stakeholders to benefit from this proposed API, making this information available in a standardized way and permitting access through an API would also serve the requirements in section 2101(a) of the Act that CHIP ensure access to coverage and coordinated care.
The proposed PARDD API would be a mechanism for receiving and responding to requests for coverage determinations before the services were furnished; the PARDD API would streamline the initial authorization process for the payer, by sharing this information in an easily accessible way. This would also allow the provider to know what to do if a prior authorization is required for a certain service, which would improve the provider's ability to treat the patient timely. The proposed PARDD API would enable the payer to send a real time response back to a provider, based on the request for authorization. This, too, would improve the efficiency of providing services to the patient, because the request and response would be automated, and in real time. Payer use of these APIs could ensure that a provider is able to submit a request for a prior authorization with the correct and complete documentation to avoid an incorrect submission which might result in an unnecessary denial. The PARDD API would: (i) enable providers to submit a prior authorization request faster and easier, (ii) support more timely notice to provider and beneficiary of the disposition of the prior authorization request, and (iii) permit faster scheduling of services or filing appeals, depending on the decision. The PARDD API has the potential to improve the prior authorization process by making it more efficient, including limiting the number of denials and appeals, or even eliminating requests for additional documentation, as noted elsewhere.
The safeguards for beneficiary information at subpart F of 42 CFR part 431 are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As discussed above for Medicaid, CHIP payers' and providers' data exchange through the PARDD API would be related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that when they share medical records or any other health or enrollment information pertaining to individual beneficiaries, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306.
The proposed requirement in section II.D.5.b. of this proposed rule that CHIP FFS and managed care entities meet certain timeframes to provide decisions for prior authorizations, for expedited and standard decisions would be an improvement from the current state,
Our proposal to require CHIP FFS and CHIP managed care entities to publicly report prior authorization metrics would also support the states' oversight, evaluation, and administration responsibilities. Should the reporting provisions be finalized as proposed, CMS may occasionally view some of the CHIP's FFS and CHIP websites to check for compliance, see how data is being reported, and determine if there are any trends in prior authorization changes that could be indicative of the benefits of the proposals for prior authorization policies as discussed in section II.D.8. of this proposed rule. The data may indicate use of the APIs, improvements in prior authorization numbers, or changes in total numbers, denials, and appeals.
For QHP issuers on the FFEs, we are proposing these new requirements pursuant to the authority of section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates.
The policies included here could improve the efficiency of the issuers who are certified to offer QHPs on the FFEs and improve the quality of services they provide to providers and their patients. Qualified individuals in FFEs may receive covered services more quickly, and the information may be more accurate with the use of the APIs. These proposals could improve the quality of the patient experience with their providers by increasing the efficiency in the prior authorization submission and review process. Certifying only health plans that implement FHIR APIs and adhere to the other proposals herein would be in the interests of qualified individuals in the state or states in which an FFE operates. We encourage State-based Exchanges (SBEs) to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchanges.
In section II.D.3.a. of this proposed rule, we propose that QHPs issuers on the FFEs implement an API to support the prior authorization process. The PARDD API would allow QHP issuers to communicate requirements for prior authorization more efficiently, and enable providers to similarly operate more efficiently to determine when a prior authorization is needed and locate the documentation requirements. The API could enable more accurate submission and subsequent processing of prior authorization requests, with the potential of improving delivery of services to patients. Similar to the other API proposals, certifying only health plans that implement FHIR APIs would be in the interests of qualified individuals in the state or states in which an FFE operates because of the opportunities for improvements in patient care, in alignment with the goals of the Affordable Care Act.
We are also proposing that QHP issuers on the FFEs provide a reason for denial when sending a response to a prior authorization request, to facilitate better communication and understanding between the provider and issuer. This could enable efficient resubmission of the prior authorization request with additional information or an appeal, which could more promptly facilitate the needed patient care.
Finally, the proposal to require QHP issuers on the FFEs to publicly report prior authorization metrics in section II.D.8. of this proposed rule would hold issuers accountable to their providers and patients, which could help these organizations improve their program administration. These data could help QHP issuers evaluate their processes and determine if there are better ways to leverage the APIs, including the quality and sufficiency of the coverage and documentation information included in the APIs.
In the December 2020 CMS Interoperability proposed rule (85 FR 82639), we requested comment on ways in which CMS can incentivize the use of electronic prior authorization solutions by healthcare providers. We sought comment on whether the Quality Payment Program (QPP) Merit-based Incentive Payment System (MIPS) for MIPS eligible clinicians or the Conditions of Participation/Conditions for Coverage requirements for eligible hospitals and other providers would be the appropriate mechanism for new or additional policies that would promote the use of prior authorization APIs. Commenters expressed support for incentivizing healthcare providers to use these processes and tools to improve prior authorization processes. They noted that provider participation and health information technology are critical to promoting the widespread adoption of electronic prior authorization solutions. CMS considered both approaches outlined in that RFI (85 FR 82639) aimed at adopting and using electronic prior authorization processes. We believe that requiring healthcare providers, including clinicians and hospitals, to use these API functions for prior authorization is critical to ensuring the success and widespread adoption of this technology.
As discussed in section II.D. of this proposed rule, the current prior authorization process needs improvement to reduce the burden associated with the process itself. According to a 2020 American Medical Association (AMA) survey, 94 percent of respondents experienced patient care delays associated with processing prior authorizations, and 79 percent indicated having at least one experience of abandoned patient care due to onerous prior authorization processes.
As mandated by section 4001 of the 21st Century Cures Act (Pub. L. 114-255), ONC published the Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs in February 2020.
As described in section II.D. of this proposed rule, stakeholders who participated in listening sessions conducted by CMS, including payers, providers, patients, and other industry representatives, noted that there are aspects of prior authorization processes that may be improved. For example, the information required by payers to evaluate or review a prior authorization can be inconsistent between payers, so it can be difficult for providers to determine the rules and required documentation. Further, submitting a prior authorization request relies on multiple cumbersome submission channels, including payer-specific web-based portals, telephone calls, and fax exchange technology. This process can be duplicative for providers who must re-submit prior authorization requests when patients change payers. To pursue these recommendations and facilitate needed improvements in the prior authorization process, in section II.D. of this proposed rule, we propose requiring impacted payers to implement and maintain a PARDD API. The PARDD API aims to improve care coordination and shared decision-making by enabling enhanced electronic documentation discovery and facilitating electronic prior authorization. This is discussed in more detail in section II.D. of this proposed rule. We believe the PARDD API would reduce administrative burden, improve efficiency, and ensure patients promptly receive necessary medical items and services. However, as noted in the December 2020 CMS Interoperability proposed rule (85 FR 82639), we recognize that efficiencies from payer implementation of these APIs will only be realized if they are utilized by requesting providers to complete prior authorization requests.
Therefore, in this proposed rule, we propose a new measure for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS, as well as for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program, related to electronic prior authorization. We intend for the new measure, titled “Electronic Prior Authorization,” to be included in the Health Information Exchange (HIE) objective for the MIPS Promoting Interoperability performance category and in the HIE objective for the Medicare Promoting Interoperability Program. This measure aims to address stakeholder concerns regarding possible low provider utilization of APIs established by payers for electronic prior authorization, as described in letters from commenters in response to the December 2020 CMS Interoperability proposed rule (85 FR 82586).
MIPS is authorized under section 1848(q) of the Act. As described in sections 1848(q)(2) and (5) of the Act, we evaluate the performance of MIPS eligible clinicians in four performance categories, which we refer to as the quality, cost, improvement activities, and Promoting Interoperability performance categories. Under § 414.1375(b)(2), MIPS eligible clinicians must report on objectives and measures as specified by CMS for the Promoting Interoperability performance category. We refer readers to the Calendar Year (CY) 2023 Physician Fee Schedule (PFS) final rule (87 FR 70075 through 70080) for a list of the current objectives and measures for the Promoting Interoperability performance category. We determine a final score for each MIPS eligible clinician based on their performance in the MIPS performance categories and apply a payment adjustment (which can be positive, neutral, or negative) for the covered professional services they furnish based on their final score.
The Medicare Promoting Interoperability Program for eligible hospitals and CAHs are authorized in part under sections 1886(b)(3)(B)(ix) and 1814(l)(4) of the Act. Under these statutory provisions, eligible hospitals and CAHs that do not successfully demonstrate meaningful use of CEHRT are subject to Medicare payment reductions. To demonstrate meaningful use of CEHRT, eligible hospitals and CAHs must satisfy objectives and measures as required under 42 CFR 495.24. We refer readers to the Fiscal Year (FY) 2023 Hospital Inpatient Prospective Payment System (IPPS) and Long-Term Care Hospital (LTCH) final rule (87 FR 49350) for a summary of the current objectives and measures for the Medicare Promoting Interoperability Program.
To support the policies in this proposed rule and maximize the potential to improve the prior authorization process for providers and patients, we are proposing to add a new measure titled “Electronic Prior Authorization” in the HIE objective of the MIPS Promoting Interoperability performance category and in the HIE objective of the Medicare Promoting Interoperability Program. We believe this measure would further enable the electronic exchange of health information to improve the quality of healthcare, such as promoting care coordination, as described in section 1848(o)(2)(A)(ii) of the Act with respect to MIPS eligible clinicians and section 1886(n)(3)(A)(ii) of the Act with respect to eligible hospitals and CAHs. We are proposing to require MIPS eligible clinicians to report this measure beginning with the CY 2026 performance period/CY 2028 MIPS payment year and for eligible hospitals and CAHs to report this measure beginning with the CY 2026 EHR reporting period. However, we propose that the measure will not be scored in 2026.
The proposals we are making in this section with regard to an Electronic Prior Authorization measure do not alter a covered entity's requirement to use the
We are proposing the following specifications for the Electronic Prior Authorization measure:
•
The MIPS eligible clinician would be required to report a numerator and denominator for the measure or (if applicable) report an exclusion:
•
•
•
(1) Does not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period; or
(2) Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the PARDD API requirements outlined in section II.D.3.a of this proposed rule during the applicable performance period.
•
The eligible hospital or CAH would be required to report a numerator and denominator for the measure or (if applicable) report an exclusion:
•
•
•
(1) Does not order any medical items or services (excluding drugs) requiring prior authorization during the applicable EHR reporting period; or
(2) Only orders medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the PARDD API requirements outlined in section II.D.3.a of this proposed rule during the applicable EHR reporting period.
We propose that beginning with the CY 2026 performance period/CY 2028 MIPS payment year for MIPS eligible clinicians and the CY 2026 EHR reporting period for eligible hospitals and CAHs, a MIPS eligible clinician, eligible hospital, or CAH that fails to report the measure or claim an exclusion would not satisfy the MIPS Promoting Interoperability performance category or Medicare Promoting Interoperability Program reporting requirements. For the CY 2026 performance period/CY 2028 MIPS payment year for MIPS eligible clinicians and the CY 2026 EHR reporting period for eligible hospitals and CAHs, we are proposing that the Electronic Prior Authorization measure would not be scored and would not affect the total score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program. In other words, for CY 2026, a MIPS eligible clinician, eligible hospital, or CAH would be required to report a numerator of at least one for the measure or claim an exclusion, but the measure would not be scored. If the MIPS eligible clinician, eligible hospital, or CAH does not report a numerator of at least one for the measure or claim an exclusion, they would receive a zero score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program, respectively. We intend to propose a scoring methodology for the measure in future rulemaking.
We are proposing that for purposes of this measure, a prior authorization request must be made using the PARDD API to satisfy the measure. The PARDD API functionality is outlined in further detail in section II.D.3.a of this proposed rule. Prior authorization requests that are made using fax, mail, or portal would be included in the denominator of the measure unless the prior authorization cannot be requested using the PARDD API because the payer does not offer an API that meets the PARDD API requirements, in which case it would be excluded from the denominator. Instances where a payer offering the PARDD API specifically requests a mailed or faxed prior authorization would be included in the denominator. Prior authorization requests that are made using fax, mail, or portal would not be included in the numerator of the measure because these methods would not incentivize the use of standards-based API functionality as intended by the measure. Prior authorizations for any and all drugs would be excluded from both the numerator and denominator of the measure. (For a more detailed
We are proposing that only prior authorizations that are requested electronically from a PARDD API using data from CEHRT would be included in the numerator. Using the API to query documentation requirements alone and not to request the prior authorization would not count in the numerator or denominator.
We propose that MIPS eligible clinicians, eligible hospitals, or CAHs that do not order any medical items or services (excluding drugs) requiring prior authorization during the applicable performance period or EHR reporting period could claim an exclusion for this measure. We are also proposing that MIPS eligible clinicians, eligible hospitals, or CAHs that only order medical items or services (excluding drugs) requiring prior authorization from a payer that does not offer an API that meets the PARDD API requirements outlined in section II.D.3.a of this proposed rule (that is, non-impacted payers or impacted payers that are non-compliant with the PARDD API requirements outlined in section II.D.3.a of this proposed rule), during the applicable performance period or EHR reporting period, could claim an exclusion for this measure. As an alternative to this proposal, we considered whether MIPS eligible clinicians, eligible hospitals, and CAHs that request a small number of prior authorizations, such as five prior authorizations during the performance period/EHR reporting period, should also be able to claim the exclusion. Given the previously discussed limitations of the current prior authorization process, we believe that all healthcare providers (as well as their patients and the payers they request prior authorization from) would benefit from using the electronic process described here, regardless of how often they request prior authorization. Therefore, we believe that no minimum number of prior authorization requests, other than zero, would be a reasonable threshold for claiming an exclusion for this measure. However, we seek public comment on the alternative we considered and whether another minimum number of prior authorization requests would be appropriate for the exclusion.
ONC recently sought comment through an RFI titled “Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria” (87 FR 3475), which appeared in the January 24, 2022 issue of the
We invite public comment on these proposals. Specifically, we seek comment on the following:
• Should CMS consider alternatives to the proposed numerator and denominator of the measure? Are there changes to these specifications that would reduce the implementation burden for both providers and health IT developers?
• What challenges will providers face in identifying those payers that have the PARDD API technology in order to accurately include eligible prior authorization requests in the denominator?
• What challenges will providers face in performing the actions included in the measure specifications and successfully reporting the measure if certification criteria are not available in the ONC Health IT Certification Program at the time providers are required to report the measure under the Medicare Promoting Interoperability Program or MIPS Promoting Interoperability performance category?
• With the understanding that ONC may consider policies in the ONC Health IT Certification Program that could further support this measure, are there alternate implementation timeframes that should be considered?
In the CMS Interoperability and Patient Access final rule (85 FR 25510), we finalized a requirement to implement, maintain, and use API technology conformant with 45 CFR 170.215, which includes API technical standards, including HL7® FHIR® Release 4.0.1 (at 45 CFR 170.215(a)(1)), the HL7 FHIR US Core Implementation Guide Standard for Trial Use (STU) 3.1.1 (at 45 CFR 170.215(a)(2)), the HL7 SMART Application Launch Framework IG Release 1.0.0 (at 45 CFR 170.215(a)(3)), the FHIR Bulk Data Access (Flat FHIR) version 1.0.0: STU 1 (at 45 CFR 170.215(a)(4)) and OpenID Connect Core 1.0 (at 45 CFR 170.215(b)) (85 FR 25521). When we finalized the requirement for conformance with the specifications in 45 CFR 170.215 in the CMS Interoperability and Patient Access final rule (85 FR 25521), we finalized the use of all standards at 45 CFR 170.215 in whole for each of the APIs finalized in that rule. However, we understand that the existing requirements
Accordingly, to reduce complexity and provide clarity, we are proposing modifications to be more specific regarding the standards at 45 CFR 170.215 applicable to previously finalized API requirements. We are also proposing specific language regarding the standards at 45 CFR 170.215 applicable for each new set of API requirements proposed in this proposed rule.
Specifically, instead of maintaining and extending the language in the existing requirements to use “API technology conformant with 45 CFR 170.215” in our new proposals, we are proposing language which specifies the use of each standard at 45 CFR 170.215 that would apply to a given set of API requirements at the CFR citations identified in Tables 8. We further summarize the standards applicable for each set of API requirements in Table 10. We note that the exact regulation text would vary depending on which standards apply to that API. We believe this language will clarify that payers would only be required to use those specifications included at 45 CFR 170.215 that CMS has identified as necessary for each specific API, as discussed further in section II.F.3 of this proposed rule.
Regarding the standard at § 170.215(a)(2), which is currently the HL7 FHIR® US Core Implementation Guide STU 3.1.1 (US Core IG), we
We also recognize that several of the IGs recommended for use in this section of this proposed rule build on specific profiles within the US Core IG. For example, the HL7 FHIR Da Vinci Payer Data Exchange (PDex) Implementation Guide: Version STU 1.0.0. Furthermore, we recognize that the recommended IGs and subsequent versions of these IGs may use profiles in updated versions of the US Core IG. We note that payers could use updated versions of the recommended IGs that rely on newer versions of the US Core IG, as long as those updated versions meet the requirements of our policy for the use of updated standards which is described below and aligns with the procedures established by ONC under the Standards Version Advance Process (SVAP).
In the CMS Interoperability and Patient Access final rule (85 FR 25510), we explained that while we must codify a specific version of each standard, the need for continually evolving standards development has historically outpaced our ability to amend regulations. In that final rule, we established that payers implementing a Patient Access or Provider Directory API could use an updated version of a standard subject to certain conditions. Specifically, we established that an updated version of a standard could be used if the updated version of the standard is required by other applicable law, or not prohibited under other applicable law, provided that: for content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of the section in which the provision is located, or 45 CFR part 170; and for standards at 45 CFR 170.213 and 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program (85 FR 25522). Finally, we established that an updated version of the standard could be used if the updated version does not disrupt an end user's ability to use a required API to access the data required for that API (85 FR 25532). We are now proposing to extend this same policy to allow the use of an updated version of a standard to the Provider Access API, Payer-to-Payer API, and PARDD API. Under this proposal, impacted payers could upgrade to newer versions of the required standards, subject only to those limiting conditions, as previously noted, at any pace they wish. However, we reiterate that when using updated standards, a payer must continue to support connectivity for end users and may only use an updated version of the standard instead of the standard specified in the applicable regulation, if it does not disrupt an end user's ability to access the data available through the API. We are proposing to allow the use of updated standards, specifications, or Implementation Guides for each of the API requirements at the CFR sections identified in Table 9. We note that any existing or proposed cross-references apply current requirements to the newly proposed APIs.
Regarding the use of updated versions of standards at 45 CFR 170.213 and 170.215, we propose that these standards may be used if the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program. We note that the National Coordinator approves the use of updated versions of standards in the Certification Program under SVAP pursuant to 45 CFR 170.555, which was finalized in the ONC 21st Century Cures Act final rule as a Maintenance of Certification flexibility included in the real-world testing Condition of Certification (85 FR 25775). This flexibility permits health IT developers to voluntarily use, in certain certified Health IT Modules, newer versions of adopted standards so long as specific conditions are met, providing a predictable and timely approach within the Certification Program to keep pace with the industry's standards development efforts.
Under the SVAP, after a standard has been adopted through notice and comment rulemaking, ONC engages in an open and transparent process to timely ascertain whether a more recent version of an adopted standard or implementation specification should be approved by the National Coordinator for developers' voluntary use under the Certification Program. ONC lists updated versions of standards that the National Coordinator has approved on its website.
We note that several updated versions of the standards currently at §§ 170.213 and 170.215 have been approved by the National Coordinator under the SVAP process,
In the CMS Interoperability and Patient Access final rule (85 FR 25529), we noted certain IGs that are publicly available for use and provide implementation information that payers can use to meet the regulatory requirements for APIs finalized in the rule to support interoperability and avoid having to develop an approach independently, saving time and resources. Reference implementations, which are use case-specific test implementations with test data, have been developed for these IGs and allow payers to see the APIs in production and support testing and development. We explained that using the additional recommended IGs could limit payer burden and support consistent, interoperable API development and implementation. We referred payers to information about recommended IGs and related reference implementations (85 FR 25533). In this proposed rule, we are also recommending specific implementation guides, including implementation guides relevant to the new API requirements proposed in this rule, that may be used in addition to the standards we are proposing to require at 45 CFR 170.215.
In the December 2020 CMS Interoperability proposed rule, we proposed to require the use of FHIR IGs, including the CARIN IG for Blue Button®, HL7® FHIR® Da Vinci PDex IG, HL7® FHIR® Da Vinci PDex U.S. Drug Formulary IG, HL7® FHIR® Da Vinci PDex Plan Net IG, Da Vinci Coverage Requirements Discovery (CRD) IG, Documentation Templates and Rules (DTR) IG, and Prior Authorization Support (PAS) IG (85 FR 82586) to support the APIs requirements in the proposed rule. As discussed in section I.A. of this proposed rule, the December 2020 CMS Interoperability proposed rule will not be finalized, and we are withdrawing the proposals included in that rule. We also note that these FHIR IGs continue to undergo further refinement and development as part of the HL7 ballot and standard advancement process that are expected to better support the Patient Access, Provider Access, Payer-to-Payer, and PARDD APIs.
Additionally, some aspects of the HL7® FHIR® DaVinci PAS IG, notably the FHIR to X12 transactions and use of FHIR subscriptions, continue to be developed. In the case of the HL7® FHIR® DaVinci PDex US Drug Formulary IG, which was proposed to support API requirements finalized in the CMS Interoperability and Patient Access final rule, nuances involving how the data are used in different ways by payers need to be resolved, such as different co-pay and co-insurance options and subtleties when searching by brand name, ingredients, and drug name. Industry stakeholders continue to pursue production implementations to identify refinements and reconcile inconsistencies in these IGs to address targeted use cases more effectively.
After careful ongoing consideration of the IGs, as previously listed, that were proposed previously in the December 2020 CMS Interoperability proposed rule, their development cycles, and our role in advancing interoperability and supporting innovation, we believe that while these IGs will continue to play a critical role in supporting our policy, we are not ready to propose them as a requirement of our interoperability initiatives. We believe these IGs will continue to be refined over time as stakeholders have the opportunity to test and implement them, and as such, we are recommending them for use but are not proposing to require them. Specifically, we will continue to monitor and evaluate the development of the IGs and consider whether to propose them as a requirement at some future date. At this time, we are recommending the use of the CARIN IG for Blue Button®, HL7® FHIR® Da Vinci PDex IG, HL7® FHIR® Da Vinci PDex U.S. Drug Formulary IG, HL7® FHIR® Da Vinci PDex Plan Net IG, and Da Vinci CRD IG, DTR IG, PAS IGs for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and PARDD APIs.
We acknowledge that by not requiring the use of all of the available FHIR IGs, there is potential for implementation variation in these APIs that could limit interoperability and ultimately lead to re-work for implementers if requirements are introduced later. However, at this time, we believe it is more important not to require these IGs while they are still undergoing additional enhancements. We are recommending, but not requiring, certain IGs that were previously proposed because we want to ensure that implementers use subsequent versions of these IGs without restriction to the version available when we issue a regulation. As discussed in section II.F.1, we previously finalized a policy to allow flexibility for the use of updated versions of certain standards required for the API requirements finalized in the Patient Access and Interoperability final rule, which we have proposed to extend to the API requirements proposed in this rule. However, we understand that the subsequent versions of the recommended IGs may include substantial changes that would not be consistent with the requirement included in our flexibility provisions that the use of an updated standard must not impair access to data through the API. Therefore, we believe that if we proposed to require the recommended IGs at this time, impacted payers would not be able to use an updated version of these IGs unless we were to require the updated versions through additional rulemaking. We intend to monitor IG development and may propose to require specific IGs at some future date when there are versions available for adoption that are mature and more likely to allow for voluntary updates under our flexibility policies.
We seek comment on whether CMS should propose to require the use of these IGs for previously finalized and proposed APIs in future rulemaking and other ways that we could support innovation and interoperability. In addition, we seek comment on the process CMS should use to adopt or allow new versions of standards and implementation specifications over time, as previously discussed. CMS supports innovation and continued efforts to refine standards in a way that will leverage the most recent technological advancements.
In making these recommendations, we note that these IGs are publicly available at no cost to a user. All HL7® FHIR® IGs are developed through an industry-led, consensus-based public process. HL7® is an American National Standards Institute (ANSI)-accredited standards development organization. HL7 FHIR standards allow disparate systems with different data architectures to exchange information in a standardized way via standards-based APIs. HL7 FHIR IGs are also openly available, so that any interested party can access a HL7 FHIR IG on the HL7 website. All public comments made during the HL7 balloting process and the IG version
A few
While we are recommending the IGs proposed previously in the December 2020 CMS Interoperability proposed rule as discussed, we welcome further information about the maturity of these IGs, including considerations about further development that would be needed prior to CMS requiring the use of specific IGs.
Using IGs supports consistent implementations across the industry. Therefore, we are proposing at the CFR citations identified in Table 8 to require that impacted payers use API technology conformant with the standards at 45 CFR 170.215 that we propose as applicable for each set of API requirements. We include Table 10 to provide a clear outline of which standards we are proposing to require and which IGs we recommend for each proposed API.
The December 2020 CMS Interoperability proposed rule (85 FR 82586) included several requests for information, including one regarding standards for social risk factor data. We received several comments requesting additional time to comment on this issue, and thus we are reissuing the request for information, with modification to add additional questions in this section.
Social determinants of health (SDOH) as defined by Healthy People 2030 are “the conditions in the environments where people are born, live, learn, work, play, worship, and age that affect a wide range of health, functioning, and quality-of-life outcomes and risks.”
CMS recognizes that social risk factors impact patient health, utilization, and outcomes, and that these factors can have a direct impact on our healthcare system as a whole. To the extent that healthcare providers and payers have access to data on social risk factors, they are best equipped to address these factors, and thus have a positive impact on patient health. Healthcare providers in value-based payment arrangements rely on comprehensive, high-quality data to identify opportunities to improve patient care and drive value. When implemented effectively, value-based payment encourages healthcare providers to care for the whole person and address the social risk factors that are critical for patient quality of life.
As value-based payment has grown, so has provider community interest in social risk factor data.
Unfortunately, social risk factor data are often fragmented, unstandardized, out of date, and duplicative. These circumstances are a result of a lack of clear standards for capturing, recording, and exchanging these data. While the International Classification of Diseases, Tenth Revision, Clinical Modification (ICD-10-CM) psychosocial risk and economic determinant-related codes (“Z codes”) can be used to capture standardized information on social determinants of health, utilization on Medicare claims remains relatively low for a number of reasons, including a
As healthcare providers assume greater accountability for costs and outcomes through value-based payment, they need tools to successfully identify and address social risk factors to improve care and health outcomes. Over the last several years, standards development organizations like the Gravity Project under HL7,
CMS seeks input on barriers the healthcare industry faces to using industry standards and opportunities to accelerate adoption of data collection standards related to social risk factor data, including exchange of information with community-based organizations. CMS specifically seeks input on these topics from stakeholders in minority and underserved communities as defined by section 2(b) of Executive Order 13985, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government,
• What are best practices regarding frequency of collection of social risk and social needs data? What are factors to be considered around expiration, if any, of certain social needs data?
• What are best practices regarding workforce training on collecting social risk and social needs data? How could CMS best support such training?
• What are the challenges in representing and exchanging social risk and social needs data from different commonly used screening tools? How do these challenges vary across screening tools or social needs (for example, housing or food access)?
• What are the barriers to the exchange of social risk and social needs data across healthcare providers? What are key challenges related to exchange of social risk and social needs data between healthcare providers and community-based organizations? If Federal or other regulations are perceived or actual barriers, please identify the specific regulation, policy, or guidance and clarifying language that would be necessary to resolve the cited barrier. If no specific language or policy is known, please provide a citation where more information is available related to this barrier.
• What mechanisms (EHRs, Health Information Exchanges [HIEs], software, cloud-based data platforms, etc.) and/or standards are currently used to capture, exchange, and use social risk and social needs data? What challenges, if any, occur in translating, collecting, or transferring social risk factor data in these platforms to Z codes on claims?
• How can payers promote exchange of social risk and social needs data? Are there promising practices used by MA organizations, state Medicaid agencies, Medicaid managed care plans, commercial health plans, or other payers that can potentially be further leveraged in other settings?
• What specific strategies, tactics, or policies would help CMS and other Federal agencies facilitate greater standardization in the capture, recording, and exchange of social risk factor data? Are there best practices (related to contracting language, requirements in Federal programs, etc.)
• What are the most promising efforts that exist to date in resolving the challenges previously cited in this proposed rule? Which gaps remain that are not being addressed by existing efforts?
• What privacy issues should be considered when formulating policy for collecting and exchanging social risk and social needs data? Are there certain data elements that patients may wish to exercise more control over than others?
• What are best practices that are currently addressing other challenges previously cited in this proposed rule, such as integration of social risk and social needs data into clinical workflow, adoption, and use of commonly used screening tools with associated health IT standards and value sets, and integration of social risk data and social needs data into the patient's longitudinal health record?
• Please identify potential existing, emerging, or possible new policy levers that CMS could use to better incentivize use and interoperability of social risk factor data.
• Please identify opportunities and approaches that would help CMS facilitate and inform effective infrastructure investments to address gaps and challenges for advancing the interoperability of social risk factor data.
We seek comments on these questions and issues for future consideration.
The December 2020 CMS Interoperability proposed rule (85 FR 82586) included several requests for information, including a request for information regarding electronic data exchange among behavioral health providers (85 FR 82637). We received several comments requesting additional time to comment on this particular issue, and thus we are reissuing the request for information, with modification to add additional questions in this section of this proposed rule.
Several factors have led behavioral health providers to adopt EHRs at a significantly lower rate than other types of healthcare providers. One possible contributing factor was that the Health Information Technology for Economic and Clinical Health Act (HITECH Act), enacted as part of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111-5) on February 17, 2009, made Medicare FFS and Medicaid incentive payments for the adoption and meaningful use of CEHRT available only to eligible professionals, eligible hospitals, and CAHs, so behavioral health providers that did not meet those criteria were ineligible for these incentive payments. For example, while behavioral health providers who were physicians (eligible professionals) could receive the incentive payments, other types of non-physician behavioral health providers may not have been eligible. Congress created another potential opportunity to address this issue when it enacted the Substance Use-Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT Act) (Pub. L. 115-271) on October 24, 2018. Section 6001 of the SUPPORT Act modifies an existing list of possible model opportunities the Center for Medicare & Medicaid Innovation may consider testing to include models to provide incentive payments to behavioral health providers for adopting EHRs.
Today, behavioral health providers lag behind their peers in the ability to electronically share health information across providers and with patients. ONC noted that, in 2017, only 14 percent of office-based physicians reported sending data to behavioral health providers, while 12 percent of office-based physicians reported receiving data from behavioral health providers.
Understanding the time and cost of implementing an EHR system, we are interested in evaluating whether using other applications that exchange data using the FHIR APIs and do not require implementation of a full EHR system might be a way to help behavioral health providers leverage technology to exchange health data to improve care quality and coordination in a more agile fashion. Specifically, would small practices and community-based providers be able to more quickly adopt applications using API technology to exchange health information when the technology is not tied to an EHR? Would these providers be able to achieve the same care coordination goals using such applications as with a more extensive EHR implementation, or would the value be lower but still sufficient to improve care quality and care coordination?
The Substance Abuse and Mental Health Services Administration (SAMHSA) published regulations related to improved care coordination among providers that treat substance use disorders as well as protecting those patients' records (42 CFR part 2). Section 6001 of the SUPPORT Act also encourages CMS to consider ways to facilitate information sharing among behavioral health providers by adding a model opportunity to the list of possible model opportunities for consideration by the CMS Center for Medicare & Medicaid Innovation under section 1115A(b)(2)(B) of the Act. We are looking for innovative approaches to addressing the need to facilitate the electronic exchange of behavioral health information, as well as approaches to support the exchange of health information to behavioral health providers to inform care and provision of behavioral health services.
ONC has been working with other Federal agencies to consolidate input to help inform approaches HHS can take to advance behavioral healthcare delivery and coordination supported by health IT, through the development of action items and high impact projects including to support behavioral health integration consistent with the HHS Roadmap for Behavioral Health Integration.
Many behavioral health providers practice in community-based roles. As a result, when considering behavioral health specifically, it is valuable to consider community-based providers more broadly.
We are interested in public comments on how we might best support electronic data exchange of behavioral health information between and among behavioral health providers, other healthcare providers, and patients, as well as how we might best inform and
• Can applications using FHIR APIs facilitate electronic data exchange between behavioral health providers and with other healthcare providers, as well as their patients, without greater EHR adoption? Is EHR adoption needed first? What opportunities do FHIR APIs provide to bridge the gap? What needs might not be addressed by using applications with more limited functionality than traditional EHRs?
• How can existing criteria under the ONC Health IT Certification Program ensure applications used by behavioral health providers enable interoperability? What updates to existing criteria, or new criteria, could better support exchange by these clinicians?
• What levers could CMS consider using to facilitate greater electronic health data exchange from and to behavioral health providers? What costs, resources, and/or burdens are associated with these options? Is there additional sub-regulatory guidance and/or technical assistance that CMS or HHS could provide that would be helpful?
• Are there particular considerations for electronic data exchange for behavioral health providers who practice independently, are community-based, or are non-traditional providers? What about rural-based behavioral health providers? How could an API-based solution help address these considerations?
• Are there state or Federal regulations or payment rules that are perceived as creating barriers to technical integration of systems within these practices? What additional policy issues, technical considerations, and operational realities should we consider when looking at ways to best facilitate the secure electronic exchange of health information that is maintained by behavioral health providers including sensitive health information?
• What are current drivers at the Federal, state, or local level that are effectively supporting greater adoption of health IT for behavioral health providers? What new regulations guidance, or other policy levers (including new authorities) could benefit community providers or include incentives for community providers to encourage greater adoption of health IT?
• What methods and approaches have stakeholders utilized to help advance health IT adoption among behavioral health providers, for instance, effective practices for braiding/blending of funds and as part of value-based models? How are stakeholders effectively strengthening system capacity, connecting to care, and creating healthy environments today?
• What levers and approaches could CMS consider using and advancing to facilitate greater electronic health data exchange from and to community-based health providers including use of relevant health IT standards and certification criteria for health IT as feasible? What costs, resources, and/or burdens are associated with these options?
• What privacy and security considerations would be the biggest barriers for community-based providers to engage in information exchange, and which could be addressed by Federal policy, which by technology, and which by process?
We seek comments on these questions and issues for future consideration.
In the Medicare FFS program, the ordering provider or supplier can often be different than the rendering provider or supplier of items or services, which may contribute to challenges in the coordination of patient care and exchange of medical information needed to ensure accurate and timely payment. Unlike their physician and hospital counterparts, providers such as home health agencies, Durable Medical Equipment, Prosthetics, Orthotics, and Supplies (DMEPOS) suppliers, and ambulance providers were not included in the American Reinvestment and Recovery Act (ARRA) Health Information Technology for Economic and Clinical Health (HITECH) Act programs, so they were not eligible for the same incentive payments for health IT adoption and interoperable data exchange as other providers. Thus, some providers or suppliers continue to use the U.S. Postal Service or fax machines to send patient information, and these methods can also lead to delays in the receipt of orders, prior authorization decisions, and payments. Ideally, health IT and the electronic exchange of information would streamline information-sharing processes between ordering and rendering providers or suppliers so that any impediments are eliminated.
For example, with DMEPOS suppliers, a physician or non-physician practitioner (NPP) may order a power wheelchair and document the necessary information in the beneficiary's medical record, but the DMEPOS provider will provide the wheelchair and submit the claim for payment. For some DMEPOS items, a written order is required prior to delivery.
Such coordination can take time to complete and lead to delays in the receipt of necessary documentation, particularly in those instances where either one or both providers or suppliers do not use health IT to share medical information. Even in situations where both the ordering and rendering providers or suppliers do use health IT to exchange information, the compatibility of the systems may not allow for the easy and/or expeditious exchange of that information. Should prior authorization be required, disparities in health IT system data exchange capabilities could lead to delays in healthcare decision-making and potential delays in the delivery of care for patients. These delays can be more problematic in those settings where the focus of one provider is on the order and the focus of the other provider is on providing the item or service and submitting the claim for payment. This arrangement frequently
The inconsistent use and lack of uniform health IT to exchange medical documentation will take time to effectively resolve. In the interim, we are interested in public comments on how Medicare FFS might best support improvements to the exchange of medical documentation between and among providers or suppliers and patients, as well as how we might best inform and support the movement of health data (and its consistency) to providers or suppliers for their use to inform care and treat beneficiaries. We are also interested in public comments on what specific changes or improvements in health IT could assist providers or suppliers in submitting medical documentation to CMS and its contractors so that claims are not denied and/or are not deemed improper payments. Specifically, we are seeking public comments on the following questions:
• How might CMS encourage more electronic exchange of medical information (for example, orders, progress notes, prior authorization requests, and/or plans of care) between providers/suppliers and with CMS and its contractors at the time an item or service is ordered? When possible, please describe specific recommendations to facilitate improved data exchange between providers or suppliers, and with CMS and its contractors, to support more efficient, timely, and accurate claims and prior authorization communications. Are there specific process changes that you believe would improve the exchange of medical documentation between ordering and rendering providers or suppliers? Are there particular policy, technical, or other needs that must be accounted for in light of the unique roles of ordering and rendering providers or suppliers?
• Are there changes necessary to health IT to account for the need for providers/suppliers (ordering and rendering) to exchange medical documentation, either to improve the process in general or to expedite processing to ensure beneficiary care is not delayed? How could existing certification criteria or updates to certification criteria under the ONC Health IT Certification program support specific exchange needs?
• What additional steps in the area of health IT and the exchange of information could CMS take to assist providers or suppliers in the claim submission process? Are there changes in technology or processes that could also reduce the number of claims re-submissions and/or improper payments?
• What levers could CMS consider using to facilitate greater collaboration and exchange of information among providers/suppliers? What costs, resources, and/or burdens are associated with this type of collaboration? Are there changes that could reduce improper payments and the administrative burden often encountered by rendering providers/suppliers who need medical record documentation from ordering providers or suppliers?
• Are there state or Federal regulations or payment rules that are perceived as creating barriers to the exchange of information between ordering and rendering providers/suppliers? What additional policy issues, technical considerations, and operational realities should we consider when looking at ways to best facilitate the secure exchange of information between providers or suppliers and with Medicare FFS?
We seek comments on these questions and issues for future consideration.
The Biden-Harris Administration has prioritized addressing the nation's maternity care crisis. In April 2021, President Biden issued a Presidential Proclamation marking Black Maternal Health Week.
In July 2022, CMS published its Cross-Cutting Initiative: CMS Maternity Care Action Plan,
The CMS Maternity Care Action Plan also expressed intentions to coordinate across programs to identify gaps and best practices. Technology can be leveraged to address known racial disparities to prenatal and postnatal care by facilitating telehealth visits or remote monitoring options. For example, research has shown leveraging technology and telehealth significantly reduced the racial disparities in blood pressure ascertainment.
As the CMS action plan outlines, we are working to expand our data collection efforts, stratify data by key demographics to identify disparities in maternal care or outcomes, and coordinate across programs to identify gaps and best practices. In the FY 2022 IPPS final rule,
For state Medicaid and CHIP agencies, CMS annually identifies a core set of measures for voluntary reporting that show the quality of care and health outcomes for those programs' beneficiaries. These measures are currently voluntarily reported by states, but a subset of measures—that, is the Child Core Set and behavioral health measures in the Adult Core Set—will become mandatory for states to report beginning in 2024. We identified a core set of 9 measures in 2022 that support our maternal and perinatal health-focused efforts (the Maternity Core Set).
In addition to measurement data, which helps us to better understand the state of maternal healthcare in our various programs, CMS also believes that a critical foundation comprised of health IT, data sharing, and interoperability underlie many opportunities to improve maternal health outcomes. CMS is now seeking information from the public on evidence-based policies we could pursue that leverage information technology to improve such outcomes.
Health IT can be used to support safe and effective maternal and child healthcare. The ONC Pediatric Health Information Technology: Developer Informational Resource
Using common data exchange standards for human services information can also provide many benefits for supporting maternal healthcare, including, but not limited to, promoting greater information-sharing and interoperability, collaboration with other human services sectors beyond healthcare such as education and public safety, and overall improvements to systems for the effective use of technology. CMS welcomes input on technical and policy approaches that effectively link maternal human services data to health IT codes and value sets, such as ICD-10 and LOINC codes, in order to help improve interoperability across multiple systems, domains, and use cases, including the effective use of interoperable assessment instruments. CMS further welcomes input on how other health IT standards, such as FHIR, can be used to expand healthcare interoperability to integrate with human services for individual maternal health and overall population health improvement.
The USCDI version 3, published in July 2022, contains a new data class on pregnancy status, as well as other data classes and elements important for supporting maternal health, including SDOH Assessment, Diagnostic Imaging, and Vital Signs.
In addition, ONC recently launched an initiative called USCDI+ to support the identification and establishment of domain, or program-specific, datasets that build on the existing USCDI dataset.
• Are there other data elements and classes relevant to care coordination for maternal health that should be added to USCDI?
• Are there data related to maternal health that are currently not collected at scale, or not collected at all, that would be helpful for stakeholders to have
• What are key gaps in the standardization and harmonization of maternal health data? How can HHS support current efforts to address these gaps?
• How could an initiative such as USCDI+ be leveraged to harmonize maternal health data needed for care coordination, quality measurement, and other Federal programs that collect maternal health data?
In section II.D of this proposed rule, we discuss our proposals to improve prior authorizations. In addition to the impacts on patient care in general discussed in that section, we note the effects of inefficient prior authorizations on maternal health, specifically. For instance, maternal care experts have observed that some payers may utilize an intermediary, such as a radiology benefits management company, to act on their behalf to review healthcare provider requests to perform imaging. This may add an additional waiting period for a decision, potentially creating hazardous delays for pregnant women who, for example, need to obtain an ultrasound.
• Should there be special considerations for the prior authorization process in maternal healthcare? For example, should the timeframes for prior authorization be expedited in cases where the prior authorization is related to prenatal and perinatal care?
• How have prior authorization processes impacted maternal healthcare for patients enrolled in CMS programs? Please include references to specific CMS program(s) in your response.
• Should prior authorizations carry over from one payer to another when a patient changes payers for the duration of the pregnancy, or at least for a period of time while the patient and their provider gather the necessary documentation to submit a new prior authorization to the new payer?
• What other special considerations should be given to data sharing for maternal health transitions?
Section 4003(b) of the 21st Century Cures Act (Pub. L. 114-255), enacted in 2016, amended section 3001(c) of the Public Health Service Act (42 U.S.C. 300jj-11(c)) and required HHS to take steps to advance interoperability for the purpose of ensuring full network-to-network exchange of health information. Specifically, Congress directed the National Coordinator to “develop or support a trusted exchange framework, including a common agreement among health information networks nationally.” Since the enactment of the 21st Century Cures Act, HHS has pursued the development of TEFCA. ONC's goals for TEFCA are:
On January 18, 2022, ONC announced a significant TEFCA milestone by releasing the Trusted Exchange Framework
The technical and policy architecture of how exchange occurs under the Common Agreement follows a network-of-networks structure, which allows for connections at different levels and is inclusive of many different types of entities at those different levels, such as HINs, care practices, hospitals, public health agencies, and Individual Access Services (IAS)
The QTF, which was developed and released by the RCE, describes the functional and technical requirements that a HIN
The Common Agreement and the QTF do not require HL7 FHIR-based exchange. The Common Agreement and QTF allow for the optional exchange of FHIR content using more traditional, established standards to enable the transport of that content. However, TEFCA can nonetheless be a strong catalyst for network enablement of FHIR maturation. To that end, the RCE released a 3-year FHIR Roadmap for TEFCA Exchange, which lays out a deliberate strategy to add FHIR-based exchange under the Common Agreement and the QTF in the near future.
In 2022, prospective QHINs had the opportunity to begin signing the Common Agreement and apply for designation. Following the approval of their applications, the RCE will begin onboarding and designating QHINs to exchange information. In 2023, HHS expects stakeholders across the care continuum to have increasing opportunities to enable exchange under TEFCA.
In the FY 2023 IPPS/LTCH final rule (87 FR 48780), we finalized our proposal to add a new, optional Enabling Exchange Under TEFCA measure to the Health Information Exchange Objective in the Medicare Promoting Interoperability program.
We believe that the ability for stakeholders to connect to an entity that connects to a QHIN, or to connect directly to a QHIN, can support and advance the payer requirements that we have proposed in this rule that would become applicable by 2026 if enacted as proposed. Specifically, such connections could support exchange of patient information with providers via the Provider Access API and support transmission of coverage and prior authorization requests from providers via the PARDD API. As requirements for use of FHIR are incorporated into the QTF, stakeholders that enable exchange under TEFCA will be better positioned to not only exchange the data we propose to require for these APIs, but also to do so in a multi-networked environment that simplifies connections between providers and payers. We similarly believe that such connections could support requirements for the Patient Access API previously finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510) by enabling patients to access their information held by the payer, as well. As previously noted, TEFCA can be a strong catalyst for FHIR maturation. To the extent that TEFCA evolves in accordance with the FHIR Roadmap for TEFCA Exchange, we anticipate further opportunities for TEFCA to support information availability via FHIR API exchange requirements for payers.
We believe enabling exchange under TEFCA by payers and vendors offering health apps could provide a simplified way for vendors to access and make information available to their customers. By accessing payer-held information through a QHIN or an entity connected to a QHIN, health apps could avoid the need to develop direct connections to each individual payer. This is because such apps could connect once and enable patients to gain access to information held by any payer exchanging information under TEFCA. Furthermore, as discussed in section II.A., apps that enable exchange under TEFCA would be required to meet the Common Agreement's privacy and security requirements,
Enabling exchange under TEFCA by health plans could also support the proposed requirements in section II.C.
We are requesting input from the public on the ideas previously described in this section and related concepts for future exploration, as well as the following questions:
• How could the requirements of the Common Agreement and the QTF help facilitate information exchange in accordance with the final policies in the CMS Interoperability and Patient Access final rule (85 FR 25510) around making clinical and administrative information held by health plans available to patients? How could TEFCA support proposed requirements for payers under this rule related to provider data access and prior authorization processes?
• How should CMS approach incentivizing or encouraging payers to enable exchange under TEFCA? Under what conditions would it be appropriate to require this approach by payers subject to the proposed regulations in this rule and previously finalized regulations in the CMS Interoperability and Patient Access final rule (85 FR 25510)?
• What concerns do commenters have about potential requirements related to enabling exchange under TEFCA? Could such an approach increase burden for some payers? Are there other financial or technical barriers to this approach? If so, what should CMS do to reduce these barriers?
We seek comments on these questions and issues for future consideration.
Under the Paperwork Reduction Act of 1995, we are required to provide 60-day notice in the
• The need for the information collection and its usefulness in carrying out the proper functions of our agency.
• The accuracy of our estimate of the information collection burden.
• The quality, utility, and clarity of the information to be collected.
• Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.
We are requesting public comment on each of these issues for sections of this document that contain information collection requirements (ICRs).
To advance our commitment to interoperability, we are proposing new requirements for certain impacted payers to implement FHIR APIs and several process improvements to help streamline the prior authorization process. The proposed FHIR APIs would permit patients, providers, and payers to access a defined set of standardized data. We additionally propose to require impacted payers to implement a FHIR Prior Authorization Requirements, Documentation, and Decision (PARDD) API to support prior authorization processes; to reduce the amount of time to process prior authorization requests and send information about decisions; and to publicly report certain metrics about patient access utilization, and prior authorization processes, among other proposals. We also propose a new requirement for a Payer-to-Payer API to ensure data can follow patients when they change payers. Finally, we propose to require reporting of certain metrics regarding the use of the existing Patient Access API. Combined, these proposals are intended to reduce burden on providers, payers, and patients and support improvements in patient care coordination.
To incentivize provider participation, specifically with the PARDD API, we are proposing a new measure for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program related to electronic prior authorization beginning in 2026, but the measure would not be scored until a future date. We would propose future year scoring and the number of points associated with the measure in future rulemaking. This new measure will be included in a PRA package related to this proposed rule.
To derive average costs, we use data from the U.S. Bureau of Labor (BLS) Statistics' National Occupational Employment and Wage Estimates (
We are adjusting the employee hourly wage estimates by a factor of 100 percent, or doubling the BLS wage estimates. This is necessarily a rough adjustment because fringe benefits and overhead costs vary significantly across employers based on the age of employees, location, years of employment, education, vocations, and other factors. Methods of estimating these benefits and overhead costs can vary across studies. We have elected to use sources in alignment with other CMS regulations after determining that they have used similar estimates and formulas.
Consistent with our approach in the CMS Interoperability and Patient Access final rule (85 FR 25622), we determine ICRs by evaluating cost and burden at the impacted payer level, as defined and discussed in detail in that rule. Ultimately, we determined that there are 365 impacted payers
To assess whether our policy requirements concerning the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558) have been implemented, we are proposing to require impacted payers to annually report certain metrics to CMS on the use of the Patient Access API. Specifically, we are proposing to collect: 1) the total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and 2) the total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient. We estimate that impacted payers would conduct two major work phases: (1) implementation, which includes defining requirements and system design (and updates) to generate and compile reports; and (2) maintenance, which we define as including the compilation and transmission of annual reports to CMS. During the implementation phase, impacted payers would need to prepare their systems to capture the data to be transmitted to CMS.
The burden estimate related to the new proposed requirements reflects the time and effort needed to identify, collect, and disclose the information. We estimate an initial set of one-time costs associated with implementing the reporting infrastructure and an ongoing annual maintenance cost to report after the reporting infrastructure is established.
Table 12 presents our preparatory computational estimates for first-year implementation and ongoing maintenance costs. Table 12 is not the official statement of burden, which is found in Table 19, including the number of respondents and responses. Table 12 presents the preparatory calculations needed to create the official statement of burden in Table 19. We assume a two-person team of a software/web developer and a business operations specialist would spend an aggregate of 160 and 40 hours, respectively, for the first and subsequent years, at a total cost per impacted payer (rounded) up to $15,000 and $3,000, for the first and subsequent years. The
We request comment on our assumptions and approach.
To promote our commitment to interoperability, we propose new requirements for a Provider Access API. This FHIR API would permit providers to receive standardized patient data to coordinate care. To estimate costs to implement the new requirements for new APIs proposed in this rule, we use the same methodology as that used in the CMS Interoperability and Patient Access final rule.
In the CMS Interoperability and Patient Access final rule, we estimated that impacted payers would conduct three major work phases: initial design, development and testing, and long-term support and maintenance (85 FR 25605). In this proposed rule, we assume the same major phases of work would be required, with a different level of effort during each work phase, for each of the new proposed APIs. Consistent across all newly proposed API provisions, we describe the tasks associated with the first two phases. Where we believe additional effort associated with these tasks is necessary, we describe those as relevant in subsequent ICRs, depending on how we believe they affect cost estimates. We discuss the costs for the third phase, long-term support and maintenance, and our methodology for the development of those costs in aggregate for all proposed APIs in this section.
In the initial design phase, we believe tasks would include: determining available resources (personnel, hardware, cloud storage space, etc.), assessing whether to use in-house or contracted resources to facilitate an API connection, convening a team to scope, build, test, and maintain the API, performing a data availability scan to determine any gaps between internal data models and the data required for the necessary HL7 FHIR resources, and mitigating any gaps discovered in the available data.
During the development and testing phase, we believe impacted payers would need to conduct the following: map existing data to the HL7 FHIR standards, allocate hardware for the necessary environments (development, testing, production), build a new FHIR-based server or leverage existing FHIR servers, determine the frequency and method by which internal data are populated on the FHIR server, build connections between the databases and the FHIR server, perform capability and security testing, and vet provider requests.
Table 13 summarizes the aggregate burden for complying with the proposed Provider Access API requirements. Here we provide illustrative points explaining the calculations within the table and the terms used for the headings. For example, row one is titled “Database Administrators and Architects.” To develop the proposed Provider Access API, each organization will require a team of database administrators, engineers, computer system analysts, etc. The team members are detailed in the rightmost column.
Continuing on the top row, “Database Administrators,” we obtained the labor cost of $97.20 per hour from the Bureau of Labor Statistics website. The $97.20 represents the mean wage for this occupational title. We assume most organizations would require 3 months of work for Database Administrators on this task. Three months is twelve weeks, or 480 hours (3 months × 4 weeks per month × 5 days a week × 8 hours per day). The 480 hours are found in the column titled “Primary Hours.” The word primary, as used in the CMS Interoperability and Patient Access final rule, refers to the amount of time most organizations would require to conduct this work. This totals a cost of $46,656 for each organization, which is obtained by multiplying the 480 hours by the $97.20 per hour wage. This $46,656 is found in the column labeled “Total Cost, Primary.”
We also provide low and high estimates representing a range of possible time and cost across all organizations. The low estimate is half the primary estimate, which is 240 hours or 1.5 months. The high estimate is 720 hours representing 4.5 months. These numbers are found in the low and high columns (hours) of the top row. The corresponding low and high costs are multiplied by the $97.20 per hour wage. We estimate that this is a reasonable range that would include all organizations. A typical organization would take 3 months, with some organizations completing the work in less time (in as little as 1.5 months) and some organizations taking longer (up to 4.5 months).
The explanation of the top row applies to each of the ten occupational titles. The sum of the total hours and cost provides a typical organization's total cost. This number is found in the “Totals for a single impacted payer” row. As depicted, the typical organization would take a total of 2,800 hours at a cost of $270,045. We estimated the impact by organization rather than by payer since many organizations may have entities in several of the programs to which this proposed rule applies: Medicare Advantage, Medicaid, CHIP, and QHP issuers on the FFEs.
To arrive at the total cost of the rule, we multiplied the single-organization cost by 365 payers, the number of organizations hosting plans across the
Similar to the methodology used in the CMS Interoperability and Patient Access final rule, we estimated maintenance costs in future years after the API is established at 25 percent of the aggregate cost. This 25 percent was arrived at based on our experience with the industry. Rather than list more columns or create another table, we provide a footnote indicating that maintenance is 25 percent of the cost. For example, the primary aggregate burden over all 365 organizations is $98.6 million, implying that the annual maintenance costs would be $24.6 million (25 percent × $98.6 million).
Although this provision would first be applicable on January 1, 2026, we believe it is reasonable that the APIs would have to be under development before this date to conduct testing and ensure compliance. Acknowledging that impacted payers will have varying technological and staffing capabilities, as we did in the CMS Interoperability and Patient Access final rule (85 FR 25606), we estimate that the development of the APIs would require 6 to 12 months of work. Expecting that this proposed rule will be finalized by mid-year 2023, we have distributed the cost over approximately two-and-a-half calendar years to give payers the flexibility to complete the necessary work (see Table 19).
We request comment on our approach and assumptions for the cost of the Provider Access API, including whether our estimates and ranges are reasonable or should be modified.
We discuss the costs for the third phase, long-term support and maintenance, and our methodology for the development of those costs in aggregate for all APIs discussed in this proposed rule. As relevant to the APIs discussed in sections V.C.1., 3., 4., and 8., we estimate ongoing maintenance costs for the Provider Access API, PARDD API, and Payer-to-Payer API in aggregate. This approach aligns with the strategy taken in the CMS Interoperability and Patient Access final rule (85 FR 25605), whereby the costs of the API development are split into three phases: initial design, development and testing, and long-term support and maintenance. However, unlike the CMS Interoperability and Patient Access final rule, this proposed rule assumes that maintenance costs only account for the cost associated with the technical requirements as outlined in this rule. Any changes to requirements would require additional burden, which would be discussed in future rulemaking. Throughout the Collection of Information section, we discuss the initial design, development, and testing costs per API. We next discuss the total maintenance cost for all four APIs.
As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25606), once the API is established, we believe there would be an annual cost to maintain the FHIR server, including the cost of maintaining the necessary patient data and performing capability and security testing. We believe there are efficiencies gained in implementation and maintenance due to the fact that these proposed APIs rely on several of the same underlying foundational technical specifications and content. For example, the same baseline standards apply, including the HL7 FHIR Release 4.0.1 and complementary security and app registration protocols. Specifically, the HL7 SMART Application Launch Implementation Guide (SMART IG) 1.0.0, including mandatory support for the “SMART on FHIR” Core Capabilities. However, we do believe that maintenance costs would be higher than what we estimated for the CMS Interoperability and Patient Access final rule for the new APIs proposed in this rule, as our estimates also account for new data mapping needs, standards upgrades, additional data storage, system testing, initial bug fixes, fixed-cost license renewals, contracting costs, and ongoing staff education and training.
To account for these maintenance costs, we based our estimates on input from industry experience piloting and demonstrating APIs for provider access,
We request public comment on our approach and assumptions for the aggregate maintenance cost of the APIs, including whether our estimate is reasonable or should be modified.
We propose new requirements for the implementation of a PARDD API. This API would address several major challenges of the prior authorization process, including identifying whether a prior authorization is required for an item or service; identifying the payer documentation requirements for prior authorization; compiling the necessary data elements to populate the HIPAA-compliant prior authorization transactions; and enabling payers to provide a specific response regarding the status of the prior authorization, including information about the reason for denial. Use of this proposed API would begin on January 1, 2026, for MA and Medicaid and CHIP FFS, for Medicaid managed care plans and CHIP managed care entities by the rating period beginning on or after January 1, 2026, and for QHPs on the FFEs for plan years beginning on or after January 1, 2026.
As discussed previously for the Provider Access API, to implement the proposed new requirements for the PARDD API, we estimate that impacted payers would conduct three major work phases: initial design, development and testing, and long-term support and maintenance. Furthermore, for this proposed API, we believe additional tasks are necessary to accomplish the proposed requirements, which we describe below as they affect the cost estimates. For the costs for the third phase—long-term support and maintenance—our methodology for the development of those costs in aggregate for all proposed APIs is presented in section V.C.3. of this proposed rule.
We base our estimate on feedback from industry experts on the anticipated burden of implementing the PARDD API. We believe this to be a reasonable estimate of the implementation burden on payers to develop APIs that can facilitate the prior authorization process. In addition to implementing the PARDD API, these payers would be required to send a reason for denial for prior authorization requests that are denied. As discussed in section II.D. of this proposed rule, while the PARDD API would use the HL7 FHIR standard to support its basic capabilities, covered entities must also use the adopted X12 278 standard and remain HIPAA-compliant. Given the added complexity of accounting for the HIPAA standards, we have accounted for the multiple skill sets required and licensing costs for accessing the X12 standards in developing the burden estimates. The recommended HL7 IGs are freely available, as HL7 provides access to all IGs as open-source materials. This also makes the HL7 standards, IGs, many reference implementations, and test scripts available free of charge to the healthcare and developer community. These low- or no-cost HL7 resources support our belief that payers would incur minor costs for implementing the new standards. As such, we have accounted for the necessary engineers, subject matter experts, and health informaticists in our estimates. These personnel resources would, for example, need to convert payers' prior authorization documentation rules into computable, structured formats, create provider questionnaires regarding whether a patient had a medical necessity for a medical item or service, create formats that could interface with the provider's EHR or practice management system, create and execute mapping between the HL7 and X12 codes, and integrate the PARDD API with the payer's system.
As noted previously, although this provision would be applicable on January 1, 2026, this API would be under development before that date. Acknowledging that impacted payers would have varying technological and staffing capabilities, we estimate that the development of the API would require 6 to 12 months of work. Expecting that this proposed rule will be finalized by mid-year 2023, we have distributed the cost over approximately two-and-a-half calendar years to give payers the flexibility to complete the necessary work (see Table 19).
Table 14 presents total burden estimates for the PARDD API (initial design phase and the development and testing phase). This table presents the calculations associated with the total costs. The numbers from this table are used in the summary table (Table 19) to present costs per year for 3 years. Based on the same assumptions as those included in the CMS Interoperability and Patient Access final rule, we used the medium estimate as the primary estimate.
The narrative description provided for Table 13 also applies to Table 14. Both tables estimate API costs for 365 organizations and indicate follow-up annual maintenance costs by analyzing costs for a single payer using a team spanning approximately ten occupational titles.
We request public comment on our approach and assumptions for the one-time implementation cost of the PARDD API, including whether our estimates
To increase transparency and reduce burden, we are proposing to require that impacted payers, not including QHP issuers on the FFEs, send prior authorization decisions within 72 hours for urgent requests and 7 calendar days for non-urgent requests. We are proposing that the payers would have to comply with these provisions 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).
In order to implement this policy, there would be up-front costs for impacted payers to update their policies and procedures. We anticipate this burden per payer is 8 hours of work by a general and operations manager to update the policies and procedures, reflecting two half-days of work at a per-entity cost of $967. Therefore, the total burden for all 365 impacted payers is 2,920 hours of work at a first-year cost of $0.4 million (rounded).
These calculations are summarized in Table 15:
We request public comment on our assumptions, estimates, and approach.
To support transparency for patients to understand prior authorization processes, provide some assistance in choosing health coverage, and for providers when selecting payer networks to join, we are proposing to require that impacted payers publicly report certain plan-level prior authorization metrics on their websites or via a publicly accessible hyperlink(s). Impacted payers would be required to report aggregated data annually for the previous calendar year's data, beginning March 31, 2026.
We estimate that impacted payers would conduct two major work phases: implementation, which includes defining requirements and system design (and updates) to generate and compile reports; and maintenance, including an annual compilation of reports and public reporting of metrics on a website or through a publicly accessible hyperlink(s). In the first phase, we believe impacted payers would need to define requirements concerning the types and sources of data that would need to be compiled regarding prior authorization activities and data, build the capability for a system to generate reports, and update or create a public web page to post the data. In the second phase, we believe impacted payers would need to create the reports and post them to a public web page annually.
Table 16 discusses the activities, hours, and dollar burdens for the first-year implementation and estimated annual maintenance costs. We assume a team of two staff consisting of a software and web developer with a business operations specialist.
• First-year implementation would impose a burden of 320 hours for the first year and 120 hours for subsequent years, at the cost of $30,000 and $9,000 (rounded), for the first and subsequent years, respectively.
• The aggregate burden of the first-year implementation across 365 impacted payers would be 117,000 hours and 44,000 hours (rounded) for the first and subsequent years, respectively, at a cost of $10.8 million and $3.3 million (rounded) for the first and subsequent years.
We request public comment on this approach and our assumptions.
To improve patient access to their health information through care coordination between health plans, as discussed in section II.C. of this proposed rule, we propose new requirements for impacted payers to implement and maintain a Payer-to-Payer API. These proposals would improve care coordination among payers by requiring payers to exchange, at a minimum, adjudicated claims and encounter data (excluding provider remittances and enrollee cost-sharing information), all data classes and data elements included in a content standard at 45 CFR 170.213, and pending and active prior authorization decisions. This exchange would be done using an HL7 FHIR Payer-to-Payer API implemented by 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 QHPs on the FFEs for plan years beginning on or after January 1, 2026). For a complete discussion of the data types proposed to be exchanged, please refer to section II.C. of this proposed rule.
As discussed for the other APIs proposed in this rule, we estimate that impacted payers would conduct three major work phases: initial design, development and testing, and long-term support and maintenance. For the Payer-to-Payer API, we believe there may be additional tasks necessary to accomplish the proposed requirements, which we describe below with respect to their impact on cost estimates. The costs for the third phase, long-term support and maintenance, and our methodology for the development of those costs in aggregate for all proposed APIs are presented in section IV.C.3. of this proposed rule.
Payers should be able to leverage the API infrastructure already accounted for in the Patient Access API finalized in the CMS Interoperability and Patient Access final rule and the Provider Access API proposal in this rule. As discussed in the CMS Interoperability and Patient Access final rule (as well as the companion 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program final rule (85 FR 25642)) and this proposed rule, payers would be using the HL7 FHIR standards for content and transport, recommended IGs to support interoperability of data sharing, as well as the same underlying standards for security, authentication, and authorization. Taken together, these standards would support the proposed Payer-to-Payer API. Thus, we believe there would be some reduced development costs to implement the Payer-to-Payer API because of efficiencies gained in implementing the same underlying standards and IGs for the other APIs proposed in this rule.
We believe there would be some costs for impacted payers to implement the proposed Payer-to-Payer API that are unique to this API. Based on input from current industry experience testing the implementation of this API, there could be costs to test and integrate the Payer-to-Payer API with payer systems, albeit potentially lower costs than those estimated for the Provider Access API. We estimate the one-time implementation costs at about one-third the cost of a full de novo Provider Access API implementation based on input from developers who have implemented and piloted prototype APIs using the proposed required standards. As such, we have accounted for the necessary skill sets of staff required as we also believe there would be unique costs for implementing the HL7 FHIR Payer Coverage Decision Exchange (PDex) IG so that payers can exchange active and pending prior authorization decisions and related clinical documentation and forms when an enrollee or beneficiary enrolls with a new impacted payer.
Table 17 presents the total activities, hours, and dollar burdens for implementing the Payer-to-Payer API given our assumptions (initial design phase and the development and testing phase). Based on the same assumptions as those published in the CMS Interoperability and Patient Access final rule, we have the medium estimate as the primary estimate. We have included a similar narrative explanation of Table 17 as that provided for Table 13 above.
• For the primary estimate, one-time implementation efforts for the first two phases would require, on average, a total of 916 hours per organization at an average cost of $96,072 per organization.
• The aggregate burden of the one-time implementation costs across 365 impacted payers would be 334,000 hours (rounded) at the cost of $35.1 million (rounded). This corresponds to the primary estimate; the primary and high estimates are obtained by multiplying the low estimate by factors of two and three, respectively.
As noted previously, although this provision would be applicable on January 1, 2026, we believe the APIs would be under development before that date. Acknowledging that impacted payers would have varying technological and staffing capabilities, we estimate that development of the APIs would require 6 to 12 months of
We request public comment on our approach and assumptions for the cost of the Payer-to-Payer API, including whether our estimates and ranges are reasonable or should be modified.
The estimates in this section have been submitted to OMB in a PRA package (OMB control number 0938-1278).
As explained in section II.E. of this proposed rule, commenters to the December 2020 CMS Interoperability proposed rule (85 FR 82586) expressed support for requiring healthcare providers to use electronic prior authorization as part of the QPP MIPS for MIPS eligible clinicians, or the Conditions of Participation/Conditions for Coverage requirements for eligible hospitals, and other providers and suppliers. Commenters indicated these would be appropriate levers by which CMS should propose new or additional provisions that would require the use of APIs to enable enhanced electronic documentation discovery and facilitate electronic prior authorization.
To incentivize MIPS eligible clinicians, eligible hospitals, and CAHs to implement and use electronic prior authorization and the corresponding API, we are proposing in section II.E. of this proposed rule to add a new measure titled “Electronic Prior Authorization” for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program beginning with the performance period/EHR reporting period in CY 2026.
We are proposing that MIPS eligible clinicians, eligible hospitals, and CAHs must report the Electronic Prior Authorization measure beginning with the CY 2026 performance period/EHR reporting period, but the measure would not be scored for CY 2026. For this measure, we propose that a MIPS eligible clinician, eligible hospital, or CAH must request a prior authorization electronically from a PARDD API using data from CEHRT and report a numerator and denominator or claim an exclusion if applicable.
The burden in implementing these proposed requirements consists of the following steps: creating or implementing software to capture the data, capturing the data, and reporting the measure as specified by CMS. Beyond implementation, the burden lies in maintaining compliance of the system to support all functionality, including the ability to generate accurate and timely reports. We assume the annual maintenance cost would include updates to the software to meet new reporting requirements for the QPP MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program on behalf of participating MIPS eligible clinicians, eligible hospitals, and CAHs. Such an update would include the ability to report the electronic prior authorization measure as required by CMS. System maintenance is an umbrella term that includes all activities needed to keep a system running. The two main components of system maintenance are preventive and corrective maintenance, which include software tasks such as fixing bugs, updating data sources, deleting old software tasks, and adding new tasks. Maintenance requirements for systems both in this proposed rule and in the December 2020 CMS Interoperability proposed rule were estimated at 25 percent of total software creation costs, reflecting updates and bug fixes, as well as deletion and creation of software tasks (85 FR 82649). Therefore, although we anticipate there would be a moderate software update to implement the provisions of this proposed rule, there would be no added burden over and above the burden of maintaining already existing software.
The data for the reports on prior authorizations and related claims should already be stored in the system software of healthcare providers who may be required to retain such data for compliance and regulatory reasons. To report the measure as specified by CMS, the actual added burden that the proposals in this proposed rule would impose is the burden of extracting data and preparing it in report form.
For the added burden of extracting, compiling, reviewing, and submitting data, we assume that for each report, a Medical Records Specialist would spend half a minute extracting the already-existing data at a cost of $0.39 (
The following items provide support and rationale for the entries in Table 18:
• The hourly burden estimates of
• The estimate of 4,500 hospitals (including eligible hospitals and CAHs) is consistent with the revised estimates presented in the FY 2023 IPPS/LTCH PPS final rule (87 FR 49393).
• The existing QPP MIPS reporting policies allow MIPS eligible clinicians to report at the individual or group level. Based on the information available from Table 122 in the CY 2023 PFS final rule (87 FR 69404, 70154), we estimate 54,770 individual or group MIPS eligible clinicians would submit data for the Promoting Interoperability performance category for the CY 2026 performance period/CY 2028 MIPS payment year. The 54,770 is the sum of the 43,117 individual clinicians expected to submit performance data to QPP MIPS, plus the 11,633 groups expected to submit performance data to QPP MIPS, plus 20 subgroups. The information collection requirements currently approved under OMB control number 0938-1314 are approved through January 31, 2025.
The FY 2023 IPPS/LTCH PPS final rule uses median hourly wages (87 FR 49393), whereas this proposed rule and the CMS Interoperability and Patient Access final rule (85 FR 25605) use mean hourly wages. For purposes of illustration, we have provided both estimates.
For eligible hospitals and CAHs the total cost is $1,740 (4,500 hospitals and CAHs ×
For MIPS eligible clinicians, the total cost is $21,186 (54,770 clinicians ×
The previous sections have explained the costs of individual provisions in the proposed rule. Table 19 summarizes costs for the first and subsequent years of these provisions and is based on the following assumptions:
• A publication date of mid-year 2023 for the final rule.
• The effective date for all provisions is January 1, 2026. For the Electronic Prior Authorization measure, this would be required for the QPP MIPS Promoting Interoperability performance category beginning with the 2026 performance period for MIPS eligible clinicians and the Medicare Promoting Interoperability Program starting with the 2026 EHR reporting period for eligible hospitals and CAHs. Accordingly, the COI summary Table 19 reflects costs beginning in 2027, which is year 5 relative to mid-year 2023, the expected publication date of this proposed rule. The table below summarizes the total information burden for all reporting requirements, APIs, and the reporting required under the QPP MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program. The last line of the table is the total cost for all impacted payers and providers, the estimated burden, and the costs per year. The text below offers highlights from our analysis.
• For the three new APIs (Provider Access, Prior Authorization Requirements, Documents, and Decisions (PARDD), and Payer-to-Payer), we assume implementation would take place uniformly over 30 months (the time from the expected publication date (mid-year 2023) for the final rule until the applicable compliance date in 2026).
• Maintenance costs for the three APIs are, as indicated in the tables of this section, assumed to be 25 percent of total costs; we believe these maintenance costs would be incurred in years 2026 and beyond.
• For provisions requiring policy updates or first-year implementation costs, we believe it is most reasonable that these first-year costs would take place in 2026, the first year the rule is in effect, and that subsequent year implementation costs, as reflected in the various tables in this section, would take place in years 2027 and beyond.
• Since the Electronic Prior Authorization measure would not be applicable until 2026, no costs are reflected from 2023 through 2025.
• Since the targeted publication date of this final rule is mid-year 2023, we treat 2023 as a half-year. For purposes of allocating software development costs, 2023 is therefore one-half the costs expected to be incurred during 2024 and 2025.
• Labor costs in Table 19 are either BLS wages when a single staff member is involved or a weighted average representing a team effort, which is obtained by dividing the aggregate cost by the aggregate hours. For example, in the first row, $94.32 equals the aggregate $5.5 million cost divided by the aggregate 58,400 hours.
We also note that Table 19 reflects the primary estimate. The full range of estimates for all provisions is presented in the RIA section of this proposed rule.
The provisions of this proposed rule could improve data sharing across stakeholders by facilitating access, receipt, and exchange of patient data. We are committed to providing patients, providers, and payers with timely access to patient health information. We request comment on our approaches for estimating cost burden and cost savings.
The requirements of this proposed rule are extensions of the requirements of the CMS Interoperability and Patient Access final rule (85 FR 22510). Therefore, the information collection requirements will be submitted to OMB for review and approval.
If you would like to provide feedback on these information collections, please submit your comments electronically as specified in the
As described in prior sections of this proposed rule, the proposed changes to 42 CFR parts 422, 431, 435, 438, 440, and 457 and 45 CFR part 156 further support CMS' efforts to empower patients by increasing electronic access to healthcare data, while keeping that information safe and secure. The proposals in this rule build on the foundation we laid out in the CMS Interoperability and Patient Access final rule to move the healthcare system toward increased interoperability by proposing to increase the data sharing capabilities of impacted payers, encourage healthcare providers' use of new capabilities, and make health-related data more easily available to patients through standards-based technology.
If finalized, the proposals in this rule would place new requirements on MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to improve the electronic exchange of health-related data and streamline prior authorization processes. And these proposals could improve health information exchange and facilitate appropriate and necessary patient, provider, and payer access to health information via APIs. Our proposals related to prior authorization are also intended to improve certain administrative processes. The proposed rule would also add a new measure for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians under the QPP MIPS Promoting Interoperability performance category.
We have examined the impacts of this proposed rule as required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (January 18, 2011), the Regulatory Flexibility Act (RFA) (September 19, 1980, Pub. L. 96-354), section 1102(b) of the Act, section 202 of the Unfunded Mandates Reform Act of 1995 (March 22, 1995, Pub. L. 104-4), and Executive Order 13132 on Federalism (August 4, 1999).
Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health, and safety effects, distributive impacts, and equity). Section 3(f) of Executive Order 12866 defines a “significant regulatory action” as an action that is likely to result in a rule: (1) having an annual effect on the economy of $100 million or more in any 1 year, or adversely and materially affecting a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or state, local, or tribal governments or communities (also referred to as “economically significant”); (2) creating a serious inconsistency or otherwise interfering with an action taken or planned by another agency; (3) materially altering the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raising novel legal or policy issues arising out of legal mandates, the President's priorities, or the principles set forth in the Executive order.
A Regulatory Impact Analysis must be prepared for major rules with economically significant effects ($100 million or more in any 1 year). Based on our estimates, OMB's Office of Information and Regulatory Affairs has determined this rulemaking is “economically significant” as measured by the $100 million threshold. Accordingly, we have prepared a Regulatory Impact Analysis that, to the best of our ability, presents the costs and benefits of this proposed rulemaking.
As noted later in this section, we believe that our proposed policies, if finalized, would result in some financial burdens for impacted payers and providers as discussed in section IV. of this proposed rule. We have weighed these potential burdens against the potential benefits, and believe the potential benefits outweigh any potential costs. Based on our estimates, the total burden across all providers would be reduced by at least 206 million hours over 10 years, resulting in a total cost savings over 10 years of approximately $15 billion (see Table 24). However, for reasons discussed later in this proposed rule, these savings are neither included in the 10-year Summary Table (N8), nor in the Monetized Table (N10).
Executive Order 13272 requires that HHS thoroughly review rules to assess and take appropriate account of their potential impact on small businesses, small governmental jurisdictions, and small organizations (as mandated by the Regulatory Flexibility Act (RFA)). If a proposed rule may have a significant economic impact on a substantial number of small entities, then the proposed rule must discuss steps taken, including alternatives considered, to minimize the burden on small entities. The RFA does not define the terms “significant economic impact” or “substantial number.” The Small Business Administration (SBA) advises that this absence of statutory specificity allows what is “significant” or “substantial” to vary, depending on the problem that is to be addressed in rulemaking, the rule's requirements, and the preliminary assessment of the rule's impact. Nevertheless, HHS typically considers a “significant” impact to be 3 to 5 percent or more of the affected entities' costs or revenues.
For purposes of the RFA, we estimate that many impacted payers and providers are small entities, as that term is used in the RFA, either by being nonprofit organizations or by meeting the SBA definition of a small business. For purposes of the RFA, small entities include small businesses, nonprofit organizations, and small governmental jurisdictions. The North American Industry Classification System (NAICS) is used in the U.S., Canada, and Mexico to classify businesses by industry. While there is no distinction between small and large businesses among the NAICS categories, the SBA develops size standards for each NAICS category.
In analyzing the impact of this proposed rule, we take note that there would be a quantifiable impact for the following stakeholders.
Updates to systems implementing the various APIs described throughout the preamble, including any reporting requirements, would be performed by the 365 payer organizations. Throughout this section of the proposed rule, we also use the term parent organizations to refer to the impacted payers, as we did in the CMS Interoperability and Patient Access final rule (85 FR 25510), which includes the state Medicaid and CHIP agencies. The combined parent organizations administer MA, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.
The NAICS category relevant to these proposed provisions is Direct Health and Medical Insurance Carriers, NAICS 524114, which have a $41.5 million threshold for “small size.” Seventy-five percent of payers in this category have under 500 employees, thereby meeting the definition of small businesses.
If the proposals in this rule are finalized, the 365 parent organizations, including state Medicaid and CHIP agencies, would be responsible for implementing and maintaining three new APIs, updating policies and procedures regarding timeframes for making prior authorization decisions, and reporting certain metrics either to CMS or making information available to the public. MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs are classified as NAICS code 524114, direct health insurance carriers. We are assuming that a significant number of these entities are not small. We note that none of the state Medicaid and CHIP agencies are considered small. MA organizations and state Medicaid managed care plans and CHIP managed care entities have many of their costs covered through capitation payments from the Federal Government to MA organizations or through state payments. Based on this discussion, there is no significant burden.
If finalized as proposed, some QHP issuers on the FFEs would be able to apply for an exception to these requirements, and certain states operating Medicaid and CHIP FFS programs would be able to apply for an extension or exemption, under which they would not be required to meet the new API provisions of the proposed rule on the proposed compliance dates, provided certain conditions are met, as discussed in sections II.B., II.C., and II.D. of this proposed rule. We acknowledge that providing additional information for the annual APD submissions and existing reports would require effort, but we do not believe there would be significant burden to these entities from the proposals in this proposed rule if an extension or exemption is approved.
Each year, MA organizations submit a bid for furnishing Part A and B benefits and the entire bid amount is paid by the Government to each plan if the plan's bid is below an administratively set benchmark. If a plan's bid exceeds that benchmark, the beneficiary pays the difference in the form of a basic premium (note that a small percentage of plans bid above the benchmark, whereby enrollees pay a basic premium in addition to their Part B premium; this percentage of plans is not “significant” as defined by the RFA and is explained later in this proposed rule).
MA plans with prescription drug coverage (MA-PDs) can also offer supplemental benefits, that is, benefits not covered under Original Medicare (or under Part D). These supplemental benefits are paid for through enrollee premiums, extra Government payments, or a combination of enrollee premiums and extra Government payments. Under the statutory payment formula, if the bid submitted by an MA plan for furnishing Part A and B benefits is lower than the administratively set benchmark, the Government pays a portion of the difference to the plan in the form of a “beneficiary rebate.” The rebate must be used to provide supplemental benefits (that is, benefits not covered under Original Medicare) and/or lower beneficiary Part B or Part D premiums. Some examples of these supplemental benefits include vision, dental, hearing, fitness, and worldwide coverage of emergency and urgently needed services.
To the extent that the Government's payments to plans for the bid plus the rebate exceeds costs in Original Medicare, those additional payments put upward pressure on the Part B premium, which is paid by all Medicare beneficiaries, including those in Original Medicare who do not have the supplemental enhanced coverage available in many MA plans.
Part D plans, including MA-PD plans, submit bids and those amounts are paid to plans through a combination of Medicare funds and beneficiary premiums. In addition, for certain enrolled low-income beneficiaries, Part D plans receive Government funds to cover most premium and cost-sharing amounts that those beneficiaries would otherwise pay.
Thus, the cost of providing services by these payers is funded by a variety of Government funding and in some cases by enrollee premiums. As a result, MA and Part D plans are not expected to incur burden or losses since the private companies' costs are being supported by the Government and enrolled beneficiaries. This lack of expected burden applies to both large and small health plans.
Small entities that must comply with MA regulations, such as those in this proposed rule, are expected to include the costs of compliance in their bids, thus avoiding additional burden, since the cost of complying with any final rule is funded by payments from the Government and, if applicable, enrollee premiums.
For Direct Health and Medical Insurance Carriers, NAICS 524114, MA organizations estimate their costs for the upcoming year and submit bids and proposed plan benefit packages. Upon approval, the plan commits to providing the proposed benefits, and CMS commits to paying the plan either the full amount of the bid, if the bid is below the benchmark, which is a ceiling on bid payments annually calculated from Original Medicare data; or the benchmark, if the bid amount is greater than the benchmark.
Thus, there is a cost to plans to bid above the benchmark that is not funded by Government payments. Additionally, if an MA organization bids above the benchmark for any of its plans, section 1854 of the Act requires the MA organization to charge enrollees a premium for that amount. Table 20 reports the percentage of MA organizations bidding above the benchmark, along with the percentage of affected enrollees in recent years. This table reports aggregates of proprietary bid data collected by the Office of the Actuary. The CMS threshold for what constitutes a substantial number of small entities for purposes of the RFA is 3 to 5 percent. As shown in Table 20, both the percentage of plans and the percentage of affected enrollees are decreasing, and below this 3 to 5 percent threshold. Consequently, we conclude that the number of plans bidding above the benchmark is not substantial for purposes of the RFA.
The preceding analysis shows that meeting the direct costs of this proposed rule does not have a significant economic impact on a substantial number of small entities as required by the RFA.
There are certain indirect consequences of these provisions, which also would have an economic impact. We have explained that at least 98 percent of MA organizations bid below the benchmark. Thus, their estimated costs for providing services to Medicare beneficiaries for the coming year are fully paid by the Federal Government. However, the Government additionally pays the plan a “beneficiary rebate” amount that is an amount equal to a percentage (between 50 and 70 percent, depending on a plan's quality rating) multiplied by the amount by which the benchmark exceeds the bid. The rebate is used to provide additional benefits to enrollees in the form of reduced cost-sharing or other supplemental benefits, or to lower the Part B or Part D premiums for enrollees (supplemental benefits may also partially be paid by enrollee premiums). It would follow that if the provisions of this proposed rule cause the MA organization's bids to increase and if the benchmark remains unchanged or increases by less than the bid does, the result would be a reduced rebate and, possibly fewer supplemental benefits, or higher premiums for the health plans' enrollees. However, as noted previously, the number of plans bidding above the benchmark to whom this burden applies, do not meet the RFA criteria of a significant number of plans.
It is possible that if the provisions of this proposed rule would otherwise cause bids to increase, MA organizations would reduce their profit margins, rather than substantially change their benefit packages. This may be in part due to market forces; a plan lowering supplemental benefits even for 1 year may lose enrollees to competing plans that offer these supplemental benefits. Thus, it can be advantageous to the plan to temporarily reduce profit margins, rather than reduce supplemental benefits. The temporary claim refers to the possibility that plans will balance competitive pressures with profit targets immediately following a new regulation. As the regulations are typically finalized within a few months of the bid submission deadline, plans may have more time to enact strategies that don't require large benefit changes in subsequent years, such as negotiations for supplemental benefit offerings. However, it may be inappropriate to consider the relevant regulatory impacts (and thus the profit considerations) as temporary because the issuance of a series of regulations sustains the effects.
Based on the previously discussed considerations, the Secretary has certified that this proposed rule will not have a significant impact on a substantial number of small entities.
Title XIX of the Act established the Medicaid program as a Federal-state partnership for the purpose of providing and financing medical assistance to specified groups of eligible individuals. States claim Federal matching funds on a quarterly basis based on their program expenditures. Since states are not small entities under the Regulatory Flexibility Act, we need not discuss, in the Initial Regulatory Flexibility Analysis, the burden imposed on them by this proposed rule. With regard to Medicaid managed care plans and CHIP managed care entities, since managed care plans receive 100 percent capitation from the state, we generally expect that the costs associated with the provisions of this proposed rule would be included in their capitation rates and may be reasonable, appropriate, and attainable costs irrespective of whether they are a small business. Consequently, we can assert that there would be no significant impact on a significant number of these entities.
As discussed in sections II.B., II.C., and II.D. for the proposed API provisions, states operating Medicaid FFS and CHIP FFS programs could apply for an extension of 1 year to come into compliance with the requirements of this proposed rule. These same organizations may also apply for an exemption from the requirements if certain conditions are met.
Few, if any, QHP issuers on the FFEs are small enough to fall below the size thresholds for a small business established by the SBA. Consistent with previous CMS analysis, we estimate that any issuers that would be considered small businesses are likely to be subsidiaries of larger issuers that are not small businesses (78 FR 33238) and thus do not share the same burdens as an independent small business. Therefore, even though QHP issuers do not receive Federal reimbursement for the costs of providing care, we do not conclude that there would be a significant small entity burden for these issuers. In addition, we propose an exception process be available for QHPs on the FFEs, which further helps to address burden that could otherwise prohibit a QHP issuer from participating in an FFE.
In response to public comments on the December 2020 CMS Interoperability proposed rule (85 FR 82586), CMS is proposing a new Electronic Prior Authorization measure for MIPS eligible clinicians under the QPP MIPS Promoting Interoperability performance category, and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. The measure would be required for reporting beginning in CY 2026.
With regard to MIPS eligible clinicians, eligible hospitals, and CAHs, a discussion of the burden placed on these entities were presented in section IV.C.8, Table 18. That table shows that the burden per individual provider is under $2.50 per year (one half-minute of labor times an hourly wage of under $50, depending on whether one uses a mean or median). Consequently, the Secretary asserts that the provisions of this proposed rule do not represent a significant burden on providers.
Based on the information provided previously, we conclude that the requirements of the RFA have been met by this proposed rule.
Section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) also requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates require spending in any 1 year of $100 million in 1995 dollars, updated annually for inflation. In 2022, that threshold is approximately $165 million. This proposed rule would not impose an unfunded mandate that would result in the expenditure by state, local, and tribal governments, in the aggregate, or by the private sector, of more than $165 million in any 1 year.
Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent final rule) that imposes substantial direct costs on state and local governments, preempts state law, or otherwise has federalism implications. As previously outlined, while the API provisions would be a requirement for state Medicaid and CHIP agencies under these proposals, the cost per beneficiary for implementation is expected to be negligible when compared with the overall cost per beneficiary. This analysis does not consider Federal matching funds provided to state Medicaid and CHIP agencies, but the conclusion is the same: there is not expected to be a significant cost impact on state entities. For Medicaid and CHIP, we do not believe that the proposals in this rule would conflict with state law, and therefore, do not anticipate any preemption of state law. As discussed in section II.D. of this proposed rule, some state laws regarding timeframes for prior authorization decisions may be different than the proposals in this proposed rule. However, an impacted payer would be able to comply with both state and Federal requirements by complying with whichever imposes the shorter timeframe. We invite states to comment on this proposed rule if they believe any proposal in this rule would conflict with state law.
If regulations impose administrative costs on private entities, such as the time needed to read and interpret this proposed rule, we should estimate the cost associated with regulatory review. We model our estimates of this burden based on similar estimates presented in the CMS Interoperability and Patient Access final rule (85 FR 25510). There are three numbers needed to calculate this estimate:
The staff involved in such a review would vary from one parent organization to another. We believe that a good approximation for a range of staff would be a person such as a medical and health service manager or a lawyer. Using the wage information from the BLS for medical and health services managers (Code 11-9111) and lawyers (Code 23-1011) we estimate that the cost of reviewing this proposed rule is $128.71 per hour, including overhead and fringe benefits.
In the CMS Interoperability and Patient Access final rule, we estimated 6 hours of reading time. Therefore, we believe 10 hours would be enough time for each parent organization to review relevant portions of this proposed rule.
We believe the review would be done by both parent organizations that would be required to implement the proposed API provisions, and by the physician and provider specialty societies. For parent organizations, we have used an assumption of 365 parent organizations throughout this proposed rule. For physician practices, individual physician practices rely on their specialty societies to read content such as proposed rules for them. The Relative Value Scale Update Committee (RUC) has 32 members representing all specialties.
Thus, we estimate a one-time aggregated total review cost of $1.3 million ($128.71 times 10 hours of reading time times 500 entities times two staff per entity). We request comment on our estimate.
The proposed provisions of this rule all have information collection-related burden. Consequently, the impact analysis may be found in Table 19 of the Collection of Information in section IV. of this proposed rule. To facilitate a review of the provisions and estimates made in the Collection of Information, we have included Table 21, which provides the related ICRs by number and title, as well as the table numbers for which impact is presented.
Additionally, this Regulatory Impact Analysis section provides an analysis of potential savings arising from the replacement of paper approaches to prior authorization and other plan requirements with an electronic method. Although these savings are neither included in monetized tables nor in summary tables, as further discussed later in this proposed rule, we believe that these large savings are an important consideration in evaluating this proposed rule. We have identified assumptions for these analyses, and we request public comment.
Table 27 of this section, using Table 19 as a basis, provides a 10-year impact estimate. Table 27 includes impact by year, by type (parent organizations, including Medicaid and CHIP state agencies), as well as the cost burden to the Federal Government, allocations of cost by program, and payments by the Federal Government to Medicare Advantage, Medicaid, and CHIP, as well as the premium tax credits (PTC) paid to certain enrollees in the individual market.
In this proposed rule, we continue to build on the efforts initiated with the CMS Interoperability and Patient Access final rule and the work we have done to advance interoperability, improve care coordination, and empower patients with access to their healthcare data. This proposed rule covers a range of policies aimed at achieving these goals. We carefully considered alternatives to the policies we are proposing in this rule, some of which were included in the December 2020 CMS Interoperability proposed rule, and on which we received public comments. Those public comments and other engagements over the year support our conclusions that none of the alternatives would adequately or immediately begin to address the critical issues related to patient access and interoperability or help to address the processes that contribute to payer, provider, and patient burden.
We now discuss the alternatives we considered to our proposed provisions and the reasons we did not select them as proposed policies.
We are proposing to require that payers make enhancements to the Patient Access API finalized in the CMS Interoperability and Patient Access final rule including proposing additional information be made available to patients through the Patient Access API, and proposing certain metrics about patient use of the Patient Access API be reported directly to CMS annually. Before proposing to require these provisions, we considered several policy alternatives.
As we discussed in the CMS Interoperability and Patient Access final rule (85 FR 25627), one alternative to the proposed updates to the Patient Access API we considered is allowing payers and providers to upload patient data directly to a patient portal, operated by a provider. However, despite the availability of patient portals, ONC reported in 2020 that only 60 percent of individuals have been offered online access to their medical records by either their healthcare provider or payer. And of the individuals that were offered access, approximately 40 percent of those viewed their record.
A portal is operated by a provider or payer as an entry point to a finite set of data available from an individual organization. These portals do not lend themselves as well to interoperability because they do not enable other organizations, or the patient, to provide additional data to the system. Because business models and processes pertaining to patient portals are varied across the industry, and any one patient could be associated with a number of different portals, there is no available data today with which we can evaluate the cost impacts of requiring individual portals versus the estimates for enhancing the Patient Access API.
As explained in the CMS Interoperability and Patient Access final rule (85 FR 25627), another alternative considered was to allow Health Information Exchanges (HIEs) and Health Information Networks (HINs) to serve as a central source for patients to obtain aggregated data from across their providers and payers in a single location. HIEs and HINs could provide patients with information via an HIE portal that is managed by the patient.
However, as previously described, there are reasons why patient portal access does not lend itself to interoperability or innovation, and all patients might not have access to an HIE or HIN. For the reasons described, we ultimately decided to proceed with our proposed requirements versus these alternatives.
In the December 2020 CMS Interoperability proposed rule (85 FR 82592), we proposed to require impacted payers to request a privacy policy attestation from health app developers when their health app requests to connect to the payer's Patient Access API. We proposed that the attestation would include, at a minimum, that the health app has a plain language privacy policy that is always publicly available and accessible and has been affirmatively shared with the patient prior to the patient authorizing the app to access their health information. In addition, the attestation we proposed included yes/no elements as to whether the privacy policy specifically communicates how the patient's health information could be accessed, exchanged, or used.
We considered proposing that policy again, but based on substantial public comment, we believe that this type of attestation would not benefit patients in ways that would outweigh the burden on impacted payers and that such a policy could have unintended consequences for patients. Under that proposal, a health app developer would only be attesting to the format and inclusion of certain information. There would be no attestation that the substance of the privacy policy meets specific minimum requirements or best practices. We believe that having payers inform patients that an app developer has attested to the form and format of a privacy policy could easily be misinterpreted as assurance that the substance of the privacy policy has been reviewed and found acceptable by the payer (or CMS). We are concerned that requiring such an attestation would only give the appearance of privacy and security for patients' health data, without providing additional privacy or security. Though we did not pursue this option, we continue to work with the Office for Civil Rights and the Federal Trade Commission
Regarding reporting Patient Access API metrics, we considered requiring impacted payers to publicly report these metrics more frequently than annually. For example, we considered a quarterly requirement. Public comments on the December 2020 CMS Interoperability proposed rule indicated a preference for less frequent reporting, which would in turn create less burden on payers. Annual statistics on such utilization should be sufficient to accomplish our goals.
We also considered alternative effective dates for the proposed policies. For example, we considered January 1, 2024, and 2025 as possible compliance dates for the Patient Access API enhancements. However, based on the public feedback we received from the December 2020 CMS Interoperability proposed rule, we believe it is more appropriate, and less burdensome on impacted payers to propose an effective date for these policies beginning on 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), which provides for a two year implementation time frame.
In this proposed rule, to better facilitate the coordination of care across the care continuum, we are proposing to require impacted payers to implement and maintain a Provider Access API. This proposed API would require payers to make available to certain providers the same types of data they would make available to patients via the enhanced Patient Access API.
Alternatively, we considered other data types that could be exchanged via the Provider Access API. We considered only requiring the exchange of all data classes and data elements included in a content standard at 45 CFR 170.213. While this would be less data to exchange and, thus, potentially less burdensome for impacted payers to implement, we believe that claims and encounter information can complement the content standard and offer a broader and more holistic understanding of a patient's interactions with the healthcare system. Furthermore, the data that we propose to be made available through the proposed Provider Access API aligns with the data that we propose to be made available to individual patients through the Patient Access API. Once the data are mapped and prepared to share via one FHIR API, these data should be available for all payer APIs to use within that organization.
We also considered having only payer claims and encounter data available to providers, understanding that providers are generally the source of clinical data. This could limit the burden on payers by requiring less data to be made available. However, even if a provider is the source for the clinical data relevant to their patient's care, a provider may not have access to clinical data from other providers a patient is seeing. As a result, and understanding payers were already preparing these data for use in other APIs, we decided a more comprehensive approach would be most beneficial to both providers and patients and aligned the proposed Provider Access API data requirements with those proposed for the Patient Access API.
We also considered including additional data elements in this proposal as well as requiring the complete set of data available from the payer's system. We had not received recommendations for such an extensive body of data and acknowledge that such a large volume of data types would require too many additional resources, and would likely not be consistent with minimum necessary provisions (unless
We are proposing to require impacted payers to implement and maintain a Payer-to-Payer API that makes certain data available to other payers via a FHIR API. This proposal would make the same data that is being made available to patients and providers also available to other payers when an enrollee changes plans, and in that way allow patients to take their data with them as they move from one payer to another. Before proposing these policies, we considered several policy alternatives.
In the CMS Interoperability and Patient Access final rule, we finalized a policy to require payers to exchange data with other payers, but did not require a specific mechanism for the payer to payer data exchange. Rather, CMS required impacted payers to receive data in whatever format it was sent and accept data in the form and format it was received, which ultimately complicated implementation by requiring payers to accept data in different formats. In this proposed rule, we had the option to maintain the previous policy and forgo the API requirement. However, since the CMS Interoperability and Patient Access final rule was finalized in May of 2020, many impacted payers indicated to CMS that the lack of technical specifications for the payer to payer data exchange requirement was creating challenges for implementation, which could have created differences in implementation across the industry, poor data quality, operational challenges, and increased administrative burden. Differences in implementation approaches could have created gaps in patient health information that would have conflicted directly with the intended goal of interoperable payer to payer data exchange.
Furthermore, for the Payer-to-Payer API, once an organization implements the other proposed APIs, there would be less additional investment necessary to implement the Payer-to-Payer API as payers would be able to leverage the infrastructure already established for the Patient Access API and Provider Access API. The HL7 Da Vinci Payer Data Exchange work group has expanded their work over the past year to include two paths to exchange claims and associated clinical data. The updated background section for the recommended implementation guide provides an explanation of how the existing resources can be tailored to meet the provisions of our proposals.
We also considered which data elements would be the most appropriate to require for the exchange between payers. Similar to the Provider Access API alternatives, we considered only requiring the exchange of data classes and data elements included in a content standard at 45 CFR 170.213. As we previously described, we believe that claims and encounter information can complement the content standard and potentially allow for better care coordination, as well as more efficient payer operations. We do not believe there to be significant additional burden once the data are mapped for the other proposed APIs.
We are also proposing several policies associated with the prior authorization process. First, we are proposing to require that all impacted payers implement and maintain a Prior Authorization Requirements, Documentation, and Decision (PARDD) API. We believe this API would ultimately help patients receive the items and services they need in a timely fashion. The PARDD API aims to improve care coordination by enabling enhanced communication about when a prior authorization is required, information that is required to approve a prior authorization, and facilitating electronic prior authorization. This would add efficiencies for both payers and providers, and it could improve patient care by avoiding gaps and delays in care. This API would be accessible to providers to integrate directly into their workflow while maintaining compliance with the mandatory HIPAA transaction standards.
As proposed, by January 1, 2026, impacted payers would be required to implement and maintain a FHIR PARDD API, populate the API with their list of covered items and services (excluding drugs) for which prior authorization is required, and any documentation requirements for the prior authorization. (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.) We considered proposing a phased approach for the PARDD API where payers would first make the functionality available for a specified subset of their prior authorization rules and requirements, as opposed to all of the rules and requirements for all applicable items and services at one time. We also considered requiring that payers only prepare the PARDD API for a specific set of services most commonly requiring prior authorization across payers. However, we believe this would be more burdensome in some ways. It would require providers to use different systems to find requirements for different services for each payer. If the requirements for different services were in different places, such as some information in payer portals and some through the PARDD API, providers would have to spend additional time searching for the information in multiple locations for one payer. Therefore, we believe it is ultimately less burdensome overall to require impacted payers to populate the prior authorization and documentation requirements for all covered items and services (excluding drugs) at the same time. There are several pilots underway to test the PARDD API, as well as other tools. The results are all positive for the policies that are being tested and showcased in demonstrations at conferences. However, no quantitative data have yet been shared with CMS to
We also considered a phased timeline approach to implement these functionalities. For example, we considered first requiring implementation of the requirements and documentation functionality in 2026 and then a year later requiring implementation of the submission and decision functionality of the API. We also considered whether to propose these two capabilities as separate APIs. However, considering the enforcement discretion we exercised for the APIs finalized in the CMS Interoperability and Patient Access final rule, we believe it is more appropriate to propose compliance dates for this policy in 2026, providing payers with more time to potentially implement both functionalities at the same time.
We also considered whether we should propose to require that payers post, on a public-facing website, their list of items and services for which prior authorization is required and populate the website with their associated documentation rules as an interim step while they implement the PARDD API. However, we are aware that some payers already have this information publicly available, and we determined that this would not provide any reduced burden on payers or providers at this time. There is burden associated with updating the information on a website as the list of prior authorization items is likely to change frequently, due to the availability of new therapies. We seek comment on whether a payer website to provide additional transparency to prior authorization requirements and documentation would be beneficial in reducing the overall burden in this process.
Another alternative we considered to support prior authorization was to only use the X12 standard transaction adopted under HIPAA rather than require the implementation of a FHIR API. The X12 standard defines the content and format for the exchange of data for specific business purposes and is designed for administrative transactions between administrative systems. For prior authorization, the adopted standard is the X12 278 version 5010. The X12 standard for prior authorization does not have the functionality of the HL7 IGs to support the proposed PARDD API to make available the response from the payer in the provider's health IT system. Furthermore, the CRD, DTR, and PAS IGs combined, provide the necessary information for the provider to know the coverage and documentation requirements to submit a compliant prior authorization request for each payer. X12 is not designed to enable the use of SMART on FHIR apps connected to the provider's EHR system, nor is it designed for the scope envisioned in this proposed rule, including extraction of payer rules, a compilation of data into electronic-based questionnaires, or communication with EHRs. The adoption rate of the mandated X12 278 Version 5010 standard is low, according to data compiled annually by CAQH (described earlier in this proposed rule). By 2020, the use of the X12 278 standard for prior authorization transactions had reached 21 percent despite having been available since 2012. Background on the industry's failure to use the X12 standards is explained in more detail in section II.D.
We are proposing other provisions, including requiring certain impacted payers to ensure that prior authorization decisions are made within 72 hours of receiving an expedited request and no later than 7 days after receiving a standard request, and proposing to require impacted payers to publicly report prior authorization metrics on their websites or via a publicly accessible hyperlink(s) annually.
We considered several alternative timeframe policies before deciding to propose these policies. We considered alternative timeframes under which payers could provide a decision in less than 72 hours (for expedited decisions) and 7 days (for standard decisions). For example, we considered requiring payers to provide a decision in 48 hours for expedited requests and 3 days for standard requests. We are seeking comment on this proposal but decided not to make it an alternative proposal due to concerns over the feasibility of implementing such timeframes. We will reevaluate these timeframes at a future date once the PARDD API is in place, as we believe the PARDD, as well as the other efficiencies introduced in this proposed rule, would make shorter timeframes more feasible. Understanding the importance of providers and patients getting decisions as quickly as possible, we believe that the timeframes we propose in this rule are a significant step to help increase reliability in the prior authorization process and establish clear expectations without being overly burdensome for payers.
These timeframes allow payers to process the prior authorization decisions in a timely fashion and give providers and patients an expectation for when they can anticipate a decision and know when they can receive care. We also considered whether more than 7 days would be necessary for complex cases, for example, adding an additional decision timeframe category to include complex cases. However, we did not propose this alternative because we believe it is important for patients and providers to be able to receive a decision in a shorter timeframe. We believe 7 days is sufficient time for a payer to process prior authorization decisions.
Regarding publicly reporting prior authorization metrics, we considered requiring impacted payers to publicly report these metrics more frequently than annually, such as on a quarterly basis. However, because most patients typically shop for health insurance coverage on an annual basis, we believe updating this information annually be sufficient for making decisions. We also considered whether to allow payers to report on a selected subset of metrics, rather than taking an “all or nothing” approach. After further consideration, we believe all metrics proposed would be valuable for payers to report publicly.
We also considered reporting these metrics at the parent organization versus at the organization, plan, or issuer level for all impacted payers. After further consideration, we decided this may not be truly operational and may be too aggregated a level of reporting for some payer types to provide useful information for patients and providers. As a result, we are proposing reporting at the organization level for MA, state-level for Medicaid and CHIP FFS programs, plan-level for Medicaid and CHIP managed care, and at the issuer-level for QHP issuers on the FFEs.
As described in section II.D., we are proposing new requirements related to prior authorization for impacted payers, and in section II.E. we described our proposal for measure reporting for MIPS eligible clinicians, eligible hospitals, and CAHs.
In section IV., we discussed the ICRs regarding cost estimates for reporting and the potential burden specifically for the MIPS eligible clinicians, eligible hospitals, and CAHs. In this impact analysis, we discuss the anticipated cost savings of these proposals for the broader healthcare provider population, which is inclusive of, but not limited to the MIPS eligible clinicians, hospitals, and CAHs. We believe that all healthcare providers could benefit from the proposal for impacted payers to implement the API proposals in this proposed rule and base these cost-savings estimates on that total number,
The savings we calculate in this section V.G. of this proposed rule would be true savings, not transfers since they reflect savings in reducing the administrative costs required to process prior authorizations. However, these savings would be an indirect consequence of the proposed rule, not direct savings. This proposed rule supports efforts to significantly reduce time spent on manual activities. In general, it is only appropriate to claim that a regulatory provision's benefits are greater than its costs after a substantive and preferably quantitative, assessment of the pre-existing market failure and the provisions' suitability for addressing it. As a result of data limitations and other analytic challenges preventing such an assessment, the illustrative savings estimates are neither included in the monetized table, nor in the summary table of this proposed rule, nor in the 2016 dollar calculation. Nevertheless, the savings could be significant, and we believe should be a factor in the evaluation of this proposed rule. We request comment on this decision not to include the savings in the final summary Table 27 and related tables. Recognizing the potential policy interactions this proposed rule has with other future CMS and HHS rules, as well as Congressional actions, we request comment on how CMS might attribute savings benefits to avoid double-counting. What are the implications if the same effects were attributed to multiple regulations? For example, we note that the Medicare Advantage program is impacted by several CMS regulations, which may overlap with one another. How could CMS account for both costs and benefits from such policy intersections?
We note that we are only quantifying savings of reduced paperwork for healthcare providers. However, the improved efficiencies proposed in this rule have several consequences, which could lead to savings. A 2021 survey by the American Medical Association (AMA)
The approach adopted in quantifying savings is to quantify those that we can reliably estimate and note that they are minimal savings. The proposals of this rule potentially affect individual physicians, physician groups, hospitals, and CAHs. However, for purposes of quantification, we initially estimate a reduced paperwork burden for individual physicians and physician groups, which shows a savings of several billion dollars. We start the estimate with individual physicians and physician groups because we have reliable data (two multi-thousand surveys from 2006 and 2021 cited in this section of this proposed rule, which agree with each other) on (1) the number of hours per week spent on prior authorization, and (2) the proportion of hours per week spent by physicians, nurses, and clerical staff.
To then estimate reductions in spending on paperwork for prior authorization for hospitals, we assume that hospitals perform their prior authorization activities similar to individual physicians and physician groups. We make this assumption because we do not have a basis for making a more accurate assumption; that is, we do not have similar survey data for hospitals on the number of hours per week spent on prior authorization and the proportion of hours per week spent by physicians, nurses, and clerical staff.
To support the assumptions on potential benefits for hospital prior authorization, we rely on data from the 2023 Hospital Inpatient Prospective Payment Systems for Acute Care Hospitals and the Long-Term Care Hospital Prospective Payment System (FY 2023 IPPS/LTCH PPS) final rule (87 FR 48780) and the CY 2023 Hospital Outpatient Prospective Payment and Ambulatory Surgical Center Payment Systems (CY 2023 OPPS/ASC) final rule (87 FR 71748, November 23, 2022) for estimates of the number of possible organizations that could be impacted. We provide more information in this section of this proposed rule, about the estimate of the number of hospitals, 7,978,
If we assume hospitals are conducting the prior authorization process in a manner similar to physicians, then in effect we have increased the number of individual physicians and physician groups from 199,543 to 207,521 entities (199,543 individual physicians and physician groups plus 7,978 hospitals). We compute aggregate savings by first estimating the savings for a single individual physician or group physician practice and then multiplying this single savings by the number of practices. Therefore, it follows that if 199,543 individual physician and group physician practices would save money, as shown in Table 24 of this proposed rule, then 207,521 combined physician practices and hospitals would save $15.3 billion (207,521/199,543 × $14.70). When we round the updated savings to the nearest billion there is no numerical change in the savings since both $15.3 and $14.7 round to $15 billion. We believe this approach to be the clearest.
In calculating the potential savings, uncertainties arise in four areas, and the result of this illustrative analysis is that we find a minimal potential savings impact of between $10 to $20 billion over the first 10 years of implementation. To provide credibility to this savings analysis we have, where we lacked better data, underestimated any unknown quantities with minimal estimates and additionally studied the effect of a range of estimates. In the next few paragraphs, we explain each of the four uncertainties, indicate how we approached estimation, and request public comment.
To estimate the savings impact, we researched estimates of the current amount of paperwork involved in prior authorization, the type and number of staff involved, the type of physician offices involved, and hours per week staff spent engaged in prior authorization processes. Our assumptions on the relative proportion of current workload hours by type of staff are based on a survey presented by Casalino et al. (2009),
The Casalino et al. study is dated; therefore, several numbers in the article were updated, including hourly wages, the number of physician practices, and the hours per week spent on prior authorization. We only use this article for the relative proportions of workload by staff type. We have not found any other studies that address this data point for physician offices and similarly no studies that address this same information for hospitals. Staff type is important because, for example, the hourly wage for clerical staff is about one-half the hourly wage for nurses and about one-fifth the hourly wage for physicians; clearly then, the staff doing the paperwork can significantly affect savings.
Such a design allows us to update wages using the Bureau of Labor Statistics' (BLS) latest wages. It also allows the allocation of costs based on the staff member used in the analysis. We used the relative proportion of time spent by physicians, nurses, and clerical staff presented in this paper in our estimates since they seemed reasonable and were not discussed in any other survey reviewed. Thus, though the article by Casalino et al., is dated, it was useful for proportions of time spent on paperwork for prior authorization for the following reasons:
• Unlike many subsequent studies, the survey instrument was validated by several organizations.
• Unlike many subsequent studies, the number of physician practices surveyed was in the thousands.
• Finally, we note that several other estimates in the literature were reviewed,
The Casalino et al. survey excluded certain physician practices, including health maintenance organizations (HMOs), but analyzed workload by staff type (doctor, nurse, clerical, administrator, lawyer, and accountant), office type (solo, 3 to 10 physicians, 10 or more physicians), and the type of medical work involved (prior authorization, formulary, claims billing, quality, etc.). Consistent with our approach, we restricted ourselves to prior authorization activities, though formulary work could possibly add to burden related to prior authorization activities.
Table 22 presents an estimate of the current average annual paperwork burden per physician office for prior authorization activities. Table 22 estimates an average annual burden per individual physician or physician group practice of 676 hours at a cost of $48,882. In reaching this estimate, we note all of the following:
• The relative hours per week for physicians, registered nurses, and clerical staff were, as previously discussed, kept the same as in the Casalino et al. article.
• The labor costs were updated to 2021, using the Bureau of Labor Statistics (BLS) mean hourly wages.
• The 20.4 hours per week estimated for prior authorization in the Casalino et al. article was reduced to 13 hours per week based on the AMA survey conducted in 2021.
• As previously discussed, we initially estimated reduced paperwork burden for individual physician and group physician practices and updated these numbers at the end of our entire analysis to include hospitals for which we do not have definitive surveys.
Table 22 presents the current hour and dollar burden per physician group and individual physician office. To obtain the aggregate annual burden of prior authorizations for all physician practices, including those exclusively furnishing services to Fee for Service (FFS) enrollees, Casalino et al. (2009) multiplies the Table 22 burdens per physician group and individual physician office by the total number of individual and group physician practices. Thus, we need an estimate of the total number of individual and group physician practices.
We assume there
Table 22 provides current hours spent on prior authorizations. To calculate potential savings, we must make an assumption on how much these hours could be reduced as a result of the provisions of this proposed rule.
Section II.D. of this proposed rule would require impacted payers to implement a PARDD API. As we described in that section, this API, if voluntarily used by an individual physician or within a physician group, could allow members of individual physician and physician group practices to discover whether a requested item or service requires prior authorization and, if so, the relevant documentation requirements. All provider office staff types, including physicians, nurses, and clerical staff, could experience reductions in the time needed to locate prior authorization rules and documentation requirements, which are currently either not readily accessible or available in many different payer-specific locations and formats. We believe that our proposal would make it possible for staff to use one system (such as their EHR or practice management system) or software application to find the prior authorization rules and documentation requirements for most impacted payers. With these rules and requirements more consistently and easily accessible, we anticipate a reduction in the need for providers to make multiple attempts at submitting complete information necessary for the payer to approve or deny a prior authorization. Consequently, a PARDD API could also reduce appeals and improper payments,
In addition to being able to look up whether a requested item or service requires prior authorization and, if so, the relevant documentation requirements, the PARDD API can compile the necessary data elements to populate the HIPAA-compliant prior authorization transaction along with the documentation needed and receive an approval or denial decision from the payer, including any ongoing communications regarding additional information needed or other status updates. Currently, many prior authorization requests and decisions are conducted through one of several burdensome channels, including telephone, fax, or payer-specific web portals, each of which requires taking action and monitoring status across multiple and varying communication channels.
Based on this discussion we assume the following reductions. Physicians who currently (on average over all physician groups) spend 0.6 hours per week on prior authorization (Table 22) are assumed to reduce their time by 10 percent. Nurses who currently spend one day (8.3 hours) per week on prior authorization are assumed to reduce their time to half a day, a reduction of 50 percent. Clerical staff who currently spend 4 hours a week on prior authorization are assumed to reduce their time by 1 hour, a 25 percent reduction. We discuss alternate assumptions in this section of this proposed rule, after presenting the total 10-year savings. We also specifically solicit comments from stakeholders on the reasonableness of these assumptions.
Table 23 presents the total savings in paperwork for prior authorization for a single individual or group physician practice adopting the proposals of this rule. The columns of this table are explained as follows. Column (1), the total hours per year per staff type spent on prior authorization is obtained from Table 22. Column (2) presents our assumptions, as previously discussed, on reduced time by staff type. Column (3) is the product of columns (1) and (2). Column (4) is taken from Table 22. Column (5), the total reduced dollar spending per year is obtained by multiplying columns (3) and (4). The total row indicates aggregate hours and dollars saved over all staff type.
We are not assuming that over 10 years all 199,543 individual and group physician practices would adopt the proposals of this rule. Instead we assume as follows:
• That the 54,770 MIPS eligible clinicians (individual and group) a subset of the 199,543 estimated individual and group physician practices would adopt the proposals of this rule in 2026 (the 1st year of implementation) since there are payment consequences for them not doing so.
• By 2034, 50 percent of all individual and physician practices would adopt the proposals of this rule.
We do not assume a constant increase per year but rather a gradual increase per year. We begin our assumptions with the 54,770 MIPS eligible clinicians in 2026 and end with the 99,772 (50 percent of 199,543) individual and physician group practices in 2034, expecting an exponential growth, which is characterized by a slow beginning and more rapid growth later on.
Applying these assumptions results in a $14.7 billion savings over 10 years, which are shown in Table 24. If we include hospitals by increasing the amount by 4 percent, the estimate would be $15.2 billion. The estimate rounded to the nearest billion is $15 billion.
The 4 percent increase to account for hospitals is arrived at as follows. Based on the FY 2023 IPPS/LTCH final rule (87 FR 48780) and the CY 2023 OPPS/ASC final rule (87 FR 71748) there are 3,142 Inpatient and Acute Care hospitals; 1,425 CAH hospitals; and 3,411 outpatient hospitals, or a total of 7,978 hospitals. We estimate that the hospitals represent 4 percent of the health care industry (7,978 hospitals/199,543 individual and group physician practices) of all individual and group physician practices, which we acknowledge is a rough estimate, only using a calculation of numbers. However, without additional impact studies, we propose using this as our estimate for savings opportunities.
The columns headers of Table 24 show the logic and sources of the column entries are described here:
• Column (1) gives the year, with the first year of implementation being 2026.
• Column (2) gives the total reduced hours for any individual or group physician practice adopting the proposals of this rule (Table 23).
• Column (3) gives the total reduced dollar spending for any individual or group physician practice adopting the proposals of this rule (Table 23).
• Column (4) gives the assumed percentage of individual or group physician practices adopting the proposals of this rule in any one year. In 2026 we expect 54,770/199,543 or about 27 percent of all individual and
• Column (5) gives the total number of individual and physician practices.
• Column (6) gives the total hours saved (millions of hours) by multiplying the hours saved per practice times the number of practices times the percentage of practices adopting the proposals of this rule.
• Column (7) gives the total dollars saved (billions) by multiplying the dollars saved per practice times the number of practices times the percentage of practices adopting the proposals of this rule.
• The sum of savings over the 10 years is indicated in the next to last row: There is a savings of 205 million hours of work on prior authorization resulting in $14.7 billion reduced cost over 10 years.
• The last row multiplies this amount by 207,521/199,543, as explained in the introductory paragraphs of this section V.G, to account for hospitals (Inpatient, Outpatient, and CAHs) assuming hospitals are subject to the same assumptions we made for individual physician groups.
• As can be seen, to the nearest billion, $15 billion is saved to physicians and hospitals over 10 years from adopting the proposals of this proposed rule.
If we assume additional savings, 10 percent, 50 percent, and 50 percent savings for physicians, nurses, and clerical staff respectively the savings over 10 years would be $17 billion (including savings to hospitals). If we assume less savings, 10 percent, 33 percent, and 33 percent savings for physicians, nurses, and clerical staff respectively the savings over 10 years would be $11 billion. Using a wide array of different assumptions, we expect an aggregate reduction of cost over 10 years of between $10 billion and $20 billion.
In this section, we present a 10-year summary table of costs, an analysis for Federal impacts, and the monetized table.
To analyze the cost of this proposed rule to the Federal Government, we utilize a method of allocating costs by program (MA, Medicaid, CHIP, and QHP issuers on the FFEs). As the cost is shared by the 365 parent organizations, including Medicaid and CHIP state agencies, there is no readily available way to allocate costs per parent organization across programs since the percentage of each parent organization's expenditures on the different programs is not publicly available.
To address this, we utilize the same method used in the CMS Interoperability and Patient Access final rule (85 FR 25612). In that final rule, we used the public CMS Medical Loss Ratio (MLR) files, which break out total premiums among the various programs. The advantages and disadvantages of such an approach are fully discussed in that rule. Table 25 presents the 2020 MLR data of premiums by program and the resulting percentages by program. We use these percentages to allocate costs by program. This allocation of cost by program forms a basis to calculate the Federal Government's cost for the proposed provisions of this rule.
To calculate Federal costs for MA organizations, we use the CMS internal data used to produce the CMS Trustees' Report. This internal data indicates that the Trust Fund will pay about 33 to 34 percent of plan costs over the next 10 years. The remaining costs (for the 98 to 99 percent of plans bidding below the benchmark) are borne by the plans. In a similar manner, we can calculate the Federal Medicaid payments using the percentages in Table 26.
Table 25 is based on the most recent projections of the CMS Office of the Actuary (OACT) for the Mid-Session Review of the President's FY 2022 Budget (MSR 2022).
We illustrate in the 2025 column that 41 percent (1−0.59 shown in the second row) of Federal Government payments go to the states for expenditures related to their Medicaid FFS programs and 59 percent (the number shown in the second row) goes to states for their Medicaid managed care programs. For state expenditures on Medicaid mechanized claims processing and information retrieval systems, the Federal Government pays states 90 percent of their expenditures on the design, development, installation, or enhancement of such systems, and 75 percent of their expenditures on the ongoing operation of such systems. For 2025, states receive an average of 65.9 percent FMAP for their managed care program costs as shown on the third row. Therefore, the percentage of costs paid in the first year by the Federal Government is 69.6 percent (75 percent × 41 percent + 65.9 percent × 59 percent) as shown in the fourth row. The calculation of the percent of costs paid in all years is done similarly except that in the first-year 90 percent is used for weighting instead of 75 percent. By applying these percentages to the total Medicaid costs, we obtain Federal costs for the program. These percentages are used to calculate the total dollars going from the Federal Government to states.
It should be noted that although the first year of implementation of this proposed rule is 2026, we expect plans to begin constructing software systems as soon as the rule is finalized in 2023.
Based on the previous discussion in this proposed rule, the next section shows the calculation of all impacts of this proposed rule by program, Government, and QHP issuers. The numerical impacts are presented in Table 27.
For Table 27:
• As explained in the connection with Table 19 in the Collection of Information section, the data in Table 27 is based on an expected publication date
• The bottom-line totals in the columns of Table 19 labeled “1st year cost” through “5th Year Cost” are the totals found in the “Total Cost” column of Table 26 in rows 2023 through 2027 respectively. The totals in the column “Subsequent year costs” in Table 19 are found in the rows labeled 2028 through 2032 in the “Total Cost” column of Table 27.
• The Total Cost to Providers and Hospitals and CAHs column reflects the aggregate cost of producing reports for MIPS eligible individual providers, provider groups, hospitals, and CAHs, as found in Table 19 for years 2026 and further.
• The total 10-year cost (excluding PTC payments and savings from prior authorization) is, as shown in Table 27, $1.6 billion. This number uses the primary estimates for the API provisions. The low and high 10-year total costs are $0.8 billion and $2.3 billion, respectively.
• Cost of Proposed Rule to Payers by Program columns: We applied the percentages from Table 25 to obtain the cost of the rule to payers by program (MA, Medicaid, CHIP, and QHP issuers on the FFEs).
• Cost of Proposed Rule to Government by Program columns: We applied the percentages of payment by the Federal Government discussed in the narrative on Table 26 to obtain the cost by program.
• PTC Payments: The Government does not reimburse QHPs, either partially or totally, nor prospectively or retrospectively, for their expenses in furnishing health benefits. However, the Government does offer QHP enrollees PTC credits to help cover the cost of premiums for the plans. QHP issuers on the FFEs have the option to deal with increased costs by either temporarily absorbing them (for purposes of market competitiveness—see, however, a caveat elsewhere in this regulatory impact analysis), increasing premiums to enrollees, or reducing non-essential health benefits. To the extent that issuers increase premiums for individual market-qualified health plans on the FFEs, there would be Federal PTC impacts. The purpose of the PTC is to assist enrollees in paying premiums. Since PTCs are only available if an individual purchases a qualified health plan on an Exchange and the individual has an income between 100 and 400 percent of the Federal Poverty Level, the PTC estimates apply only to Exchange plans. In the PTC estimate, we have accounted for the fact that some issuers have both Exchange and non-Exchange plans, and some issuers have only non-Exchange plans. We reflected these assumptions with global adjustments, so we believe the estimates are reasonable in aggregate.
The methodology to estimate the PTC impact of the projected expense burden is consistent with the method used to estimate the PTC impact in the CMS Interoperability and Patient Access final rule (85 FR 25612). Within the FFE states, the estimated expense burden would impact premium rates in the individual market and is spread across both Exchange and non-Exchange plans. PTCs are only paid in the Exchanges and are calculated as a function of the second lowest cost silver plan and the eligible individual's household income. The estimate of these impacts uses the assumption that the industry would increase the second lowest cost silver plan premium rate in the same amount as the overall premium rate increase. This assumption allows the application of the overall rate increase to the projected PTC payments in the FFE states to estimate the impact on PTC payments. The PTC payments are currently slightly over 50 percent of total costs.
The total cost to the Government is the sum of payments related to each program. This payment is a transfer from the Government to payers for Medicare Advantage and Medicaid, CHIP, and QHP enrollees.
• Remaining Cost to Payers columns: For MA organizations, and Medicaid and CHIP, the remaining costs are the difference between the total cost to payers and what the Federal Government pays. For the individual market, the remaining costs to payers would be the total cost absorbed by the payers and not passed on through premium increases. Since the PTC is paid on behalf of individuals and not the payers, it therefore does not reduce the expenses of the payers.
We next explain how the various plans (and states) would bear the costs remaining after Federal payments. We follow the same methodology and discussion presented in the CMS Interoperability and Patient Access final rule (85 FR 25612).
In Table 28 we explain possible ways payers may manage these extra implementation costs. We emphasize that Table 28 lists possibilities. Payers would ultimately make decisions about how to defray these remaining costs based on market dynamics and internal business decisions, and we have no uniform way of predicting what these actual behaviors and responses will be.
Medicare Advantage: In their bids (submitted the June prior to the beginning of the coverage year), Medicare Advantage plans would address the reduced rebates (arising from increased bid costs due to the increased costs of this proposed rule being included in the bid) by either: temporarily absorbing costs by reducing profit margins, reducing the supplemental benefits paid for by the rebates, or raising enrollee cost sharing or premium. We believe many plans, for competitive reasons, would choose to retain a zero-dollar premium increase and either absorb losses for 1 year or reduce rebate-funded supplemental benefits.
As required by OMB Circular A-4 (available at
In accordance with the provisions of Executive Order 12866, this proposed rule was reviewed by OMB.
Because of the large number of public comments, we normally receive on
Chiquita Brooks-LaSure, Administrator of the Centers for Medicare & Medicaid Services, approved this document on November 23, 2022.
Administrative practice and procedure, Health facilities, Health maintenance organizations (HMO), Medicare, Penalties, Privacy, Reporting and recordkeeping requirements.
Grant programs-health, Health facilities, Medicaid, Privacy, Reporting and recordkeeping requirements, State fair hearings.
Aid to Families with Dependent Children, Grant programs-health, Medicaid, Notices, Reporting and recordkeeping requirements, Supplemental Security Income (SSI), Wages.
Grant programs-health, Medicaid, Reporting and recordkeeping requirements.
Grant programs-health, Medicaid.
Administrative practice and procedure, Grant programs-health, Health insurance, Reporting and recordkeeping requirements.
Administrative practice and procedure, Advertising, Brokers, Conflict of interests, Consumer protection, Grant programs-health, Grants administration, Health care, Health insurance, Health maintenance organizations (HMO), Health records, Hospitals, Indians, Individuals with disabilities, Intergovernmental relations, Loan programs-health, Medicaid, Organization and functions (Government agencies), Prescription drugs, Public assistance programs, Reporting and recordkeeping requirements, Technical assistance, Women, Youth.
For the reasons set forth in the preamble, the Centers for Medicare & Medicaid Services proposes to amend 42 CFR chapter IV and the Department of Health and Human Services proposes to amend 45 CFR part 156 as set forth below:
42 U.S.C. 1302 and 1395hh.
The revisions and additions read as follows:
(b) * * *
(1) * * *
(iii) All data classes and data elements included in a content standard at 45 CFR 170.213, if the MA organization maintains any such data, no later than 1 business day after the MA organization receives the data; and
(iv) Beginning January 1, 2026, the information in paragraph (b)(1)(iv)(A) of this section about prior authorizations for items and services (excluding drugs, as defined at paragraph (b)(1)(v) of this section), according to the timelines in paragraph (b)(1)(iv)(B) of this section.
(A) The prior authorization request and decision and related administrative and clinical documentation, including all of the following, as applicable:
(
(
(
(
(
(B) The information in paragraph (b)(1)(iv)(A) of this section must be accessible no later than 1 business day after the MA organization receives a prior authorization request, and must be updated no later than 1 business day after any change in status. All information must continue to be accessible for the duration that the authorization is active and at least 1 year from the date of the prior authorization's last status change.
(v) Drugs are defined for the purposes of paragraph (b)(1)(iv) of this section as any and all drugs covered by the MA organization.
(c) * * *
(1) Must use API technology conformant with 45 CFR 170.215(a) through (3) and (b);
(4) * * *
(ii) * * *
(C) Using the updated version of the standard, implementation guide, or specification does not disrupt an end user's ability to access the data described in paragraph (b) of this section or §§ 422.120, 422.121, and 422.122 through the required APIs.
(e) * * *
(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which parties seek to access electronic health information, as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.
(f)
(1) The total number of unique enrollees whose data are transferred via the Patient Access API to a health app designated by the enrollee; and
(2) The total number of unique enrollees whose data are transferred more than once via the Patient Access API to a health app designated by the enrollee.
(h)
(1) With a date of service on or after January 1, 2016; and
(2) That are maintained by the MA organization.
(a)
(1)
(i)
(A) The MA organization authenticates the identity of the provider that requests access using the required authorization and authentication protocols at 45 CFR 170.215(b) and attributes the enrollee to the provider under the attribution process required in paragraph (a)(2) of this section.
(B) The enrollee does not opt out per paragraph (a)(3) of this section.
(C) Disclosure of the data is permitted by applicable law.
(ii)
(2)
(3)
(ii) Provide information to enrollees in non-technical, simple and easy-to-understand language, about the benefits of API data exchange with their providers, their opt out rights, and instructions both for opting out of data exchange and for opting in after previously opting out:
(A) Before the first date on which the MA organization makes enrollee information available through the Provider Access API; and
(B) At enrollment; and
(C) At least annually; and
(D) In an easily accessible location on its public website.
(4)
(b)
(1)
(i) Is compliant with § 422.119(c), (d), and (e), as well as the standard at 42 CFR 170.215(a)(4); and
(ii) Makes available the data specified at § 422.119(b) with a date of service on or after January 1, 2016, excluding provider remittances and enrollee cost-sharing, if maintained by the MA organization.
(2)
(i) The opt in process must be offered as follows:
(A) To current enrollees, no later than the compliance date.
(B) To new enrollees, no later than enrollment.
(ii) [Reserved]
(3)
(i) For current enrollees, no later than the compliance date.
(ii) For new enrollees, no later than enrollment.
(4)
(A) For new enrollees, no later than 1 week after the start of coverage.
(B) At an enrollee's request, within 1 week of the request.
(C) For an enrollee who opts in or provides previous and/or concurrent payer information after enrollment, within 1 week.
(ii) The MA organization must incorporate into the enrollee's record any data received from other payers in response to the request.
(iii) The MA organization must make data specified in paragraph (b)(1)(ii) of this section available to other payers via the standards-based API described in paragraph (b)(1) of this section within 1 business day of receiving a request if all the following conditions are met:
(A) The payer that requests access has its identity authenticated using the authorization and authentication protocols at 45 CFR 170.215(b) and includes an attestation with the request that the patient is enrolled with the payer and has opted in to the data exchange.
(B) Disclosure of the data is not prohibited by law.
(5)
(i) No later than 1 week after enrollment, and then at least quarterly, request the enrollee's data from all known concurrent payers in accordance with paragraphs (b)(4)(i) and (ii) of this section.
(ii) Within 1 business day of a request from any concurrent payers, respond in accordance with paragraph (b)(4)(iii) of this section.
(6)
(i) At or before requesting an enrollee's consent for Payer-to-Payer API data exchange, as described in paragraph (b)(2) of this section;
(ii) At least annually, in appropriate mechanisms through which it ordinarily communicates with current enrollees; and
(iii) In an easily accessible location on its public website.
(a)
(1) The MA organization's prior authorization response to the provider must indicate whether the MA organization approves the prior authorization request (and for how long), denies the prior authorization request, or requests more information related to the prior authorization request.
(2) If the MA organization denies the prior authorization request, the response to the provider must include a specific reason for the denial.
(b)
(1) Is populated with the MA organization's list of covered items and services (excluding drugs, as defined at § 422.119(b)(1)(v)) for which prior authorization is required, and any documentation requirements for the authorization;
(2) Include functionality to determine requirements for any other data, forms or medical record documentation required by the MA organization for the items or services for which the provider is seeking prior authorization;
(3) Facilitates a Health Insurance Portability and Accountability Act (HIPAA)-compliant prior authorization request and response; and
(4) Includes the information required at § 422.122(a).
(c)
(1) A list of all items and services that require prior authorization.
(2) The percentage of standard prior authorization requests that were approved, aggregated for all items and services.
(3) The percentage of standard prior authorization requests that were denied, aggregated for all items and services.
(4) The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.
(5) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.
(6) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.
(7) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services.
(8) The average and median time that elapsed between the submission of a request and a determination by the MA plan, for standard prior authorizations, aggregated for all items and services.
(9) The average and median time that elapsed between the submission of a request and a decision by the MA plan for expedited prior authorizations, aggregated for all items and services.
The revision and addition read as follows:
(b) * * *
(1)
(i) No later than 14 calendar days after receiving the request for the standard organization determination; or
(ii) On or after January 1, 2026, for a service or item subject to the prior authorization rules at § 422.122, no later than 7 calendar days after receiving the request for the standard organization determination.
(2)
(A) The enrollee requests the extension.
(B) The extension is justified and in the enrollee's interest due to the need for additional medical evidence from a noncontract provider that may change an MA organization's decision to deny an item or service.
(C) The extension is justified due to extraordinary, exigent, or other non-routine circumstances and is in the enrollee's interest.
(ii)
(d) * * *
(2) * * *
(i) * * *
(B) Except as described in paragraph (d)(2)(i)(A) of this section, the applicable integrated plan must send a notice of its integrated organization determination as expeditiously as the enrollee's health condition requires and either of the following:
(
(
(iv) * * *
(B) * * *
(
(
(
42 U.S.C. 1302.
The revisions and addition read as follows:
(b) * * *
(3) All data classes and data elements included in a content standard at 45 CFR 170.213, if the State maintains any such data, no later than 1 business day after the State receives the data; and
(5) Beginning January 1, 2026, the information in paragraph (b)(5)(i) of this section about prior authorizations for items and services (excluding drugs as defined at paragraph (b)(6) of this section), according to the timelines in paragraph (b)(5)(ii) of this section.
(i) The prior authorization request and decision and related administrative and clinical documentation, including all of the following, as applicable:
(A) The status of the prior authorization.
(B) The date the prior authorization was approved or denied.
(C) The date or circumstance under which the authorization ends.
(D) The items and services approved and the quantity used to date.
(E) If denied, a specific reason why the request was denied.
(ii) The information in paragraph (b)(5)(i) of this section must be accessible no later than 1 business day after the State receives a prior authorization request, and must be updated no later than 1 business day after any change in status. All information must continue to be accessible for the duration that the authorization is active and at least 1 year from the date of the prior authorization's last status change.
(6) Drugs are defined for purposes of paragraph (b)(5) of this section as any and all drugs covered by the State.
(c) * * *
(1) Must use API technology conformant with 45 CFR 170.215(a)(1) through (3) and (b);
(4) * * *
(ii) * * *
(C) Using the updated version of the standard, implementation guide, or specification does not disrupt an end user's ability to access the data described in paragraph (b) of this section or §§ 431.61, 431.70, and 431.80, through the required APIs.
(e) * * *
(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which parties seek to access electronic health information, as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.
(h)
(1) The total number of unique beneficiaries whose data are transferred via the Patient Access API to a health app designated by the beneficiary.
(2) The total number of unique beneficiaries whose data are transferred more than once via the Patient Access API to a health app designated by the beneficiary.
(a)
(1)
(i)
(A) The State authenticates the identity of the provider that requests access using the required authorization and authentication protocols at 45 CFR 170.215(b) and attributes the beneficiary to the provider under the attribution process required in paragraph (a)(2) of this section.
(B) The beneficiary does not opt out per paragraph (a)(3) of this section.
(C) Disclosure of the data is permitted by applicable law.
(ii)
(2)
(3)
(ii) Provide information to beneficiaries in non-technical, simple, and easy-to-understand language about the benefits of API data exchange with their providers, their opt out rights, and instructions both for opting out of data exchange and for opting in after previously opting out—
(A) Before the first date on which the State makes beneficiary information available through the Provider Access API;
(B) At enrollment;
(C) At least annually; and
(D) In an easily accessible location on its public website.
(4)
(b)
(1)
(i) Is compliant with § 431.60(c), (d), and (e), as well as the standard at 42 CFR 170.215(a)(4); and
(ii) Makes available the data specified at § 431.60(b) with a date of service on or after January 1, 2016, excluding provider remittances and beneficiary cost-sharing, if maintained by the State.
(2)
(i) The opt in process must be offered:
(A) To current beneficiaries, no later than the compliance date.
(B) To new beneficiaries, no later than enrollment.
(ii) If a beneficiary has coverage through any Medicaid managed care plans within the same State while enrolled in Medicaid, the State must share their opt in preference with those managed care plans to allow the Payer-to-Payer API data exchange described in this section.
(3)
(i) For current beneficiaries, no later than the compliance date.
(ii) For new beneficiaries, no later than enrollment.
(4)
(A) For new beneficiaries, no later than 1 week after enrollment.
(B) At a beneficiary's request, within 1 week of the request.
(C) For a beneficiary who opts in or provides previous and/or concurrent payer information after enrollment, within 1 week.
(ii) The State must incorporate into the beneficiary's record any data received from other payers in response to the request.
(iii) The State must make data specified in paragraph (b)(1)(ii) of this section available to other payers via the standards-based API described in paragraph (b)(1) of this section within 1 business day of receiving a request if all the following conditions are met:
(A) The payer that requests access has its identity authenticated using the authorization and authentication protocols at 45 CFR 170.215(b) and includes an attestation with the request that the patient is enrolled with the payer and has opted in to the data exchange.
(B) Disclosure of the data is not prohibited by law.
(5)
(i) No later than one week after enrollment, and then at least quarterly, request the beneficiary's data from all known concurrent payers in accordance with paragraph (b)(4)(i) and (ii) of this section; and
(ii) Within one business day of a request from any concurrent payers, respond in accordance with paragraph (b)(4)(iii) of this section.
(6)
(i) At or before requesting a beneficiary's consent for Payer-to-Payer API data exchange, as described in paragraph (b)(2) of this section;
(ii) At least annually, in appropriate mechanisms through which it ordinarily communicates with current beneficiaries; and
(iii) In an easily accessible location on its public website.
(c)
(A) A narrative justification describing the specific reasons why the State cannot reasonably satisfy the requirement(s) by the compliance date and why those reasons result from circumstances that are unique to the agency operating the Medicaid fee-for service program;
(B) A report on completed and ongoing State implementation activities that evidence a good faith effort towards compliance; and
(C) A comprehensive plan to meet implementation requirements no later than 1 year after the compliance date.
(ii) CMS will grant the State's request if it determines based on the information provided in the State's annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures that the request adequately establishes a need to delay implementation; and that the State has a comprehensive plan to implement the requirements no later than 1 year after the compliance date.
(2)
(A) The exemption request must be submitted in writing as part of a State's annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures prior to the date by which the state would otherwise need to comply with the applicable requirement.
(B) The State's request must include documentation that the State meets the criteria for the exemption, based on enrollment data from the most recent CMS “Medicaid Managed Care Enrollment and Program Characteristics” report, and must also include information about an alternative
(ii) CMS will grant the exemption if the State establishes to CMS's satisfaction that the State meets the criteria for the exemption and has established an alternative plan to ensure that enrolled providers have efficient electronic access to the same information through other means while the exemption is in effect.
(iii) The State's exemption would expire if:
(A) Based on the 3 previous years of available, finalized Medicaid Transformed Medicaid Statistical Information System (T-MSIS) managed care and fee-for-service (FFS) enrollment data, the State's managed care enrollment for 2 of the previous 3 years is below 90 percent; or
(B) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by the first available, finalized Medicaid T-MSIS managed care and FFS enrollment data.
(iv) If a State's exemption expires per paragraph (c)(2)(iii) of this section, the State would be required to—
(A) Submit written notification to CMS that the State no longer qualifies for the exemption within 90 days of the finalization of annual Medicaid T-MSIS managed care enrollment data or approval of a State plan amendment, waiver, or waiver amendment confirming that there has been the requisite shift from managed care enrollment to FFS enrollment resulting in the State's managed care enrollment falling below the 90 percent threshold; and
(B) Obtain CMS approval of a timeline for compliance with the requirements at paragraphs (a) and/or (b) of this section within two years of the expiration of the exemption.
(a)
(1) The State's prior authorization response to the provider must indicate whether the State approves the prior authorization request (and for how long), denies the prior authorization request, or requests more information related to the prior authorization request.
(2) If the State denies the prior authorization request, the response to the provider must include a specific reason for the denial.
(b)
(1) Is populated with the State's list of covered items and services (excluding drugs, as defined at § 431.60(b)(6)) for which prior authorization is required, and any documentation requirements for the authorization;
(2) Includes functionality to determine requirements for any other data, forms or medical record documentation required by the State for the items or services for which the provider is seeking prior authorization;
(3) Facilitates a Health Insurance Portability and Accountability Act (HIPAA)-compliant prior authorization request and response; and
(4) Includes the information required at paragraph (a) of this section.
(c)
(A) A narrative justification describing the specific reasons why the State cannot reasonably satisfy the requirement(s) by the compliance date and explaining why those reasons result from circumstances that are unique to the agency operating the Medicaid fee-for service program;
(B) A report on completed and ongoing State implementation activities that evidence a good faith effort towards compliance; and
(C) A comprehensive plan to meet implementation requirements no later than 1 year after the compliance date.
(ii) CMS will grant the State's request if it determines based on the information provided in the State's annual Advance Planning Document for MMIS operations expenditures that the request adequately establishes a need to delay implementation; and that the State has a comprehensive plan to implement the requirements no later than 1 year after the compliance date.
(2)
(A) The exemption request must be submitted in writing as part of a State's annual Advance Planning Document for Medicaid Management Information System (MMIS) operations expenditures prior to the date by which the state would otherwise need to comply with the applicable requirement.
(B) The State's request must include documentation that demonstrates that the State meets the criteria for the exemption, based on enrollment data from the most recent CMS “Medicaid Managed Care Enrollment and Program Characteristics” report, and must also include information about an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect.
(ii) CMS will grant the exemption if the State establishes to CMS's satisfaction that the State meets the criteria for the exemption and has established an alternative plan to ensure there will be efficient electronic access the same information through alternative means while the exemption is in effect.
(iii) The State's exemption would expire if:
(A) Based on the 3 previous years of available, finalized Medicaid T-MSIS managed care and FFS enrollment data, the State's managed care enrollment for 2 of the previous 3 years is below 90 percent; or
(B) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care, and the anticipated shift in enrollment is confirmed by the first available, finalized Medicaid T-MSIS managed care and FFS enrollment data.
(iv) If a State's exemption expires per paragraph (c)(2)(iii) of this section, the State would be required to:
(A) Submit written notification to CMS that the State no longer qualifies for the exemption within 90 days of the finalization of annual Medicaid T-MSIS managed care enrollment data confirming that there has been a shift from managed care enrollment to FFS enrollment resulting in the State's managed care enrollment falling below the 90 percent threshold; and
(B) Obtain CMS approval of a timeline for compliance with the requirements at paragraph (b) of this section within two years of the expiration of the exemption.
(1) A termination, suspension of, or reduction in covered benefits or services, including benefits or services for which there is a current approved prior authorization;
(2) A termination, suspension of, or reduction in Medicaid eligibility, or an increase in enrollee liability, including a determination that an enrollee must incur a greater amount of medical expenses to establish income eligibility in accordance with § 435.121(e)(4) or § 435.831 of this chapter;
(3) A determination that an enrollee is subject to an increase in premiums or cost-sharing charges under subpart A of part 447 of this chapter; or
(4) A determination by a skilled nursing facility or nursing facility to transfer or discharge a resident and an adverse determination by a State with regard to the preadmission screening and resident review requirements of section 1919(e)(7) of the Act.
The addition reads as follows:
(a) * * *
(1) * * *
(vi) A prior authorization decision.
42 U.S.C. 1302.
The revisions read as follows:
(a)
(b)
(2)
42 U.S.C. 1302.
(b) * * *
(7) The PAHP standards in §§ 438.206(b)(1), 438.210, 438.214, 438.224, 438.230, and 438.242, excluding the requirement in § 438.242(b)(7), to comply with § 431.61(a) of this chapter.
The addition and revision read as follows:
(d) * * *
(1)
(A) For rating periods that start before January 1, 2026, within State-established timeframes that may not exceed 14 calendar days after receiving the request.
(B) For rating periods that start on or after January 1, 2026, within State-established timeframes that may not exceed 7 calendar days after receiving the request.
(ii) Standard authorization decisions may have an extension to the timeframes in paragraph (d)(1)(i) of this section may have a possible extension of up to 14 additional calendar days if:
(A) The enrollee, or the provider, requests the extension; or
(B) The MCO, PIHP, or PAHP justifies (to the State agency upon request) a need for additional information and how the extension is in the enrollee's interest.
(2) * * *
(i) For cases in which a provider indicates, or the MCO, PIHP, or PAHP determines, that following the standard timeframe could seriously jeopardize the enrollee's life or health or ability to attain, maintain, or regain maximum function, the MCO, PIHP, or PAHP must make an expedited authorization decision and provide notice as expeditiously as the enrollee's health condition requires and within State-established timeframes that are no later than 72 hours after receipt of the request for service unless a shorter minimum time frame is established under State law.
(f)
(1) A list of all items and services that require prior authorization.
(2) The percentage of standard prior authorization requests that were approved, aggregated for all items and services.
(3) The percentage of standard prior authorization requests that were denied, aggregated for all items and services.
(4) The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.
(5) The percentage of prior authorization requests for which the timeframe for review was extended, and
(6) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.
(7) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services.
(8) The average and median time that elapsed between the submission of a request and a determination by the MCO, PIHP or PAHP, for standard prior authorizations, aggregated for all items and services.
(9) The average and median time that elapsed between the submission of a request and a decision by the MCO, PIHP or PAHP, for expedited prior authorizations, aggregated for all items and services.
(b) * * *
(5) Subject to paragraph (b)(8) of this section, implement and maintain a Patient Access Application Programming Interface (API) as specified in § 431.60 of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP and:
(i) Include all encounter data, including encounter data from any network providers the MCO, PIHP, or PAHP is compensating based on capitation payments and adjudicated claims and encounter data from any subcontractors.
(ii) Exclude covered outpatient drugs as defined in section 1927(k)(2) of the Act and § 438.3(s).
(iii) Report metrics specified at § 431.60(h) of this chapter at the plan level.
(7) By the rating period beginning on or after January 1, 2026, comply with §§ 431.61(a), (b)(1), (4), and (5), and (b)(6)(ii) and (iii) and 431.80 of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP.
(8) The following timeframes apply to paragraph (b)(5) of this section:
(i) Except for the requirements at § 431.60(b)(5), (g), and (h) of this chapter, comply with the requirements of § 431.60 of this chapter by January 1, 2021.
(ii) Comply with the requirements at § 431.60(b)(5) and (g) of this chapter by the rating period beginning on or after January 1, 2026.
(iii) Beginning in 2026, by March 31 following any year the MCO, PIHP, or PAHP operates, comply with the reporting requirements at § 431.60(h) of this chapter for the previous calendar year's data, in the form of aggregated, de-identified metrics, at the plan level.
42 U.S.C. 1302.
(e) The State Medicaid agency must—
(1) Beginning January 1, 2026, provide notice of prior authorization decisions for items and services (excluding drugs, as defined at § 431.60(b)(6) of this chapter) as follows:
(i) For standard determinations, as expeditiously as a beneficiary's health condition requires, but in no case later than 7 calendar days after receiving the request, unless a shorter minimum time frame is established under State law. The timeframe for standard authorization decisions can be extended by up to 14 calendar days if the beneficiary or provider requests an extension, or if the State agency determines that additional information from the provider is needed to make a decision.
(ii) For an expedited determination, as expeditiously as a beneficiary's health condition requires, but in no case later than 72 hours after receiving the request, unless a shorter minimum time frame is established under State law.
(2) Provide the beneficiary with notice of the agency's prior authorization decision in accordance with § 435.917 of this chapter and provide fair hearing rights, including advance notice, in accordance with part 431, subpart E, of this chapter.
(f) Beginning in 2026, a State must annually report prior authorization data, excluding data on drugs, as defined at § 431.60(b)(6) of this chapter, at the State level by March 31. The State must make the following data from the previous calendar year publicly accessible by posting it directly on its website or via hyperlink(s):
(1) A list of all items and services that require prior authorization.
(2) The percentage of standard prior authorization requests that were approved, aggregated for all items and services.
(3) The percentage of standard prior authorization requests that were denied, aggregated for all items and services.
(4) The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.
(5) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.
(6) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.
(7) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services.
(8) The average and median time that elapsed between the submission of a request and a determination by the State Medicaid agency, for standard prior authorizations, aggregated for all items and services.
(9) The average and median time that elapsed between the submission of a request and a decision by the State Medicaid agency for expedited prior authorizations, aggregated for all items and services.
42 U.S.C. 1302.
(d) * * *
(1) In accordance with the medical needs of the patient, but no later than 7 calendar days after receiving the request for a standard determination and by no later than 72 hours after receiving the request for an expedited determination. A possible extension of up to 14 days may be permitted if the enrollee requests the extension or if the physician or health plan determines the additional information is needed; and
(c)
The revisions and additions read as follows:
(b) * * *
(3) All data classes and data elements included in a content standard at 45 CFR 170.213, if the State maintains any such data, no later than 1 business day after the State receives the data; and
(5) Beginning January 1, 2026, the information in paragraph (b)(5)(i) of this section about prior authorizations for items and services (excluding drugs as defined at paragraph (b)(6) of this section), according to the timelines in paragraph (b)(5)(ii) of this section.
(i) The prior authorization request and decision and related administrative and clinical documentation, including all of the following, as applicable:
(A) The status of the prior authorization.
(B) The date the prior authorization was approved or denied.
(C) The date or circumstance under which the authorization ends.
(D) The items and services approved and the quantity used to date.
(E) If denied, a specific reason why the request was denied.
(ii) The information in paragraph (b)(5)(i) of this section must be accessible no later than 1 business day after the State receives a prior authorization request, and must be updated no later than 1 business day after any change in status. All information must continue to be accessible for the duration that the authorization is active and at least 1 year from the date of the prior authorization's last status change.
(6) Drugs are defined for the purposes of paragraph (b)(5) of this section as any and all drugs covered by the State.
(c) * * *
(1) Must use API technology conformant with 45 CFR 170.215(a)(1) through (3) and (b);
(3) Must comply with the content and vocabulary standard requirements in paragraphs (c)(3)(i) and (ii) of this section, as applicable to the data type or data element, unless alternate standards are required by other applicable law, and be conformant with the requirements in paragraphs (c)(3)(iii) of this section:
(iii) Beginning January 1, 2026, for data specified in paragraphs (b)(1) through (5) of this section.
(4) May use an updated version of any standard or all standards required under paragraph (b) or (c) of this section and §§ 457.731, 457.732, and 457.760, where:
(ii) * * *
(C) Using the updated version of the standard, implementation guide, or specification does not disrupt an end user's ability to access the data described in paragraph (b) of this section or §§ 457.731, 457.732, and 457.760 through the required APIs.
(e) * * *
(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which parties seek to access electronic health information, as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.
(h)
(1) The total number of unique beneficiaries whose data are transferred via the Patient Access API to a health app designated by the beneficiary; and
(2) The total number of unique beneficiaries whose data are transferred more than once via the Patient Access API to a health app designated by the beneficiary.
(a)
(1)
(i)
(A) The State authenticates the identity of the provider that requests access using the required authorization and authentication protocols at 45 CFR 170.215(b) and attributes the beneficiary to the provider under the attribution process required in paragraph (a)(2) of this section.
(B) The beneficiary does not opt out per paragraph (a)(3) of this section.
(C) Disclosure of the data is permitted by applicable law.
(ii)
(2)
(3)
(ii) Provide information to beneficiaries in non-technical, simple and easy-to-understand language about the benefits of API data exchange with their providers, their opt out rights, and instructions both for opting out of data exchange and for opting in after previously opting out:
(A) Before the first date on which the State makes beneficiary information available through the Provider Access API; and
(B) At enrollment; and
(C) At least annually; and
(D) In an easily accessible location on its public website.
(4)
(b)
(1)
(i) Is compliant with § 457.730(c), (d), and (e), as well as the standard at 42 CFR 170.215(a)(4); and
(ii) Makes available the data specified at § 457.730(b) with a date of service on or after January 1, 2016, excluding provider remittances and beneficiary cost-sharing, if maintained by the State.
(2)
(i) The opt in process must be offered:
(A) To current beneficiaries, no later than the compliance date.
(B) To new beneficiaries, no later than enrollment.
(ii) If a beneficiary has coverage through any CHIP managed care entities within the same State while enrolled in CHIP, the State must share their opt in preference with those managed care entities to allow the Payer-to-Payer API data exchange described in this section.
(3)
(i) For current beneficiaries, no later than the compliance date.
(ii) For new beneficiaries, no later than enrollment.
(4)
(A) For new beneficiaries, no later than 1 week after enrollment.
(B) At a beneficiary's request, within 1 week of the request.
(C) For a beneficiary who opts in or provides previous and/or concurrent payer information after enrollment, within 1 week.
(ii) The State must incorporate into the beneficiary's record any data received from other payers in response to the request.
(iii) The State must make data specified in paragraph (b)(1)(ii) of this section available to other payers via the standards-based API described in paragraph (b)(1) of this section within 1 business day of receiving a request if all the following conditions are met:
(A) The payer that requests access has its identity authenticated using the authorization and authentication protocols at 45 CFR 170.215(b) and includes an attestation with the request that the patient is enrolled with the payer and has opted in to the data exchange.
(B) Disclosure of the data is not prohibited by law.
(5)
(i) No later than one week after enrollment, and then at least quarterly, request the beneficiary's data from all known concurrent payers in accordance with paragraphs (b)(4)(i) and (ii) of this section; and
(ii) Within one business day of a request from any concurrent payers, respond in accordance with paragraph (b)(4)(iii) of this section.
(6)
(i) At or before requesting a patient's consent for Payer-to-Payer API data exchange, as described in paragraph (b)(2) of this section;
(ii) At least annually, in appropriate mechanisms through which it ordinarily communicates with current beneficiaries; and
(iii) In an easily accessible location on its public website.
(c)
(A) A narrative justification describing the specific reasons why the State cannot reasonably satisfy the requirement(s) by the compliance date and explaining why those reasons result from circumstances that are unique to the agency operating the CHIP fee-for service program;
(B) A report on completed and ongoing State implementation activities that evidence a good faith effort towards compliance; and
(C) A comprehensive plan to meet implementation requirements no later than 1 year after the compliance date.
(ii) CMS will grant the State's request if it determines based on the information provided in the State's annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures that the request adequately establishes a need to delay implementation; and that the State has a comprehensive plan to implement the requirements no later than 1 year after the compliance date.
(2)
(A) The exemption request must be submitted in writing as part of the State's annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures prior to the date by which the state would otherwise need to comply with the applicable requirement.
(B) The State's request must include documentation that the State meets the criteria for the exemption, based on enrollment data from Section 5 of the most recently accepted CHIP Annual Report Template System (CARTS), and must also include information about an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect.
(ii) CMS will grant the exemption if the State establishes to CMS's satisfaction that the State meets the criteria for the exemption and has established an alternative plan to ensure that enrolled providers have efficient electronic access to the same information through other means while the exemption is in effect.
(iii) The State's exemption would expire if:
(A) Based on the 3 previous years of available, finalized CHIP CARTS managed care and FFS enrollment data, the State's managed care enrollment for 2 of the previous 3 years is below 90 percent; or
(B) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by the first available, finalized CARTS managed care and FFS enrollment data.
(iv) If a State's exemption expires per paragraph (c)(2)(iii) of this section, the State would be required to:
(A) Submit written notification to CMS that the State no longer qualifies for the exemption within 90 days of the finalization of annual CHIP CARTS managed care enrollment data or approval of a State plan amendment, waiver, or waiver amendment confirming that there has been a shift from managed care enrollment to FFS enrollment resulting in the State's managed care enrollment falling below the 90 percent threshold; and
(B) Obtain CMS approval of a timeline for compliance with the requirements at paragraph (b) of this section within 2 years of the expiration of the exemption.
(a)
(1) The State's prior authorization response to the provider must indicate whether the State approves the prior authorization request (and for how long), denies the prior authorization request, or requests more information related to the prior authorization request.
(2) If the State denies the prior authorization request, the response to the provider must include a specific reason for the denial.
(b)
(1) Is populated with the State's list of covered items and services (excluding drugs as defined at § 457.730(b)(6)) for which prior authorization is required, and any documentation requirements for the prior authorization;
(2) Includes functionality to determine requirements for any other data, forms or medical record documentation required by the State for the items or services for which the provider is seeking prior authorization;
(3) Facilitates a HIPAA-compliant prior authorization request and response; and
(4) Includes the information required at paragraph (a) of this section.
(c)
(1) A list of all items and services that require prior authorization.
(2) The percentage of standard prior authorization requests that were approved, aggregated for all items and services.
(3) The percentage of standard prior authorization requests that were denied, aggregated for all items and services.
(4) The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.
(5) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.
(6) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.
(7) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services.
(8) The average and median time that elapsed between the submission of a request and a determination by the State, for standard prior authorizations, aggregated for all items and services.
(9) The average and median time that elapsed between the submission of a request and a decision by the State for expedited prior authorizations, aggregated for all items and services.
(d)
(A) A narrative justification describing the specific reasons why the State cannot reasonably satisfy the requirement(s) by the compliance date and why those reasons result from circumstances that are unique to the agency operating the CHIP fee-for service program;
(B) A report on completed and ongoing State implementation activities that evidence a good faith effort toward compliance; and
(C) A comprehensive plan to meet implementation requirements no later than 1 year after the compliance date.
(ii) CMS will grant the State's request if it determines based on the information provided in the State's annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations expenditures that the request adequately establishes a need to delay implementation; and that the State has a comprehensive plan to implement the requirements no later than 1 year after the compliance date.
(2)
(A) The exemption request must be submitted in writing as part of a State's
(B) The State's request must include documentation that the State meets the criteria for the exemption, based on enrollment data from Section 5 of the most recently accepted CHIP Annual Report Template System (CARTS), and must also include information about an alternative plan to ensure that enrolled providers will have efficient electronic access to the same information through other means while the exemption is in effect.
(ii) CMS will grant the exemption if the State establishes to CMS's satisfaction that the State meets the criteria for the exemption and has established a plan to ensure its enrolled providers have efficient electronic access to the same information through other means while the exemption is in effect.
(iii) The State's exemption would expire if:
(A) Based on the 3 previous years of available, finalized CHIP CARTS managed care and FFS enrollment data, the State's managed care enrollment for 2 of the previous 3 years is below 90 percent; or
(B) CMS has approved a State plan amendment, waiver, or waiver amendment that would significantly reduce the share of beneficiaries enrolled in managed care and the anticipated shift in enrollment is confirmed by the first available, finalized Medicaid Transformed Medicaid Statistical Information System (T-MSIS) managed care and FFS enrollment data.
(iv) If a State's exemption expires per paragraph (d)(2)(iii) of this section, the State would be required to:
(A) Submit written notification to CMS that the State no longer qualifies for the exemption within 90 days of the finalization of annual CHIP CARTS managed care enrollment data confirming that there has been a shift from managed care enrollment to FFS enrollment resulting in the State's managed care enrollment falling below the 90 percent threshold; and
(B) Obtain CMS approval of a timeline for compliance with the requirements at paragraph (b) of this section within two years of the expiration of the exemption.
(b) * * *
(6) The PAHP standards in § 438.206(b)(1) of this chapter, as cross-referenced by §§ 457.1230(a) and (d) and 457.1233(a), (b), and (d), excluding the requirement at § 438.242(b)(7) of this chapter to comply with § 431.61(a) of this chapter.
(d)
42 U.S.C. 18021-18024, 18031-18032, 18041-18042, 18044, 18054, 18061, 18063, 18071, 18082, and 26 U.S.C. 36B.
The revisions and addition read as follows:
(b) * * *
(1) * * *
(iii) All data classes and data elements included in a content standard at 45 CFR 170.213, if the Qualified Health Plan (QHP) issuer maintains any such data, no later than 1 business day after the QHP issuer receives the data; and
(iv) For plan years beginning on or after January 1, 2026, the information in paragraph (b)(1)(iv)(A) of this section about prior authorizations for items and services (excluding drugs, as defined at paragraph (b)(1)(v) of this section), according to the timelines in paragraph (b)(1)(iv)(B) of this section.
(A) The prior authorization request and decision and related administrative and clinical documentation, including all of the following, as applicable:
(
(
(
(
(
(B) The information in paragraph (b)(1)(iv)(A) of this section must be accessible no later than 1 business day after the QHP issuer receives a prior authorization request, and must be updated no later than 1 business day after any change in status. All information must continue to be accessible for the duration that the authorization is active and at least one year from the date of the prior authorization's last status change.
(v) Drugs are defined for the purposes of paragraph (b)(1)(iv) of this section as any and all drugs covered by the QHP issuer.
(c) * * *
(1) Must use API technology conformant with 45 CFR 170.215(a)(1) through (3) and (b);
(4) * * *
(ii) * * *
(C) Using the updated version of the standard, implementation guide, or specification does not disrupt an end user's ability to access the data described in paragraph (b) of this section or § 156.222 or § 156.223 through the required APIs.
(e) * * *
(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which parties seek to access electronic health information, as defined at § 171.102 of this subchapter, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.
(f)
(1) The total number of unique enrollees whose data are transferred via the Patient Access API to a health app designated by the enrollee; and
(2) The total number of unique enrollees whose data are transferred more than once via the Patient Access API to a health app designated by the enrollee.
(a)
(1)
(i)
(A) The QHP issuer authenticates the identity of the provider that requests access using the required authorization and authentication protocols at 45 CFR 170.215(b) and attributes the enrollee to the provider under the attribution process required in paragraph (a)(2) of this section.
(B) The enrollee does not opt out per paragraph (a)(3) of this section.
(C) Disclosure of the data is permitted by applicable law.
(ii)
(2)
(3)
(ii) Provide information to enrollees in non-technical, simple and easy-to-understand language, about the benefits of API data exchange with their providers, their opt out rights, and instructions for both for opting out of data exchange and for opting in after previously opting out:
(A) Before the first date on which the QHP issuer makes enrollee information available through the Provider Access API; and
(B) At enrollment; and
(C) At least annually; and
(D) In an easily accessible location on its public website.
(4)
(b)
(1)
(i) Is compliant with § 156.221(c), (d), and (e), as well as the standard at 42 CFR 170.215(a)(4); and
(ii) Makes available the data specified at § 156.221(b) with a date of service on or after January 1, 2016, excluding provider remittances and enrollee cost-sharing, if maintained by the QHP issuer.
(2)
(i) The opt in process must be offered:
(A) To current enrollees, no later than the compliance date.
(B) To new enrollees, no later than the effectuation of enrollment.
(ii) [Reserved]
(3)
(i) For current enrollees, no later than the compliance date.
(ii) For new enrollees, no later than the effectuation of enrollment.
(4)
(A) For current enrollees, no later than 1 week after the effectuation of enrollment.
(B) At an enrollee's request, within 1 week of the request.
(C) For an enrollee who opts in or provides previous and/or concurrent payer information after the effectuation of enrollment, within 1 week.
(ii) The QHP issuer must incorporate into the enrollee's record any data received from other payers in response to the request.
(iii) The QHP issuer on a Federally-facilitated Exchange must make data specified in paragraph (b)(1)(ii) of this section available to other payers via the standards-based API described in paragraph (b)(1) of this section within 1 business day of receiving a request if all the following conditions are met:
(A) The payer that requests access has its identity authenticated using the authorization and authentication protocols at 45 CFR 170.215(b) and includes an attestation with the request that the patient is enrolled with the payer and has opted in to the data exchange.
(B) Disclosure of the data is not prohibited by law.
(5)
(i) No later than one week after the effectuation of enrollment, and then at least quarterly, request the enrollee's data from all known concurrent payers in accordance with paragraphs (b)(4)(i) and (ii) of this section; and
(ii) Within one business day of a request from any concurrent payers, respond in accordance with paragraph (b)(4)(iii) of this section.
(6)
(i) At or before requesting a patient's consent for Payer-to-Payer API data exchange, as described in paragraph (b)(2) of this section;
(ii) At least annually, in appropriate mechanisms through which it ordinarily communicates with current enrollees; and
(iii) In an easily accessible location on its public website.
(c)
(2) The Federally-facilitated Exchange may grant an exception to the requirements in paragraphs (a) and/or (b) of this section if the Exchange determines that making qualified health plans of such issuer available through such Exchange is in the interests of qualified individuals in the State or States in which such Exchange operates, and an exception is warranted to permit the issuer to offer qualified health plans through the FFE.
(a)
(1) The QHP issuer's prior authorization response to the provider must indicate whether the QHP issuer approves the prior authorization request (and for how long), denies the prior authorization request, or requests more information related to the prior authorization request.
(2) If the QHP issuer denies the prior authorization request, the response to the provider must include a specific reason for the denial.
(b)
(1) Is populated with the QHP issuer's list of covered items and services (excluding drugs as defined at § 156.221(b)(1)(v)) for which prior authorization is required, and any documentation requirements for the prior authorization;
(2) Includes functionality to determine requirements for any other data, forms or medical record documentation required by the QHP issuer for the items or services for which the provider is seeking prior authorization;
(3) Facilitates a Health Insurance Portability and Accountability Act (HIPAA)-compliant prior authorization request and response; and
(4) Includes the information required at paragraph (a) of this section.
(c)
(1) A list of all items and services that require prior authorization.
(2) The percentage of standard prior authorization requests that were approved, aggregated for all items and services.
(3) The percentage of standard prior authorization requests that were denied, aggregated for all items and services.
(4) The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.
(5) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.
(6) The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.
(7) The percentage of expedited prior authorization requests that were denied, aggregated for all items and services.
(8) The average and median time that elapsed between the submission of a request and a determination by the QHP issuer, for standard prior authorizations, aggregated for all items and services.
(9) The average and median time that elapsed between the submission of a request and a decision by the QHP issuer for expedited prior authorizations, aggregated for all items and services.
(d)
(2) The Federally-facilitated Exchange may grant an exception to the requirements in paragraph (b) of this section if the Exchange determines that making qualified health plans of such issuer available through such Exchange is in the interests of qualified individuals in the State or States in which such Exchange operates and an exception is warranted to permit the issuer to offer qualified health plans through the FFE.
Commodity Futures Trading Commission.
Proposed order and request for comment.
The Commodity Futures Trading Commission (“Commission” or “CFTC”) is soliciting public comment on a joint request submitted by Morgan Stanley Mexico, Casa de Bolsa, S.A. de C.V., Goldman Sachs Mexico, Casa de Bolsa, S.A. de C.V., and Casa de Bolsa Finamex, S.A. de C.V. requesting that the Commission determine that the capital and financial reporting laws and regulations of Mexico applicable to CFTC-registered swap dealers organized and domiciled in Mexico, and licensed with the Mexican Banking and Securities Commission (Comision Nacional Bancaria y de Valores) as broker-dealers (casa de bolsa), provide a sufficient basis for an affirmative finding of comparability with respect to the Commission's swap dealer capital and financial reporting requirements adopted under the Commodity Exchange Act. The Commission also is soliciting public comment on a proposed order providing for the conditional availability of substituted compliance in connection with the application.
Comments must be received on or before February 13, 2023.
You may submit comments, identified by “Mexico Swap Dealer Capital Comparability Determination”, by any of the following methods:
•
•
•
Please submit your comments using only one of these methods. To avoid possible delays with mail or in-person deliveries, submissions through the CFTC Comments Portal are encouraged.
All comments must be submitted in English, or if not, accompanied by an English translation. Comments will be posted as received to
The Commission reserves the right, but shall have no obligation, to review, pre-screen, filter, redact, refuse or remove any or all of your submission from
Amanda L. Olear, Director, 202-418-5283,
The Commission is soliciting public comment on an application dated September 28, 2021 (the “Mexico Application”) and submitted jointly by Morgan Stanley Mexico, Casa de Bolsa, S.A. de C.V., Goldman Sachs Mexico, Casa de Bolsa, S.A. de C.V., and Casa de Bolsa Finamex, S.A. de C.V. (the “Applicants”).
Section 4s(e) of the CEA
Section 4s(e) applies a bifurcated approach with respect to the above Congressional directives, requiring each SD and MSP that is subject to the regulation of a prudential regulator (“bank SD” and “bank MSP,”
The prudential regulators implemented Section 4s(e) in 2015 by amending existing capital requirements applicable to bank SDs and bank MSPs to incorporate swap transactions into their respective bank capital frameworks, and by adopting rules imposing initial and variation margin requirements on bank SDs and bank MSPs that engage in uncleared swap transactions.
Section 4s(f) of the CEA addresses SD and MSP financial reporting requirements.
Regulation 23.106 establishes a substituted compliance framework whereby the Commission may determine that compliance by a non-U.S. domiciled nonbank SD or non-U.S. domiciled nonbank MSP with its home country's capital and financial reporting requirements will satisfy all or parts of the CFTC Capital Rules and all or parts of the CFTC Financial Reporting Rules (such a determination referred to as a “Capital Comparability Determination”).
The Commission's approach for conducting a comparability determination with respect to the CFTC Capital Rules and the CFTC Financial Reporting Rules is a principles-based, holistic approach that focuses on whether the applicable foreign jurisdiction's capital and financial reporting requirements achieve comparable outcomes to the corresponding CFTC requirements.
A person requesting a Capital Comparability Determination is required to submit an application to the Commission containing: (i) a description of the objectives of the relevant foreign jurisdiction's capital adequacy and financial reporting requirements applicable to entities that are subject to the CFTC Capital Rules and the CFTC Financial Reporting Rules; (ii) a description (including specific legal and regulatory provisions) of how the relevant foreign jurisdiction's capital adequacy and financial reporting requirements address the elements of the CFTC Capital Rules and CFTC Financial Reporting Rules, including, at a minimum, the methodologies for establishing and calculating capital adequacy requirements and whether such methodologies comport with any international standards; and (iii) a description of the ability of the relevant foreign regulatory authority to supervise and enforce compliance with the relevant foreign jurisdiction's capital adequacy and financial reporting requirements. The applicant must also submit, upon request, such other information and documentation as the Commission deems necessary to evaluate the comparability of the capital adequacy and financial reporting requirements of the foreign jurisdiction.
The Commission may consider all relevant factors in making a Capital Comparability Determination, including: (i) the scope and objectives of the relevant foreign jurisdiction's capital and financial reporting requirements; (ii) whether the relevant foreign
In performing the comparability assessment for foreign nonbank SDs, the Commission's review will include the extent to which the foreign jurisdiction's requirements address: (i) the process of establishing minimum capital requirements for nonbank SDs and how such process addresses risk, including market risk and credit risk of the nonbank SD's on-balance sheet and off-balance sheet exposures; (ii) the types of equity and debt instruments that qualify as regulatory capital in meeting minimum requirements; (iii) the financial reports and other financial information submitted by a nonbank SD to its relevant regulatory authority and whether such information provides the regulatory authority with the means necessary to effectively monitor the financial condition of the nonbank SD; and (iv) the regulatory notices and other communications between a nonbank SD and its foreign regulatory authority that address potential adverse financial or operational issues that may impact the firm. With respect to the ability of the relevant foreign regulatory authority to supervise and enforce compliance with the foreign jurisdiction's capital adequacy and financial reporting requirements, the Commission's review will include a review of the foreign jurisdiction's surveillance program for monitoring nonbank SDs' compliance with such capital adequacy and financial reporting requirements, and the disciplinary process imposed on firms that fail to comply with such requirements.
In performing the comparability assessment for a foreign nonbank MSP,
Regulation 23.106 further provides that the Commission may impose any terms or conditions that it deems appropriate in issuing a Capital Comparability Determination.
The Commission's capital adequacy and financial reporting requirements are designed to address and manage risks that arise from a firm's operation as a SD or MSP. Given their functions, both sets of requirements and rules must be applied on an entity-level basis (meaning that the rules apply on a firm-wide basis, irrespective of the type of transactions involved) to effectively address risk to the firm as a whole. Therefore, in order to rely on a Capital Comparability Determination, a nonbank SD or nonbank MSP domiciled in the foreign jurisdiction and subject to supervision by the relevant regulatory authority (or authorities) in the foreign jurisdiction must file a notice with the Commission of its intent to comply with the applicable capital adequacy and financial reporting requirements of the foreign jurisdiction set forth in the Capital Comparability Determination in lieu of all or parts of the CFTC Capital Rules and/or CFTC Financial Reporting Rules.
Each non-U.S. nonbank SD and/or non-U.S. nonbank MSP that receives, in accordance with the applicable Commission Capital Comparability Determination Order, confirmation from the Commission that it may comply with a foreign jurisdiction's capital adequacy and/or financial reporting requirements will be deemed by the Commission to be in compliance with the corresponding CFTC Capital Rules and/or CFTC Financial Reporting Rules.
The Commission will consider an application for a Capital Comparability Determination to be a representation by the applicant that the laws and regulations of the foreign jurisdiction that are submitted in support of the application are finalized and in force, that the description of such laws and regulations is accurate and complete, and that, unless otherwise noted, the scope of such laws and regulations encompasses the relevant non-U.S. nonbank SDs and/or non-U.S. nonbank MSPs domiciled in the foreign jurisdiction.
The Applicants submitted the Mexico Application to request that the Commission issue a Capital Comparability Determination finding that compliance with the capital requirements of Mexico and the financial reporting requirements of Mexico, as specified in the Mexico Application, by a Mexican nonbank SD satisfies corresponding CFTC Capital Rules and the CFTC Financial Reporting Rules applicable to a nonbank SD under sections 4s(e) through (f) of the CEA and Regulations 23.101 and 23.105.
The Applicants have represented that the Securities Market Law (Ley del Mercado de Valores, the “Law”)
The CFTC Capital Rules provide nonbank SDs with three alternative capital approaches: (i) the Tangible Net Worth Capital Approach (“TNW Approach”); (ii) the Net Liquid Assets Capital Approach (“NLA Approach”); and (iii) the Bank-Based Capital Approach (“Bank-Based Approach”).
Nonbank SDs that are “predominantly engaged in non-financial activities” may elect the TNW Approach.
The TNW approach requires a nonbank SD to compute its market risk exposure requirement and credit risk exposure requirement using standardized capital charges set forth in Securities and Exchange Commission (“SEC”) Rule 18a-1
A nonbank SD that elects the NLA Approach is required to maintain “net capital” in an amount that equals or exceeds the greater of: (i) $20 million; (ii) 2 percent of the nonbank SD's uncleared swap margin amount; or (iii) the amount of capital required by NFA.
A nonbank SD is required to reduce the value of its highly liquid assets by the market risk exposure requirement and/or the credit risk exposure requirement in computing its net capital.
A nonbank SD that has obtained Commission or NFA approval, may use internal market risk and/or credit risk models to compute market risk and/or credit risk capital charges in lieu of the standardized capital charges.
The Commission's NLA Approach is consistent with the SEC's SBSD capital rule, and is based on the Commission's capital rule for FCMs and the SEC's capital rule for securities broker-dealers (“BDs”). The quantitative and qualitative requirements for NLA Approach internal market and credit risk models are also consistent with the quantitative and qualitative requirements of the Commission's Bank-Based Approach as described below.
The Commission's Bank-Based Approach for computing regulatory capital for nonbank SDs is based on certain capital requirements imposed by the Federal Reserve Board for bank holding companies.
The terms used in the Commission's Bank-Based Approach are defined by reference to regulations of the Federal Reserve Board.
Common equity tier 1 capital, additional tier 1 capital, and tier 2 capital are unencumbered and generally long-term or permanent forms of capital that help ensure that a nonbank SD will be able to absorb losses resulting from its operations and maintain confidence in the nonbank SD as a going concern. In addition, in setting an equity ratio requirement, this limits the amount of asset growth and leverage a nonbank SD can incur, as a nonbank SD must fund its asset growth with a certain percentage of regulatory capital.
A nonbank SD also must compute its risk-weighted assets using standardized capital charges or, if approved, internal models. Risk-weighting assets involves adjusting the notional or carrying value of each asset based on the inherent risk of the asset. Less risky assets are adjusted to lower values (
Nonbank SDs not approved to use internal models to risk-weight their assets must compute market risk capital charges using the standardized charges contained in Regulation 1.17 and SEC Rule 18a-1, and must compute their credit risk charges using the standardized capital charges set forth in regulations of the Federal Reserve Board for bank holding companies contained in Subpart D of 17 CFR part 217.
Standardized market risk charges are computed under Regulation 1.17 and SEC Rule 18a-1 by multiplying, as appropriate to the specific asset schedule, the notional value or market value of the nonbank SD's proprietary financial positions (such as swaps, security-based swaps, futures, equities, and U.S. Treasuries) by fixed percentages set forth in the Regulation or Rule.
A nonbank SD also may apply to the Commission or NFA for approval to use internal models to compute market risk exposure and/or credit risk exposure for purposes of determining its total risk-weighted assets.
The Mexican Capital Rules impose bank-like capital requirements on a Mexican nonbank SD that are consistent with the BCBS framework for international bank-based capital standards.
The Mexican Capital Rules require each Mexican nonbank SD to hold and maintain: (i) common equity tier 1 capital equal to at least 4.5 percent of the Mexican nonbank SD's risk-weighted assets; (ii) total tier 1 capital (
The amount of regulatory capital required to be held by a Mexican nonbank SD is determined by calculating and aggregating the firm's total risk exposures, including market risk, credit risk, and operational risk.
Mexican nonbank SDs compute the capital charges for market risk exposure and credit risk exposure using
Standardized market risk and credit risk charges are calculated under the Mexican Capital Rules using a methodology that is consistent with the BCBS bank capital framework for standardized market risk and credit risk charges. With respect to market risk, the Mexican Capital Rules require a Mexican nonbank SD to multiply the market value or carrying value of its on-balance sheet and off-balance sheet market exposures by standard percentages established by the Mexican Commission and set forth in the Mexican Capital Rules.
A Mexican nonbank SD calculates its capital charges for operational risk exposure using the basic method set forth in the General Provisions.
The Mexican Capital Rules also impose liquidity requirements on Mexican nonbank SDs in addition to minimum capital requirements.
A Mexican nonbank SD also must follow specified procedures in monitoring its liquidity to ensure that it has sufficient liquid assets to meet anticipated needs.
The following section provides a description and comparative analysis of the regulatory requirements of the Mexican Capital Rules and Mexican Financial Reporting Rules to the CFTC Capital Rules and CFTC Financial Reporting Rules. Immediately following a description of the requirement(s) of the CFTC Capital Rules or the CFTC Financial Reporting Rules for which a comparability determination was requested by the Applicants, the Commission provides a description of Mexico's corresponding laws, regulations, or rules. The Commission then provides a comparative analysis of the Mexican Capital Rules or the Mexican Financial Reporting Rules with the corresponding CFTC Capital Rules or CFTC Financial Reporting Rules. The Commission identifies any material differences between the respective rules.
The Commission performed this proposed Capital Comparability Determination by assessing the comparability of the Mexican Capital Rules for Mexican nonbank SDs, as set forth in the Mexico Application and in the English language translation of certain Mexican laws and regulations, with the Commission's Bank-Based Approach. For clarity, the Commission did not assess the comparability of the Mexican Capital Rules to the Commission's TNW Approach or NLA Approach as the Commission understands that the Applicants, as of the date of the Mexico Application, are subject to the current bank-based capital approach of the Mexican Capital Rules. Accordingly, when the Commission makes a preliminary determination herein about the comparability of the Mexican Capital Rules with the CFTC Capital Rules, the determination pertains to the comparability of the Mexican Capital Rules with the Bank-Based Approach under the CFTC Capital Rules.
As described below, it is proposed that any material changes to the Mexican Capital Rules will require notification to the Commission. Therefore, if there are subsequent material changes to the Mexican Capital Rules to include, for example, another capital approach, the Commission will review and assess the impact of such changes on the Capital Comparability Determination Order as it is then in effect, and may amend or supplement the Order.
In addition, although the BCBS bank capital standards establish minimum capital standards that are consistent with the requirements of the Commission's Bank-Based Approach, the Commission notes that consistency with the BCBS standards is not determinative of a finding of comparability with the CFTC Capital Rules. In the Commission's view, a foreign jurisdiction's consistency with the BCBS international bank capital standards is an element in the Commission's comparability assessment, but, in and of itself, it may not be sufficient to demonstrate comparability with the CFTC Capital Rules without an assessment of the individual elements of the foreign jurisdiction's capital framework.
Capital and financial reporting regimes are complex structures comprised of a number of interrelated regulatory components. Differences in how jurisdictions approach and implement these regimes are expected, even among jurisdictions that base their requirements on the principles and standards set forth in the BCBS international bank capital framework. Therefore, the Commission's comparability determination involves a detailed assessment of the relevant requirements of the foreign jurisdiction and whether those requirements, viewed in the aggregate, lead to an outcome that is comparable to the outcome of the CFTC's corresponding requirements. Consistent with this approach, the Commission has grouped the CFTC Capital Rules and CFTC Financial Reporting Rules into key categories that focus the analysis on whether the Mexican capital and financial reporting requirements are comparable to the Commission's SD requirements in purpose and effect, and not whether the Mexican requirements meet every aspect or contain identical elements as the Commission's requirements.
Specifically, as discussed in detail below, the Commission used the following key categories in its review: (i) the quality of the equity and debt instruments that qualify as regulatory capital, and the extent to which the regulatory capital represents committed and permanent capital that would be available to absorb unexpected losses or counterparty defaults; (ii) the process of establishing minimum capital requirements for a Mexican nonbank SD and how such process addresses market risk and credit risk of the firm's on-balance sheet and off-balance sheet exposures; (iii) the financial reports and other financial information submitted by a Mexican nonbank SD to its relevant regulatory authorities to effectively monitor the financial condition of the firm; and (iv) the regulatory notices and other communications between the Mexican nonbank SD and its relevant regulatory authorities that detail potential adverse financial or operational issues that may impact the firm. The Commission also reviewed the manner in which compliance by a Mexican nonbank SD with the Mexican Capital Rules and Mexican Financial Reporting rules is monitored and enforced. The Commission invites public comment on all aspects of the Mexico Application and on the Commission's Capital Comparability Determination discussed below.
The regulatory objectives of the CFTC Capital Rules and CFTC Financial Reporting Rules are to further the Congressional mandate to ensure the safety and soundness of nonbank SDs to mitigate the greater risk to nonbank SDs and the financial system arising from the use of swaps that are not cleared.
The objective of the CFTC Financial Reporting Rules is to provide the Commission with the means to monitor
The regulatory objective of the Mexican Capital Rules is to ensure the safety and soundness of Mexican financial firms, including Mexican nonbank SDs. The Mexican Capital Rules are designed to preserve the financial stability and solvency of a Mexican nonbank SD by requiring the firm to maintain a sufficient amount of quality equity and subordinated debt to absorb decreases in the value of firm assets, increases in the value of firm liabilities, and to cover losses from business activities, including counterparty defaults and margin collateral shortfalls associated with the firm's swap dealing activities.
The objective of the Mexican Financial Reporting Rules is to enable the Mexican Commission and other relevant Mexican regulatory authorities to assess the financial condition and safety and soundness of Mexican nonbank SDs.
The Commission has reviewed the Mexico Application and the relevant Mexican laws and regulations, and has preliminarily determined that the overall objectives of the Mexican Capital Rules and CFTC Capital Rules are comparable in that both sets of rules are intended to ensure the safety and soundness of nonbank SDs by establishing a regulatory regime that requires nonbank SDs to maintain a sufficient amount of qualifying regulatory capital to absorb losses, including losses from swaps and other trading activities, and to absorb decreases in the value of firm assets and increases in the value of firm liabilities without the nonbank SDs becoming insolvent. The Mexican Capital Rules and CFTC Capital Rules are also based on, and consistent with, the BCBS international bank capital framework, which was designed to ensure that banking entities hold sufficient levels of capital to absorb losses, decreases in the value of assets, and increases in the value of liabilities without the banks becoming insolvent.
The Mexican Capital Rules are comparable in purpose and effect to the CFTC Capital Rules in that both regulatory approaches compute the minimum capital requirements based on the level of a nonbank SD's on-balance sheet and off-balance sheet exposures, with the objective and purpose of ensuring that the nonbank SD's capital is adequate to absorb losses resulting from such exposures. The Mexican Capital Rules and CFTC Capital Rules also provide for a comparable approach to the calculation of on-balance sheet and off-balance sheet risk exposures using non-model, standardized approaches that result in comparable risk exposure amounts. The Mexican Capital Rules' and CFTC Capital Rules' requirements for identifying and measuring on-balance sheet and off-balance sheet exposures under standardized approaches are also consistent with the requirements set forth under the BCBS international bank capital framework for identifying and measuring on-balance sheet and off-balance sheet exposures.
The Mexican Capital Rules and CFTC Capital Rules achieve comparable outcomes and are comparable in purpose and effect in that both limit the types of capital instruments that may qualify as regulatory capital to cover the on-balance sheet and off-balance sheet risk exposures to high quality equity capital and qualifying subordinated debt instruments that meet conditions designed to ensure that the holders of the debt have effectively subordinated their claims to other creditors of the nonbank SD. Both the Mexican Capital Rules and the CFTC Capital Rules define high quality capital by the degree to which the capital represents permanent capital that is contributed, or readily available to a nonbank SD, on an unrestricted basis to absorb unexpected losses, including losses from swaps trading and other activities, decreases in the value of firm assets, and increases in the value of firm liabilities without the nonbank SD becoming insolvent.
The Mexican Financial Reporting Rules are also comparable in purpose and effect with the CFTC Financial Reporting Rules as both the Mexican Commission and CFTC require nonbank SDs to file periodic financial reports, including unaudited financial reports and an annual audited financial report, detailing their financial operations and demonstrating their compliance with minimum capital requirements. In addition to providing the CFTC and Mexican Commission with information necessary to comprehensively assess the financial condition of a nonbank SD on an ongoing basis, the financial reports further provide the CFTC and Mexican Commission with information regarding potential changes in a nonbank SD's risk profile by disclosing changes in account balances reported over a period of time. Such changes in account balances may indicate that the nonbank SD has entered into new lines of business, has increased its activity in an existing line of business relative to other activities, or has terminated a previous line of business.
The prompt and effective monitoring of the financial condition of nonbank SDs through the receipt and review of periodic financial reports supports the Commission and Mexican Commission in meeting their respective objectives of ensuring the safety and soundness of nonbank SDs. In this connection, the early identification of potential financial
The Commission invites public comment on its analysis above, including comment on the Mexico Application and relevant Mexican laws and regulations.
The CFTC Capital Rules require a nonbank SD electing the Bank-Based Approach to maintain regulatory capital in the form of common equity tier 1 capital, additional tier 1 capital, and tier 2 capital in amounts that meet certain stated minimum requirements set forth in Regulation 23. 101.
Common equity tier 1 capital is generally composed of an entity's common stock instruments and any related surpluses, retained earnings, and accumulated other comprehensive income, and is a more conservative or permanent form of capital than additional tier 1 and tier 2 capital.
Subordinated debt must meet certain conditions to qualify as tier 2 capital under the CFTC Capital Rules. Specifically, subordinated debt instruments must have a term of at least one year (with the exception of approved revolving subordinated debt agreements which may have a maturity term that is less than one year), and contain terms that effectively subordinate the rights of lenders to receive any payments, including accrued interest, to other creditors of the firm.
Common equity tier 1 capital, additional tier 1 capital, and tier 2 capital are permitted to be included in a nonbank SD's regulatory capital and used to meet the firm's minimum capital requirement due to their characteristics of being permanent forms of capital that are subordinate to the claims of other creditors, which ensures that a nonbank SD will have this regulatory capital to absorb decreases in the value of the firm's assets and increases in the value of the firm's liabilities, and to cover losses from business activities, including swap dealing activities, without the firm becoming insolvent.
The Mexican Capital Rules require each Mexican nonbank SD to maintain a level of regulatory capital that equals or exceeds 8 percent of the firm's risk-weighted assets, which is the sum of the Mexican nonbank SD's market risk, credit risk, and operational risk charges.
Furthermore, with respect to tier 2 capital, qualifying subordinated debt may not be short-term debt and the Mexican nonbank SD must retain the right to cancel the payment of interest on the debt.
A Mexican nonbank SD must also maintain a capital conservation buffer equal to 2.5 percent of the firm's risk-weighted assets in addition to the requirement to maintain qualifying regulatory capital in excess of 8 percent of its risk-weighted assets. The 2.5 percent capital conservation buffer must be met with common equity tier 1 capital.
The Mexican Capital Rules also impose different ratios for the various components of regulatory capital that are consistent with the BCBS bank capital framework.
The Commission has reviewed the Mexico Application and the relevant Mexican laws and regulations, and has preliminarily determined that the Mexican Capital Rules are comparable in purpose and effect to CFTC Capital Rules with regard to the types and characteristics of a nonbank SD's equity that qualifies as regulatory capital in meeting its minimum requirements. The Mexican Capital Rules and the CFTC Capital Rules for nonbank SDs both require a nonbank SD to maintain a quantity of high-quality and permanent capital, all defined in a manner that is consistent with the BCBS international bank capital framework, that based on the firm's activities and on-balance sheet and off-balance sheet exposures, is sufficient to absorb losses and decreases in the value of the firm's assets and increases in the value of the firm's liabilities without resulting in the firm becoming insolvent. Specifically, equity instruments that qualify as common equity tier 1 capital and additional tier 1 capital under the Mexican Capital Rules and the CFTC Capital Rules have similar characteristics (
In addition, the Commission has preliminarily determined that the conditions imposed on subordinated debt instruments under the Mexican Capital Rules and the CFTC Capital Rules are comparable and are designed to ensure that the subordinated debt has qualities that support its recognition by a nonbank SD as equity for capital purposes. The conditions include, in the case of the CFTC Capital Rules, regulatory requirements that effectively subordinate the claims of debt holders to interest and repayment of the debt to the claims of other creditors of the nonbank SD, and, in the case of the Mexican Capital Rules, regulatory requirements that provide Mexican nonbank SDs with the right to cancel scheduled interest payments and to convert the debt to common equity of the firm.
Having reviewed the Mexico Application and the relevant Mexican laws and regulations, the Commission has made a preliminary determination that the Mexican Capital Rules and CFTC Capital Rules impose comparable requirements on Mexican nonbank SDs with respect to the types and characteristics of equity capital that must be used to meet minimum regulatory capital requirements. The Commission invites public comment on its analysis above, including comment on the Mexico Application and the relevant Mexican laws and regulations.
The CFTC Capital Rules require a nonbank SD electing the Bank-Based Approach to maintain regulatory capital that satisfies each of the following criteria: (i) an amount of common equity tier 1 capital of at least $20 million; (ii) an aggregate of common equity tier 1 capital, additional tier 1 capital, and tier 2 capital in an amount equal to or in excess of 8 percent of the nonbank SD's uncleared swap margin amount; (iii) an aggregate amount of common equity tier 1 capital, additional tier 1 capital, and tier 2 capital equal to or greater than 8 percent of the nonbank SD's total risk-weighted assets, provided that common equity tier 1 capital comprises at least 6.5 percent of the 8 percent; and (iv) the amount of capital required by the NFA.
Prong (i) above requires each nonbank SD electing the Bank-Based Approach to maintain a minimum of $20 million of common equity tier 1 capital in order to operate as a nonbank SD. The requirement that each nonbank SD electing the CFTC Bank-Based Approach maintain a minimum of $20 million of common equity tier 1 capital is also consistent with the minimum capital requirement for nonbank SDs electing the NLA Approach and the TNW Approach.
Prong (ii) above is a minimum capital requirement that is based on the amount of uncleared margin for swap transactions entered into by the nonbank SD and is computed on a counterparty by counterparty basis. The requirement for a nonbank SD to maintain minimum capital equal to or greater than 8 percent of the firm's uncleared swap margin provides a capital floor based on a measure of the risk and volume of the swap positions, and the number of counterparties and the complexity of operations, of the nonbank SD. The intent of the minimum capital requirement based on a percentage of the nonbank SD's uncleared swap margin was to establish a minimum capital requirement that would help ensure that the nonbank SD meets all of its obligations as a SD to market participants, and to cover potential operational risk, legal risk and
Prong (iii) above is a minimum capital requirement that is based on the Federal Reserve Board's capital requirements for bank holding companies and is consistent with the BCBS international capital framework for banking institutions. As noted above, a nonbank SD under prong (iii) must maintain an aggregate of common equity tier 1 capital, additional tier 1 capital, and tier 2 capital in an amount equal to or greater than 8 percent of the nonbank SD's total risk-weighted assets, with common equity tier 1 capital comprising at least 6.5 percent of the 8 percent. Risk-weighted assets are a nonbank SD's on-balance sheet and off-balance sheet exposures, including proprietary swap, security-based swap, equity, and futures positions, weighted according to risk. The Bank-Based Approach requires each nonbank SD to maintain regulatory capital in an amount that equals or exceeds 8 percent of the firm's total risk-weighted assets to help ensure that the nonbank SD's level of capital is sufficient to absorb decreases in the value of the firm's assets and increases in the value of the firm's liabilities, and to cover unexpected losses resulting from business activities, including uncollateralized defaults from swap counterparties, without the nonbank SD becoming insolvent.
A nonbank SD must compute its risk-weighted assets using standardized market risk and credit risk charges, unless the nonbank SD has been approved by the Commission or NFA to use internal models.
With respect to standardized credit risk charges for exposures from non-derivatives positions, a nonbank SD computes its on-balance sheet and off-balance sheet exposures in accordance with the standardized credit risk charges adopted by the Federal Reserve Board and set forth in Subpart D of 12 CFR 217.
A nonbank SD may compute standardized credit risk charges for derivatives positions, including uncleared swaps and non-cleared security-based swaps, using either the current exposure method (“CEM”) or the standardized approach for measuring counterparty credit risk (“SA-CCR”).
A nonbank SD also may obtain the approval of the Commission or NFA to use internal models to compute market risk and/or credit risk charges in lieu of the standardized charges. A nonbank SD seeking approval to use an internal model is required to submit an application to the Commission or NFA.
A nonbank SD approved by the Commission or NFA to use internal models to compute market risk is required to comply with Subpart F of the Federal Reserve Board's Part 217 regulations (“Subpart F”).
A nonbank SD approved to use internal models to compute credit risk is required to perform such computation in accordance with Subpart E of the Federal Reserve Board's Part 217
Under the Basel 2.5 capital framework, nonbank SDs have flexibility in developing their internal models, but must follow certain minimum standards. Internal market risk and credit risk models must follow a Value-at-Risk (“VaR”) structure to compute, on a daily basis, a 99th percentile, one-tailed confidence interval for the potential losses resulting from an instantaneous price shock equivalent to a 10-day movement in prices (unless a different time-frame is specifically indicated). The simulation of this price shock must be based on a historical observation period of minimum length of one year but there is flexibility on the method used to render simulations, such as variance-covariance matrices, historical simulations, or Monte Carlo.
The Commission and the Basel standards for internal models also have requirements on the selection of appropriate risk factors as well as on data quality and update frequency.
In addition, BCBS standards for market risk models include a series of additive components for risks for which the broad VaR is ill-suited or that may need targeted calculation. These include the calculation of a Stressed VaR measure (with the same specifications as the VaR, but calibrated to historical data from a continuous 12-month period of significant financial stress relevant to the firm's portfolio); a Specific Risk measure (which includes the effect of a specific instrument); an Incremental Risk measure (which addresses changes in the credit rating of a specific obligor which may appear as a reference in an asset); and a Comprehensive Risk measure (which addresses risk of correlation trading positions).
The Mexican Capital Rules impose bank-like capital requirements on a Mexican nonbank SD that, consistent with the BCBS international bank capital framework, require the Mexican nonbank SD to hold a sufficient amount of qualifying equity capital and subordinated debt to absorb decreases in the value of firm assets and increases in the value of firm liabilities, and to cover losses from its activities, including possible counterparty defaults and margin collateral shortfalls associated with its swap dealing activities, without the firm becoming insolvent. Specifically, the Mexican Capital Rules require each Mexican nonbank SD to maintain qualifying regulatory capital to satisfy the following capital ratios, expressed as a percentage of the firm's total risk-weighted assets: (i) common equity tier 1 capital equal to at least 4.5 percent of the firm's risk-weighted assets; (ii) total tier 1 capital (
The Mexican nonbank SD's risk-weighted assets are calculated as the sum of the firm's market risk, credit risk, and operational risk charges. The risk charges are computed using standardized (
A Mexican nonbank SD is required to take a deduction from capital for market risk based on standardized charges published by the Mexican Commission,
For derivatives positions, a Mexican nonbank SD is required to take standardized market risk charges based on the nature of the instrument underlying the derivatives position.
The resulting total market risk exposure amount, including market risk exposure for derivative positions, is multiplied by a factor of 12.5 to adjust the 8 percent multiplication factor applied to all of the Mexican nonbank SD's risk-weighted assets, which effectively requires a Mexican nonbank SD to hold qualifying regulatory capital equal to or greater than 100 percent of the firm's market risk exposure amount.
The Mexican Capital Rules also require a Mexican nonbank SD to calculate credit risk exposure under a standardized approach by taking the accounting value of each of its on-balance sheet and off-balance sheet positions and exposures, determining a conversion value to credit risk determined pursuant to Mexican regulation,
The Mexican Capital rules further require a Mexican nonbank SD to retain qualifying regulatory capital to cover operational risk. Operational risk is computed using the basic method set forth in the Mexican Capital Rules.
The Mexican Capital Rules also require a Mexican nonbank SD to comply with minimum paid-in capital requirements depending on the services or activities to be performed by the firm.
In addition to the minimum paid-in-capital requirement, the Mexican Central Bank also imposes limits on a Mexican nonbank SD's overall leverage.
The Mexican Commission may also require a Mexican nonbank SD to satisfy additional capital requirements, considering the composition of the firm's capital, the composition of the firm's assets, the efficiency of the firm's internal control systems, the firm's compliance with its remuneration system and, in general, the firm's exposure and risk management.
The Mexican Capital Rules also impose liquidity requirements on Mexican nonbank SDs
A Mexican nonbank SD also must follow specified procedures in monitoring its liquidity and to ensure that it has sufficient liquid assets to meet anticipated needs.
Lastly, a Mexican nonbank SD is required to conduct annual stress tests to ensure that the firm retains sufficient capital.
The Commission has reviewed the Mexico Application and the relevant Mexican laws and regulations, and has preliminarily determined that the Mexican Capital Rules are comparable in purpose and effect to CFTC Capital Rules with regard to the establishment of a nonbank SD's minimum capital requirement and the calculation of the nonbank SD's amount of regulatory capital. Although there are differences in the minimum capital requirements and calculation of regulatory capital between the Mexican Capital Rules and the CFTC Capital Rules, as discussed below, the Commission preliminary believes that the Mexican Capital Rules and the CFTC Capital rules are designed to ensure the safety and soundness of a nonbank SD, and subject to the proposed conditions discussed below, will achieve comparable outcomes by requiring the firm to maintain a minimum level of qualifying regulatory capital, including subordinated debt, to absorb losses from the firm's business activities, including its swap dealing activities, and decreases in the value of the firm's assets and increases in the value of the firm's liabilities, without the nonbank SD becoming insolvent.
The CFTC Capital Rules require a nonbank SD electing the Bank-Based Approach to maintain regulatory capital in an amount that meets or exceeds each of the following requirements: (i) $20 million of common equity tier 1 capital; (ii) 8 percent of the nonbank SD's uncleared swap margin amount; (iii) 8 percent of the nonbank SD's risk-weighted assets (with common equity tier 1 capital comprising at least 6.5 percent of the 8 percent); and (iv) the amount of capital required by NFA.
Prong (i) of the CFTC Capital Rules recited above requires each nonbank SD electing the Bank-Based Approach to maintain a minimum of $20 million of common equity tier 1 capital. The CFTC's $20 million fixed-dollar minimum capital requirement is intended to ensure that each nonbank SD maintains a level of regulatory capital, without regard to the level of the firm's dealing and other activities, sufficient to meet its obligations to swap market participants given the firm's status as a CFTC-registered nonbank SD and to help ensure the safety and soundness of the nonbank SD.
The Mexican Capital Rules also contain a requirement that each Mexican nonbank SD maintain a fixed amount of minimum paid-in capital that is based on the services or activities performed by the firm.
The Mexican Capital Rules and the CFTC Capital Rules both require nonbank SDs to hold a minimum amount of regulatory capital that is not based on the risk-weighted assets of the firms. The Commission, however, preliminarily believes that CFTC-registered nonbank SDs should maintain a minimum amount of $20 million of common equity tier 1 capital irrespective of the volume of its dealing activities to help ensure that the firm satisfies its regulatory obligations to market participants, including meeting its financial commitments to swap counterparties and creditors, without the firm becoming insolvent. The Commission recognizes that the $20 million of common equity tier 1 capital required under the CFTC Capital Rules is substantially higher than the estimated $4.3 million of minimum paid-in capital required under the Mexican Capital Rules and preliminarily believes that the $20 million represents a more appropriate level of minimum capital to help ensure the safety and soundness of the nonbank SD that is engaging in uncleared swap transactions. Since the Commission preliminarily finds fundamental capital, as defined in Article 162 and Article 162 Bis of the General Provisions, to be comparable to common equity tier 1 capital required under the CFTC Capital Rules, the Commission is proposing to condition the Capital Comparability Determination Order to require each Mexican nonbank SD to maintain, at all times, a minimum level of $20 million of fundamental capital.
The Commission preliminarily believes that the Mexican Capital Rules and CFTC Capital Rules are also comparable in that both impose minimum capital requirements on nonbank SDs that are based on the BCBS bank capital framework, which requires a banking entity to hold qualifying capital, including subordinated debt, in an amount in excess of certain percentages of the banking entity's risk-weighted assets (
The Mexican Capital Rules contain capital requirements for Mexican nonbank SDs that the Commission preliminarily believes are comparable to the requirements contained in prong
The Commission also preliminarily believes that the Mexican Capital Rules and CFTC Capital Rules are comparable with respect to the calculation of market risk and credit risk in determining a nonbank SD's risk-weighted assets. As noted above, Mexican nonbank SDs currently are not authorized by the Mexican Commission to use models to compute market risk or credit risk exposures and, therefore, must compute their risk-weighted assets using standardized market risk and credit risk charges set forth in the Mexican Capital Rules, which generally produce charges that are higher than model-based charges.
The Commission preliminarily believes that the approach to computing the standardized market risk and credit risk charges set forth in the Mexican Capital Rules is comparable to the standardized approach set forth in the CFTC Capital Rules, and is also consistent with the approach for calculating standardized market risk and credit risk charges under the BCBS bank capital framework. Specifically, the standardized approaches under the Mexican Capital Rules and CFTC Capital Rules for calculating market and credit risk follow the same structure that is now the common global standard: allocating assets to categories according to risk and assigning each category a risk-weight; allocating counterparties according to risk assessments and assigning each a risk factor; calculating gross exposures based on valuation of assets; calculating a net exposure allowing offsets following well defined procedures and subject to clear limitations; adjusting the net exposure by the market risk-weights; and finally, for credit risk exposures, multiplying the sum of net exposures to each counterparty by their corresponding risk factor.
The Mexican Capital Rules, however, differ from the CFTC Capital Rules with respect to a nonbank SD's computation of its market risk exposures and credit risk exposures that are included in the firm's risk-weighted assets. As noted above, the CFTC Capital Rules and Mexican Capital Rules both require a nonbank SD to maintain regulatory capital equal to or greater than 100 percent of the firm's market risk exposure amount.
The Commission also preliminarily believes that the Mexican Capital Rules and CFTC Capital Rules are comparable in that nonbank SDs are required to account for operational risk, in addition to market risk and credit risk, in computing their minimum capital requirements. In this connection, the Mexican Capital Rules require a Mexican nonbank SD to calculate an operational risk exposure amount equal to 15 percent of a Mexican nonbank SD's average annual net positive income for the last three years, on a rolling basis.
The CFTC Capital Rules address operational risk as a stand-alone, separate minimum capital requirement that a nonbank SD is required to meet under prong (ii) of the Bank-Based Approach recited above, and not as an additional risk exposure element in the calculation of the nonbank SD's total risk weighted assets.
CFTC rules also require a SD to maintain a risk management program to address certain risks associated with operating as SD, including operational, liquidity, legal, market, credit, foreign currency, settlement, and other applicable risks.
The Mexican Capital Rules and CFTC rules also impose liquidity requirements on Mexican nonbank SDs and nonbank SDs, respectively. The Mexican Capital Rules require Mexican nonbank SDs to meet quantitative liquidity requirements, which require a Mexican nonbank SD to hold or invest at least 20 percent of the firm's total capital in liquid assets comprised of: (i) bank deposits; (ii) highly liquid debt securities registered in Mexico; (iii) shares of debt investment funds; (iv) reserve funds created to maintain funds available to cover contingencies; and (v) high and low marketability shares subject to market value discounts of 20 and 25 percent, respectively.
The CFTC Capital Rules do not include a specific, quantifiable, liquidity component. The CFTC rules, however, address liquidity risks through the SD risk management program. Specifically, the SD's risk management program must take into account, among other things, the daily measurement of liquidity needs, the assessment of the procedures to liquidate all non-cash collateral in a timely manner without a significant effect on price, and the application of appropriate haircuts that accurately reflect market risk and credit risk of the noncash collateral.
The CFTC SD risk management requirements also address legal risk. Regulation 23.600(c)(4)(v) requires a SD to take into account, among other things, determinations that transactions and netting arrangements entered into have a sound legal basis, and the establishment of documentation tracking procedures designed to ensure the completeness of relevant documentation and procedures to resolve any documentation exceptions on a timely basis.
The Commission has reviewed the Mexico Application and the relevant Mexican laws and regulations, and has preliminarily determined that the Mexican Capital Rules are comparable in purpose and effect to CFTC Capital Rules with regard to the establishment of a nonbank SD's minimum capital requirement and the calculation of the nonbank SD's amount of regulatory capital to meet that requirement. As previously noted, the Commission's approach for conducting a comparability determination is a principles-based, holistic approach that focuses on whether the applicable foreign jurisdiction's capital requirements for nonbank SDs achieve comparable outcomes to the corresponding CFTC requirements for nonbank SDs.
The Commission invites comment on the Mexico Application, Mexican laws and regulations, and the Commission's analysis above regarding its preliminary determination that, subject to the $20 million minimum capital requirement, the Mexican Capital Rules and the CFTC Capital Rules are comparable in purpose and effect and achieve comparable outcomes with respect to the minimum regulatory capital requirements and the calculation of regulatory capital for nonbank SDs. The Commission also specifically seeks public comment on the question of whether the requirement under the Mexican Capital Rules for a Mexican nonbank SD to hold qualifying capital in an amount equal to 15 percent of its average annual net positive income from the last three years, taking into account insurance coverage for operational risk, and subject to a floor equal to 5 percent and a ceiling of 15 percent of the monthly average sum of market risk and credit risk exposures amounts, calculated over the prior 36 months, on a rolling basis, is sufficiently comparable in purpose and effect to the CFTC's requirement for a nonbank SD to hold qualifying capital in amount equal
The CFTC Financial Reporting Rules imposes financial recordkeeping and reporting requirements on nonbank SDs. The CFTC Financial Reporting Rules require each nonbank SD to prepare and keep current ledgers or similar records summarizing each transaction affecting the nonbank SD's asset, liability, income, expense, and capital accounts.
The CFTC Financial Reporting Rules also require each nonbank SD to prepare and file with the Commission and with NFA periodic unaudited and annual audited financial statements.
The CFTC Financial Reporting Rules provide that a nonbank SD's unaudited financial statements must include: (i) a statement of financial condition; (ii) a statement of income/loss; (iii) a statement of changes in liabilities subordinated to claims of general creditors; (iv) a statement of changes in ownership equity; (v) a statement demonstrating compliance with and calculation of the applicable regulatory requirement; and (vi) such further material information necessary to make the required statements not misleading.
A nonbank SD that has obtained approval from the Commission or NFA to use internal capital models also must submit certain model metrics, such as aggregate VaR and counterparty credit risk information, each month to the Commission and NFA.
The CFTC Financial Reporting Rules also require a nonbank SD to attach to each unaudited and audited financial report an oath or affirmation that to the best knowledge and belief of the individual making the affirmation the information contained in the financial report is true and correct.
The CFTC Financial Reporting Rules further require each nonbank SD to make certain financial information publicly available by posting the information on its public website.
The CFTC Financial Reporting Rules also require a nonbank SD to provide the Commission and NFA with information regarding the custodianship of margin for uncleared swap transactions (“Margin Report”).
The Mexican Financial Reporting Rules impose financial recordkeeping and reporting requirements on Mexican nonbank SDs that enable the Mexican Commission to assess the financial condition and safety and soundness of the Mexican nonbank SDs. Consistent with that purpose, a Mexican nonbank SD must periodically report its financial position and capital levels to the Mexican Commission and other Mexican regulatory authorities. The reporting of financial position and capital level information, along with other reporting requirements, provide the Mexican Commission with a comprehensive view of the activities and financial condition of each Mexican nonbank SD.
Specifically, the Mexican Financial Reporting Rules require a Mexican nonbank SD to submit to the Mexican Commission quarterly consolidated financial reports and an annual consolidated financial report.
The Mexican nonbank SD's quarterly consolidated financial reports and annual audited consolidated financial report must contain a balance sheet, a statement of income/loss, a statement of changes in equity, a statement of cash flows, and a statement showing the firm's compliance with minimum capital requirements.
In addition to the above consolidated financial reports, each Mexican nonbank SD must provide the Mexican Commission, on a monthly basis, with a balance sheet and income statement, along with additional financial information.
A Mexican nonbank SD licensed to enter into derivatives transactions for its own account is also required to file with the Mexican Central Bank, during May of each year, a written communication issued by the Mexican nonbank SD's internal audit committee evidencing compliance in the performance of its derivatives transactions with each and all applicable legal provisions and, when required by the Mexican Central Bank, a Mexican nonbank SD also must provide the Mexican Central Bank with all the information related to the derivatives transactions performed by the firm.
A Mexican nonbank SD is also required to make certain financial condition information publicly available by posting the information on a publicly accessible website. Specifically, a Mexican nonbank SD is required to provide its quarterly financial statements to the general public along with information related to the firm's regulatory capital structure, including the main components of the firm's regulatory capital structure, the capital adequacy level, and the amount of the assets subject to risk.
The Commission has reviewed the Mexico Application and the relevant Mexican laws and regulations, and has preliminarily determined that the financial reporting requirements of the Mexican Financial Reporting Rules, subject to the conditions specified below, are comparable to the CFTC Financial Reporting Rules in purpose and effect as they are intended to provide the Mexican Commission and Mexican Central Bank, as applicable, and the Commission, respectively, with financial information to monitor and assess the financial condition of nonbank SDs and their ongoing ability to absorb decreases in the value of firm assets and increases in the value of firm liabilities, and to cover losses from business activities, including swap dealing activities, without the firm becoming insolvent.
The Mexican Financial Reporting Rules require each Mexican nonbank SD to prepare and submit to the Mexican Commission on a quarterly basis an unaudited financial report, and on an annual basis an audited financial report, that includes: (i) a statement of financial condition; (ii) a statement of profit and loss; (iii) a statement of changes in equity; (iv) a statement of cash flows; and (v) a statement showing the firm's compliance with minimum capital requirements. In addition, a Mexican nonbank SD is required to file a
The Commission is proposing to condition the Capital Comparability Determination Order on a Mexican nonbank SD providing the Commission and NFA with copies of the monthly financial information, including a copy of its balance sheet and income statement, that is filed with the Mexican Commission pursuant to Article 202 and Exhibit 9 of the General Provisions. It is further proposed that a Mexican nonbank SD must provide the Commission and NFA with copies of its quarterly consolidated financial reports and annual audited financial reports that are filed with the Mexican Commission pursuant to Article 203 of the General Provisions. In addition, the Commission is proposing that the Mexican nonbank SD also provide as part of its monthly filing a statement of regulatory capital. The Commission is also proposing to condition the Capital Comparability Determination Order on the Mexican nonbank SD translating the annual audited and unaudited monthly and quarterly financial reports into the English language with balances contained in the unaudited financial reports converted to U.S. dollars. The annual audited financial report may be presented in U.S. dollars or Mexican pesos. The monthly financial information and the unaudited and audited financial reports must be filed with the Commission and NFA within 15 business days of the earlier of the date the respective reports are filed with the Mexican Commission or the date that the respective reports are required to be filed with the Mexican Commission.
The Commission is proposing to impose these conditions as financial reporting is a critical and central component of the Commission's ongoing obligation to monitor and assess the safety and soundness of nonbank SDs as required under Section 4s(e) of the CEA. For nonbank SDs registered with the Commission, it is necessary for the Commission to effectively monitor the ongoing financial condition of all nonbank SDs, including Mexican nonbank SDs, to help ensure their safety and soundness and their ability to meet their financial obligations to customers, counterparties, and creditors.
The Commission preliminarily believes that its approach of requiring Mexican nonbank SDs to provide the Commission and NFA with copies of the monthly financial information, and the quarterly and annual financial reports, that the firms currently file with the Mexican Commission strikes an appropriate balance of ensuring that the Commission receives the financial reporting necessary for the effective monitoring of the financial condition of the nonbank SDs, while also recognizing the existing regulatory structure of the Mexican Commission including its financial reporting requirements. Under the proposed conditions, the Mexican nonbank SD would not be required to prepare separate financial statements or reports for filing with the Commission, but would be required to translate its current financial statements and reports into the English language with balances converted to U.S. dollars so that Commission staff may properly understand and efficiently analyze the financial information. The proposed conditions also provide the Mexican nonbank SDs with 15 days from the date the reports are provided to the Mexican Commission to translate the documents into English and to convert balances to U.S. dollars.
The Commission is also proposing to condition the Capital Comparability Determination Order on a Mexican nonbank SD filing with the Commission and NFA, on a monthly basis, the aggregate securities, commodities, and swap positions information set forth in Schedule 1 of Appendix B to Subpart E of Part 23.
The Commission is further proposing to condition the Capital Comparability Determination Order on a Mexican nonbank SD submitting with each monthly and quarterly financial report and each annual audited financial report, as well as the applicable Schedule 1, a statement by an authorized representative or representatives of the Mexican nonbank SD that to the best knowledge and belief of the representative or representatives the information contained in the respective report is true and correct, including the translation of the report into the English language and conversion of balances in the reports to U.S. dollars. The statement by the authorized representative or representatives of the Mexican nonbank SD would be in lieu of the oath or affirmation required of nonbank SDs under Regulation 23.105(f),
The Commission is further proposing to condition the Capital Comparability Determination Order on a Mexican nonbank SD filing the Margin Report specified in Regulation 23.105(m) with the Commission and NFA. The Margin Report is required to contain: (i) the name and address of each custodian holding initial margin or variation margin on behalf of the nonbank SD or its swap counterparties; (ii) the amount of initial and variation margin held by each custodian on behalf of the nonbank SD and on behalf its swap counterparties; and (iii) the aggregate
The Commission preliminarily believes that receiving this margin information from Mexican nonbank SDs will assist in the Commission's assessment of the safety and soundness of the Mexican nonbank SDs. Specifically, the Margin Report would provide the Commission with information regarding a Mexican nonbank SD's swap book, the extent to which it has uncollateralized exposures to counterparties or has not met its financial obligations to counterparties. This information, along with the list of custodians holding both the firm's and counterparties' swaps collateral, is expected to assist the Commission in assessing and monitoring potential financial impacts to the nonbank SD resulting from defaults on its swap transactions. The Commission is proposing to require that the Margin Report be filed with the Commission as part of the Mexican nonbank SD's monthly financial information that it prepares pursuant to Article 202 and Exhibit 9 of the General Provisions. Therefore, it is being proposed that each Mexican nonbank SD must file a monthly Margin Report within 15 business days of the earlier of the date the monthly financial reports are filed with the Mexican Commission or the date that the respective reports are required to be filed with the Mexican Commission. The Commission is also proposing that the Margin Report must be prepared in the English language with balances reported in U.S. dollars.
The Commission is not proposing to require a Mexican nonbank SD to file the monthly model metric information contained in Regulation 23.105(k) with the Commission or NFA.
The Commission is also not proposing to require a Mexican nonbank SD to file the monthly counterparty credit exposure information specified in Regulation 23.105(l) and Schedules 2, 3, and 4 of Appendix B to Subpart E of part 23 with the Commission or NFA. Regulation 23.105(l) requires each nonbank SD to provide information to the Commission and NFA regarding its counterparty credit concentration for the 15 largest exposures in derivatives, a summary of its derivatives exposures by internal credit ratings, and the geographic distribution of derivatives exposures for the 10 largest countries in Schedules 2, 3, and 4, respectively. The Commission preliminarily believes that, under a substituted compliance regime, the Mexican Commission is best positioned to monitor a Mexican nonbank SD's credit exposures, which may be comprised of credit exposures to primarily other Mexican counterparties, as part of the Mexican Commission's overall monitoring of the financial condition of the firm.
Furthermore, the Commission, in making the preliminary determination to not require a Mexican nonbank SD to file the counterparty exposures required by Regulation 23.105(l), recognizes that NFA's current risk monitoring program requires each bank SD and each nonbank SD, including each Mexican nonbank SD, to file risk metrics addressing market risk and credit risk with NFA on a monthly basis. NFA's risk metric information includes a list of the 15 largest swaps counterparty exposures providing for each counterparty: (i) current exposure by counterparty before collateral; and (ii) current exposure by counterparty net of collateral. The NFA risk metric information also includes a SD's total current exposure before collateral for the firm across all counterparties, as well as, total current exposure net of collateral.
The Commission notes that the proposed financial reporting conditions in the Mexican Capital Comparability Determination Order are consistent with the proposed conditions set forth in the Commission's proposed Japan Capital Comparability Determination Order,
The Commission invites public comment on its analysis above, including comment on the Mexico Application and relevant Mexican Financial Reporting Rules. The Commission also invites comment on the proposed conditions listed above and on the Commission's proposal not to require Mexican nonbank SDs to submit to the Commission and NFA the information set forth in Regulation 23.105(l) outlined above. Are there specific elements of the data required under Regulations 23.105(l) that the Commission should require of Mexican nonbank SDs for purposes of monitoring the financial condition of the firm?
The Commission requests comment on the proposed filing dates for the reports and information specified above. Specifically, do the proposed filing dates provide sufficient time for Mexican nonbank SDs to prepare the reports, translate the reports into English, and, where required, convert balances into U.S. dollars? If not, what period of time should the Commission consider imposing on one or more of the reports?
The Commission also requests specific comment regarding the setting of compliance dates for the reporting conditions that the proposed Capital
The CFTC Financial Reporting Rules require nonbank SDs to provide the Commission and NFA with written notice of certain defined events.
The CFTC Financial Reporting Rules require a nonbank SD to provide written notice within specified timeframes if the firm is: (i) undercapitalized; (ii) fails to maintain capital at a level that is in excess of 120 percent of its minimum capital requirement; or (iii) fails to maintain current books and records.
The CFTC Financial Reporting Rules further require a nonbank SD to provide advance notice of an intention to withdraw capital by an equity holder that would exceed 30 percent of the firm's excess regulatory capital.
The Mexican Financial Reporting Rules do not include explicit notice provisions that require a Mexican nonbank SD to report certain predefined events to the relevant Mexican regulatory authorities. Specifically, the Mexican Capital Rules do not include provisions requiring a Mexican nonbank SD to notify the Mexican Commission or other relevant regulatory authority if the firm fails to maintain current books and records, fails to meet minimum capital requirements, or experiences a decrease in excess capital from a previous amount reported by the Mexican nonbank SD.
The Commission has reviewed the Mexico Application and Mexican laws and regulations, and has preliminarily determined that the Mexican Financial Reporting Rules related to notice provisions are not comparable to the notice requirements set forth in in Regulation 23.105(c) of the CFTC Financial Reporting Rules. Therefore, the Commission is proposing to condition the Capital Comparability Determination Order to require Mexican nonbank SDs to file certain notices contained in Regulation 23.105(c) with the Commission as discussed below.
The notice provisions contained in Regulation 23.105(c) are intended to provide the Commission and NFA with information in a prompt manner regarding actual or potential financial or operational issues that may adversely impact the safety and soundness of a nonbank SD by impairing the nonbank SD's ability to meet its obligations to counterparties, other creditors, and the general swaps market. Upon the receipt of a notice from a nonbank SD under Regulation 23.105(c), the Commission and NFA will initiate reviews of the facts and circumstances that caused the notice to be filed including, as appropriate, engaging in conversations with personnel of the nonbank SD. The review of the facts and the interaction with the nonbank SD provide the Commission and NFA with information to initiate an assessment of whether it is necessary for the nonbank SD to take remedial action to address potential financial or operational issues, and whether the remedial actions instituted by the nonbank SD properly address the issues that are the root cause of the operational or financial issues. Such actions may include the infusion of additional capital into the firm and the development and implementation of additional internal controls to address operational issues. The notice filings further allow the Commission and NFA to monitor the firm's performance after the implementation of remedial actions to assess the effectiveness of such actions.
As noted above, the Mexican Financial Reporting Rules do not include explicit, predefined notice provisions that require a Mexican nonbank SD to file prompt notice with the Mexican Commission or other relevant Mexican regulatory authority in a manner that is comparable to the notice provisions set forth in Regulation 23.105(c). Therefore, the Commission is proposing to condition the Capital Comparability Determination Order to require Mexican nonbank SDs to file certain defined notices with the Commission and NFA. Specifically, pursuant to the proposed conditions, a Mexican nonbank SD would be required to file a notice with the Commission and NFA, within the timeframe set forth in the proposed conditions, if the firm: (i) failed to keep current books and records; (ii) maintained regulatory capital at a level that is below the minimum capital requirement set by the
The Commission is proposing these conditions so that it will be alerted to the occurrence of any of the defined events in a prompt manner, which will allow the Commission to communicate with the impacted Mexican nonbank SD and NFA to assess the seriousness of the matter and the effectiveness of any actions that the Mexican nonbank SD may have taken to remediate the matter. As noted above, the notices are intended to provide the Commission with “early warning” of potential adverse financial and operational issues at a nonbank SD. The receipt of “early warning” notices are an important component of the Commission's and NFA's programs for effectively overseeing the safety and soundness of nonbank SDs.
The Commission invites public comment on its analysis above, including comment on the Mexico Application and the relevant Mexican Financial Reporting Rules. The Commission also invites comment on the proposed conditions to the Capital Comparability Determination Order that are listed above and set forth in the proposed Order below.
The Commission requests comment on the timeframes set forth in the proposed conditions for Mexican nonbank SDs to file notices with the Commission and NFA. In this regard, the proposed conditions would require Mexican nonbank SDs to file certain written notices with the Commission within 24 hours of the occurrence of a reportable event or of being alerted to a reportable event by the Mexican Commission. These notices would have to be translated into English prior to being filed with the Commission and NFA. The Commission request comment on the issues Mexican nonbank SDs may face meeting the filing requirements given translation and other issues.
The Commission requests specific comment regarding the setting of compliance dates for the notice reporting conditions that the proposed Capital Comparability Determination Order would impose on Mexican nonbank SDs.
The Commission and NFA conduct ongoing supervision of nonbank SDs to assess their compliance with the CEA, Commission regulations, and NFA rules by reviewing financial reports, notices, risk exposure reports, and other filings that nonbank SDs are required to file with the Commission and NFA. The Commission and NFA also conduct periodic examinations as part of their supervision of nonbank SDs, including routine on-site examinations of nonbank SDs' books, records, and operations to ensure compliance with CFTC and NFA requirements.
As noted in section D.1 above, financial reports filed by a nonbank SD provide the Commission and NFA with information necessary to ensure the firm's compliance with minimum capital requirements and to assess the firm's overall safety and soundness and its ability to meet its financial obligations to customers, counterparties, and creditors. A nonbank SD is also required to provide written notice to the Commission and NFA if certain defined events occur, including that the firm is undercapitalized or maintains a level of capital that is less than 120 percent of the firm's minimum capital requirements.
The Commission also has authority to take disciplinary actions against a nonbank SD for failing to comply with the CEA and Commission regulations. Section 4b-1(a) of the CEA
The Mexican Commission has supervisory, inspection, and surveillance powers,
As noted in section D.2 above, Mexican broker-dealers, including Mexican nonbank SDs, are required to submit financial reports to the Mexican Commission detailing their financial condition and operations. Specifically, Mexican nonbank SDs are required to submit to the Mexican Commission monthly balance sheet and income statements,
The Mexican Commission also uses financial reporting from Mexican nonbank SDs as a component of its risk-bases methodology in setting the frequency and scope of its examinations of Mexican nonbank SDs. The Mexican Commission generally engages in examinations of broker-dealers, including Mexican nonbank SDs, as part of its general supervision and oversight program to assess firms' compliance with relevant laws and regulations.
The Mexican Commission also may impose fines against Mexican nonbank SDs for failing to comply with relevant Mexican laws and regulations. Fines may range from approximately $130,000 to $432,000 for failing to maintain sufficient regulatory capital in relation to the risks in the Mexican nonbank SD's operations.
In addition to imposing fines, the Mexican Commission also may order a Mexican nonbank SD that fails to comply with the applicable regulatory capital ratios, including the 2.5 percent common equity tier 1 capital buffer, to take corrective measures including the following:
Based on the above, the Commission preliminarily finds that the Mexican Commission has the necessary powers to supervise, investigate, and discipline entities for compliance with its capital, financial and reporting requirements, and to detect and deter violations of, and ensure compliance with, the applicable capital and financial reporting requirements in Mexico.
The Commission also has a history of regulatory cooperation with the Mexican Commission and would expect to communicate and consult with the Mexican Commission regarding the supervision of the financial and operational condition of the Mexican nonbank SDs. An appropriate MOU or similar arrangement with the Mexican Commission would facilitate cooperation and information sharing in the context of supervising the Mexican nonbank SDs.
The Commission invites comment on the Mexico Application, Mexican laws and regulations, and the Commission's analysis above regarding its preliminary determination that Mexican Commission and CFTC have supervision programs and enforcement authority that are comparable in that the purpose of the relevant programs and authority is to ensure that nonbank SDs maintain compliance with applicable capital and financial reporting requirements.
The Commission's preliminary view, based on the Mexico Application and the Commission's review of applicable Mexican laws and regulations, is that the Mexican Capital Rules and the Mexican Financial Reporting Rules, subject to the conditions set forth in the proposed Capital Comparability Determination Order below, achieve comparable outcomes and are comparable in purpose and effect to the CFTC Capital Rules and CFTC Financial Reporting Rules. In reaching this preliminary conclusion, the Commission recognizes that there are certain differences between the Mexican Capital Rules and CFTC Capital Rules and certain differences between the Mexican Financial Reporting Rules and the CFTC Financial Reporting Rules. The proposed Capital Comparability Determination Order is subject to proposed conditions that are preliminarily deemed necessary to promote consistency in regulatory outcomes, or to reflect the scope of substituted compliance that would be available notwithstanding certain differences. In the Commission's preliminary view, the differences between the two rule sets would not be inconsistent with providing a substituted compliance framework for Mexican nonbank SDs subject to the conditions specified in the proposed Order below.
Furthermore, the proposed Capital Comparability Determination Order is limited to the comparison of the Mexican Capital Rules to the Bank-Based Approach under the CFTC Capital Rules. As noted previously, the Applicants have not requested, and the Commission has not performed, a comparison of the Mexican Capital Rules to the Commission's NLA Approach or TNW Approach.
The Commission invites comments on all aspects of the Mexico Application, relevant Mexican laws and regulations, the Commission's preliminary views expressed above, the question of whether requirements under the Mexican Capital Rules are comparable in purpose and effect to the Commission's requirement for a nonbank SD to hold regulatory capital equal to or greater than 8 percent of its uncleared swap margin amount, and the Commission's proposed Capital Comparability Determination Order, including the proposed conditions included in the proposed Order, set forth below.
(1) The SD is not subject to regulation by a prudential regulator defined in Section 1a(39) of the CEA (7 U.S.C. 1a(39));
(2) The SD is organized under the laws of Mexico and is domiciled in Mexico (a “Mexican nonbank SD”);
(3) The Mexican nonbank SD is a licensed casa de bolsa (broker-dealer) with the Mexican Comision Nacional Bancaria y de Valores (Mexican Banking and Securities Commission) (the “Mexican Commission”);
(4) The Mexican nonbank SD is subject to and complies with: Articles 2, 113, 153, 172, 173, 228, 350, 358, and 392 of the Ley del Mercado de Valores (Securities Market Law) (referred to as “the Law”); Articles 5 and 19 of the Mexican Commission Law, the Supervision Regulations of the Mexican Commission; Articles 10, 137, 144, 146, 150 through 158 Bis, 159, 160, 161, 161 Bis through 161 Bis 5, 162, 162 Bis, 162 Bis 1, 163, 163 Bis, 169, 169 Bis, 175, 176, 179, 180, 201, 202, 203, 204 Bis 1, 204 Bis 2, 204 Bis 3, 204 Bis 7 through Bis 21, 214, 216, 217, Exhibits 5 and 9 of the Disposiciones de Caracter General Aplicables a las Casa De Bolsa (“General Provisions Applicable to Broker-Dealers”); Section C.B1 of Circular 115/2002, issued by the Mexican Central Bank; and Provision 3.1.3 of Rule 4/2012, issued by the Mexican Central Bank (collectively, the “Mexican Capital Rules” and “Mexican Financial Reporting Rules,” as applicable);
(5) The Mexican nonbank SD maintains at all times fundamental capital, as defined in Article 162 and Article 162 Bis of the General Provisions Applicable to Broker-Dealers, equal to or in excess of the equivalent of $20 million in United States dollars (“U.S. dollars”). The Mexican nonbank SD shall use a commercially reasonable and observed peso/U.S. dollar exchange rate to convert the value of the peso-denominated common equity tier 1 capital to U.S. dollars;
(6) The Mexican nonbank SD has filed with the Commission a notice stating its intention to comply with the applicable Mexican Capital Rules and Mexican Financial Reporting Rules in lieu of the CFTC Capital Rules and CFTC Financial Reporting Rules. The notice of intent must include the Mexican nonbank SD's representations that the firm is organized and domiciled in Mexico; is a licensed casa de bolsa with the Mexican Commission; and is subject to, and complies with, the Mexican Capital Rules and Mexican Financial Reporting Rules. The Mexican nonbank SD may not rely on this Capital Comparability Determination Order until it receives confirmation from Commission staff that it may comply with the applicable Mexican Capital Rules and Mexican Financial Reporting Rules in lieu of the CFTC Capital Rules and CFTC Financial Reporting Rules. Each notice filed pursuant to this condition must be prepared in the English language and submitted to the Commission via email to the following address:
(7) The Mexican nonbank SD shall provide notice to the Commission and National Futures Association (“NFA”) if at any time it initiates the process of seeking the approval of the Mexican Commission to use internal models to compute market risk and/or credit risk. The Mexican nonbank SD shall not use internal models to compute its
(8) The Mexican nonbank SD prepares and keeps current ledgers and other similar records in accordance with accounting principles required by the Mexican Commission;
(9) The Mexican nonbank SD files with the Commission and with NFA a copy of its quarterly financial report filed with the Mexican Commission pursuant to Article 203 of the General Provisions Applicable to Broker-Dealers and a copy of the monthly financial information, including the monthly balance sheet and income statement, filed with the Mexican Commission pursuant to Article 202 and Exhibit 9 of the General Provisions Applicable to Broker-Dealers. The Mexican nonbank SD must also include with the monthly information provided to the Commission and NFA a statement of regulatory capital as of each month end. The quarterly financial report and monthly financial information must be translated into the English language and balances must be converted to U.S. dollars. The quarterly financial report and monthly financial information must be filed with the Commission and NFA within 15 business days of the earlier of the date the quarterly financial report and monthly financial information are filed with the Mexican Commission or the date that the financial reports and financial information are required to be filed with the Mexican Commission;
(10) The Mexican nonbank SD files with the Commission and with NFA a copy of its audited annual financial report that is required to be filed with the Mexican Commission in accordance with Article 203 of the General Provisions Applicable to Broker-Dealers. The audited annual report must be translated into the English language. The audited annual report must be filed with the Commission and NFA within 15 business days of the earlier of the date the audited annual report is filed with the Mexican Commission or the date that the audited annual report is required to be filed with the Mexican Commission;
(11) The Mexican nonbank SD files Schedule 1 of Appendix B to Subpart E of Part 23 of the Commission's regulations (17 CFR part 23 Subpart E—Appendix B) with the Commission and NFA on a monthly basis. Schedule 1 must be prepared in the English language with balances reported in U.S. dollars and must be filed with the Commission and NFA together with the financial information set forth in condition (9);
(12) The Mexican nonbank SD must submit with the monthly financial information, the quarterly financial report, and the audited annual report required under conditions (9)-(11) of this Capital Comparability Determination Order a statement by an authorized representative or representatives of the Mexican nonbank SD that to the best knowledge and belief of the representative or representatives the information contained in the reports, including the translation of the reports into the English language and the conversion of balances into the reports to U.S. dollars (as applicable), is true and correct. The statement must be prepared in the English language;
(13) The Mexican nonbank SD files a margin report containing the information specified in Regulation 23.105(m) (17 CFR 23.105(m)) with the Commission and with NFA.
(14) The Mexican nonbank SD files a notice with the Commission and NFA within 24 hours of being informed by the Mexican Commission that the firm is not in compliance with any component of the Mexican Capital Rules or Mexican Financial Reporting Rules. The notice must be prepared in the English language;
(15) The Mexican nonbank SD files a notice with the Commission and NFA within 24 hours of when it knows that its regulatory capital is below 120 percent of the minimum capital requirement under the Mexican Capital Rules. The notice must be prepared in the English language;
(16) The Mexican nonbank SD files a notice with the Commission and NFA if it experiences a 30 percent or more decrease in its excess regulatory capital as compared to that last reported in the financial information filed with the Mexican Commission pursuant to Article 202 and Exhibit 9 of the General Provisions Applicable to Broker-Dealers. The notice must be prepared in the English language and filed within two business days of the firm experiencing the 30 percent or more decrease in excess regulatory capital;
(17) The Mexican nonbank SD files a notice with the Commission and NFA within 24 hours of when it knows or should have known that it has failed to make or keep current the books and records required by the Mexican Commission. The notice must be prepared in the English language;
(18) The Mexican nonbank SD files a notice with the Commission and NFA within 24 hours of the occurrence of any of the following: (i) a single counterparty, or group of counterparties under common ownership or control, fails to post required initial margin or pay required variation margin to the Mexican nonbank SD on uncleared swap and security-based swap positions that, in the aggregate, exceeds 25 percent of the Mexican nonbank SD's minimum capital requirement; (ii) counterparties fail to post required initial margin or pay required variation margin to the Mexican nonbank SD for uncleared swap and security-based swap positions that, in the aggregate, exceeds 50 percent of the Mexican nonbank SD's minimum capital requirement; (iii) a Mexican nonbank SD fails to post required initial margin or pay required variation margin for uncleared swap and security-based swap positions to a single counterparty or group of counterparties under common ownership and control that, in the aggregate, exceeds 25 percent of the Mexican nonbank SD's minimum capital requirement; and (iv) the Mexican nonbank SD fails to post required initial margin or pay required variation margin to counterparties for uncleared swap and security-based swap positions that, in the aggregate, exceeds 50 percent of the Mexican nonbank SD's minimum capital requirement. The notice must be prepared in the English language;
(19) The Mexican nonbank SD files a notice with the Commission and NFA of a change in its fiscal year end approved or permitted to go into effect by the Mexican Commission. The notice required by this condition will satisfy the requirement for a nonbank SD to obtain the approval of NFA for a change in fiscal year end under Regulation 23.105(g) (17 CFR 23.105(g)). The notice of change in fiscal year end must be prepared in the English language and filed with the Commission and NFA at least 15 business days prior to the effective date of the Mexican nonbank SD's change in fiscal year end;
(20) The Applicants notify the Commission of any material changes to the information submitted in their application, including, but not limited to, material changes to the Mexican Capital Rules or Mexican Financial Reporting Rules imposed on Mexican nonbank SDs, the Mexican Commission's supervisory authority or
(21) Unless otherwise noted in the conditions above, the reports, notices, and other statements required to be filed by Mexican nonbank SD with the Commission or NFA pursuant to the conditions of this Capital Comparability Determination Order must be submitted electronically to the Commission and NFA in accordance with instructions provided by the Commission or NFA.
The following appendices will not appear in the Code of Federal Regulations.
On this matter, Chairman Behnam and Commissioners Johnson, Goldsmith Romero, and Mersinger voted in the affirmative. Commissioner Pham voted to concur. No Commissioner voted in the negative.
Today the Commission will consider a proposed order and request for comment on an application for a capital comparability determination submitted on behalf of three nonbank
I support the Commission's proposed order and request for comment on its preliminary determination that the Mexican nonbank swap dealers organized and domiciled in Mexico are subject to, and comply with, capital and financial reporting requirements in Mexico that are comparable to certain capital and financial reporting requirements under the Commodity Exchange Act and the Commission's regulations (Capital Comparability Determination), subject to certain conditions set forth in the proposed order.
As CFTC provisionally-registered swap dealers operate and manage risk globally, the Commission's supervisory framework must acknowledge the realities of multi-jurisdictional operations. The Commission's approach to the proposed determination focuses on whether the Mexico Banking and Securities Commission's capital and financial reporting requirements achieve comparable outcomes to the corresponding CFTC requirements for nonbank swap dealers.
Throughout its analysis, the Commission has recognized that jurisdictions may adopt unique approaches to achieving comparable outcomes, and the Commission has focused on how the Mexican Banking and Securities Commission's capital and financial reporting requirements are comparable to its own in purpose and effect, rather than whether each are comparable in every particular aspect or contain identical elements. In this regard, the approach was not a line-by-line assessment or comparison of the Mexican Banking and Securities Commission's regulatory requirements with the Commission's requirements.
Consistent with the Commission's authority to issue a Capital Comparability Determination with terms and conditions it deems appropriate, today's proposed order contains 21 conditions. These conditions aim to ensure that the proposed order, if finalized, would only apply to Mexican nonbank swap dealers that are eligible for substituted compliance and that these Mexican nonbank swap dealers comply with the Mexican Banking and Securities Commission's capital and financial reporting requirements as well as certain additional capital, margin, position, financial reporting, recordkeeping, and regulatory notice requirements.
If the Commission, upon consideration of the comments received, determines to issue a favorable comparability determination, an eligible Mexican nonbank swap dealer would be required to file a notice of its intent to comply with the Mexican Banking and Securities Commission's capital adequacy and financial reporting rules in lieu of the Commission's requirements.
I believe it is important to note that today's proposed Capital Comparability Determination, if finalized, would not compromise the Commission's capital and financial reporting requirements. Instead, it recognizes the global nature of the swap markets with dually-registered swap dealers that operate in multiple jurisdictions that mandate prudent capital and financial reporting requirements. As I have said before, a capital and financial reporting comparability determination order of this kind is not a compromise or deference to a foreign regulatory authority. The Commission would retain its enforcement authority and examinations authority as well as obtain all financial and event specific reporting to maintain direct oversight of nonbank swap dealers located in Mexico.
I look forward to the public's submission of comments and feedback on this proposed determination and order.
Thank you to the hardworking staff in the Market Participants Division for all of their efforts to bring us here today, as well as the support of our colleagues in the Office of the General Counsel and the Office of International Affairs.
I support the Commission's issuance of the Notice of Proposed Order and Request for Comment (Notice of Proposed Order and Request for Comment) on the Application for the Capital Comparability Determination submitted on behalf of Nonbank Swap Dealers subject to Regulation by the Mexican Comisión Nacional Bancaria y de Valores (Mexican Banking and Securities Commission). The application of the nonbank swap dealers Morgan Stanley Mexico, Casa de Bolsa, S.A. de C.V.; Goldman Sachs Mexico, Casa de Bolsa, S.A. de C.V.; and Casa de Bolsa Finamex, S.A. de C.V. (Mexican nonbank swap dealers) domiciled in Mexico and subject to regulation by the Mexican Banking and Securities Commission seeking a capital comparability determination for Mexican nonbank swap dealers is the second proposed order and request for comment to come before the Commission since it adopted its substituted compliance framework for
Today, a little over a decade after the onset of the financial crisis precipitated by events in the bespoke, bilateral, over the counter swaps market, we continue to vigilantly monitor and surveil the risk management activities among market participants. Our efforts to coordinate and harmonize regulation with regulators around the world reinforces the adoption, implementation, and enforcement of sound prudential and capital requirements. These requirements aim to ensure the integrity of entities operating in these markets, to ensure rapid identification and remediation of liquidity crises, and to mitigate the threat of systemic risks that may threaten the stability of domestic and global financial markets.
Capital requirements play a critical role in fostering the safety and soundness of financial markets. As indicated in the Commodity Exchange Act, capital requirements protect market participants against concerning risks that threaten the integrity of individual market participants or potentially trigger a domino effect of cascading losses across financial markets.
Section 4s(e) of the CEA directs the Commission and “prudential regulators” to impose capital requirements on all swap dealers (“SDs”) and major swap participants (“MSPs”) registered with the Commission.
Under Section 4s(f), the Commission may adopt rules imposing financial condition reporting obligations on all SDs and MSPs. In accord with the same, the Commission has adopted financial reporting obligations.
I support acknowledging market participants' compliance with the regulations of foreign jurisdictions when the requirements lead to an outcome that is comparable to the outcome of complying with the CFTC's corresponding requirements. Substituted compliance must not, however, be confused with deference. To the contrary, the swap dealers that qualify for substituted compliance under regulation 23.106 must be Commission registrants. The Proposed Order, if approved, would ensure that relevant swap dealers domiciled in Mexico remain subject to the Commission's examination and enforcement authority over the firms.
Capital adequacy and financial reporting are pillars of risk management oversight for any business, and, for firms operating in our markets, it is of the utmost importance that rules governing these risk management tools are effectively calibrated, continuously assessed, and fit for purpose. The Commission's efforts in considering this proposal reflect careful and thoughtful evaluation of the comparability of relevant standards and an attempt to coordinate our efforts to bring transparency to the swaps market and reduce its risks to the public. I look forward to reviewing the comments that the Commission will receive in response to the Notice of Proposed Order and Request for Comment and, in particular, comments exploring proposed conditions.
Finally, I appreciate our colleagues in the Market Participants Division and their continuous collaboration with our fellow regulator—the Comisión Nacional de Bancaria y de Valores. I also want to thank my fellow Commissioners for their support in advancing this matter before the Commission. Successfully implementing comparability determinations requires collaboration between the CFTC and its partner regulators in other countries. The economies of the United States and Mexico are closely intertwined, and increased collaboration can only be beneficial in achieving our key goals of customer protection and market integrity.
I support the Commission considering efforts to safeguard the resilience of swap dealers, including through the proposed capital comparability determination for Mexico. The proposal recognizes that strong capital requirements are essential to ensure a swap dealer's safety and soundness, and that cross-border coordination with a like-minded regulator can promote financial stability. I commend the staff for their hard work on today's proposal—and thank them for working closely with me and my office on changes to improve the proposal.
One of the lessons learned from the 2008 financial crisis was the need to protect our markets from the serious risks posed by inadequate amounts of capital that could serve as a buffer against risk. Critical financial reforms introduced by the Dodd-Frank Act included minimum capital requirements for swap dealers. I note that two of the three swap dealers in Mexico that would be immediately subject to this proposed determination are affiliates of two of the largest recipients of Troubled Asset Relief Program dollars.
Dodd-Frank Act reforms led to the CFTC establishing capital requirements for nonbank swap dealers, implementing rules to keep our markets safe. Requiring firms to maintain a strong amount of high-quality capital helps to ensure their resilience—their ability to meet their financial commitments, and continue to perform their critical market making function, even when faced with stress events in the market, unexpected losses or decreases in the value of their assets. This lowers the risk in the financial system, and helps to ensure financial stability.
Our capital rules are a critical pillar of the Dodd-Frank Act's reforms. Therefore, we must ensure that our comparability assessments are sound and do not increase risk to U.S. markets.
The global nature of the 2008 financial crisis also highlighted the need for the CFTC to coordinate with foreign regulators, as swap activities in a foreign jurisdiction may have an impact in the United States. This is particularly relevant here as two of the three existing swap dealers are affiliates of large U.S. financial institutions.
Today's proposal is only the second substituted compliance determination to be considered for the CFTC's capital rules, following our proposal in July related to swap dealers in Japan. Therefore, we should proceed carefully, as what we do will establish precedent.
Substituted compliance is not an all-or-nothing proposition. The Commission can impose any terms or conditions that it deems appropriate, and can continue to require direct compliance with certain of the CFTC's rules. That is what we are proposing to do here in certain areas.
For example, I strongly support the proposed condition for Mexican nonbank swap dealers to comply with the CFTC's $20 million minimum capital requirement—just as we proposed to require for nonbank swap dealers in Japan. This is one of the most critical components of the CFTC's capital requirements. It helps to ensure that each nonbank swap dealer maintains, at all times, a fixed amount of the highest quality capital to meet its financial obligations without becoming insolvent. The minimum capital requirement recognizes the significant role that swap dealers play in our markets—with extensive connections to other swap counterparties and to each other—and helps ensure their resilience.
Even with substituted compliance, the CFTC must ensure that we receive—both on a periodic, and event-driven, basis—the information necessary to identify, evaluate and address situations that may have an adverse impact on firms or financial markets. That is why I support the conditions in the proposal that would require a nonbank swap dealer in Mexico to notify the Commission of undercapitalization and other events that may indicate financial or operational issues. I look forward to public comment on whether allowing Mexican nonbank swap dealers to submit financial reports that are required to be prepared under Mexico's rules will ensure that the Commission has access to the information needed to effectively monitor the
The CFTC has a duty to ensure that our comparability assessment is sound and that the foreign regulator is like-minded, not only in their rules but in their supervision, oversight, and enforcement. Therefore, a strong regulatory relationship with the Mexican Banking and Securities Commission (Comision Nacional Bancaria y de Valores) (“CNBV”) and regular continued coordination is important. I highlight, and express my appreciation for, the CNBV's engagement with our staff. Continued engagement will enhance our ability to work together swiftly and effectively to address any significant market stress events or other circumstances that may threaten a firm's safety and soundness.
It is a priority for me to ensure that the CFTC guards against complacency with post-crisis reforms, particularly after market stresses from the pandemic and geopolitical events. Our capital rules serve as critical pillars of Dodd-Frank Act reforms to help ensure the safety and resilience of the markets and market participants from serious risks and contagion. Substituted compliance must leave U.S. markets and our economy at no greater risk than full compliance with our rules.
I respectfully concur with the notice of proposed order and request for comment on an application for a capital comparability determination submitted on behalf of nonbank swap dealers subject to regulation by the Mexican Comision Nacional Bancaria y de Valores (CNBV).
Today's proposed order and request for comment on a comparability determination for three nonbank swap dealers by Mexican CNBV marks yet another important step for cross-border harmonization. It is worth reiterating the progress that the world has made since the 2008 financial crisis in implementing this, among other, G20 global derivatives reforms.
The proposed determination and order would permit, subject to several proposed conditions, CFTC registered nonbank swap dealers domiciled in Mexico to satisfy certain Commission swap dealer capital and financial reporting requirements via substituted compliance with certain capital and financial reporting requirements established by the Mexican Banking and Securities Commission (“Mexican Commission”). CFTC staff met with Mexican CNBV staff on several occasions to discuss the application process and capital and financial reporting requirements.
One of my guiding principles throughout my career, both as a regulator and in the private sector, is that markets work best when there are clear and simple rules with common standards. Ensuring that these rules are harmonized minimizes operational complexity that can otherwise increase risks and costs. Without an approach that appropriately recognizes the home country regulations, trading and clearing becomes more complex and therefore costlier and less efficient for all market participants. Through the hard work of CFTC staff, today's order takes a step in mitigating these potential negative effects on the global and U.S. markets. I am also pleased that the proposed order recognizes that Mexico has implemented rules that are consistent with the Basel Committee for Banking Supervision Framework for International Bank Based Capital Standards. We must continue to appropriately adhere to international standards, because our markets are global and we are not regulating in a vacuum.
I continue to believe that the CFTC should take an outcomes-based approach to substituted compliance, one that strikes a balance of both recognizing the nature of cross-border regulation of global markets and that preserves access for U.S. persons to other markets.
There's just one small example that I wanted to mention. Specifically, I'm unsure as to how an entity can file a notice within 24 hours of when it “should have known” about a books and records issue. When you are designing an escalation and self-reporting process and have to start the clock ticking, either you have identified an issue or you have not. There is a specific time, and then the deadline is 24 hours later. I am not sure how you count 24 hours from “should have known” because there is no specific time from which to start the clock ticking. Perhaps we mean “knows or reasonably suspects” there is an issue. That is one of the reasons I am concurring in today's proposal.
Nonetheless, I appreciate the careful consideration by the staff and the Commission of how to take a practical approach to achieving appropriate oversight and mitigation of risk to the United States and the markets. I urge a pragmatic approach with sufficient time to implement conditions before any compliance date, and I appreciate the thought that the staff have been putting into that.