Animal and Plant Health Inspection Service
Food and Nutrition Service
Foreign-Trade Zones Board
Industry and Security Bureau
National Oceanic and Atmospheric Administration
Federal Energy Regulatory Commission
Western Area Power Administration
Centers for Disease Control and Prevention
Centers for Medicare & Medicaid Services
National Institutes of Health
Transportation Security Administration
U.S. Citizenship and Immigration Services
Bureau of Safety and Environmental Enforcement
Indian Affairs Bureau
National Park Service
Federal Aviation Administration
Federal Motor Carrier Safety Administration
Maritime Administration
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.
Food and Nutrition Service (FNS), USDA.
Final rule.
The Department of Agriculture (USDA) is adopting the interim final rule on non-discretionary quality control provisions of Title IV of the Agricultural Improvement Act of 2018, and its correction, as final. In this final rule, USDA is also removing one obsolete paragraph from the interim final rule due to the Office of Management and Budget's (OMB) subsequent approval of information collection activities associated with the rule.
Effective April 18, 2023.
John McCleskey, 703-457-7747, Food and Nutrition Service, 1320 Braddock Place, 5th Floor; Alexandria, Virginia 22314,
The Department published an interim final rule on August 13, 2021, which addressed non-discretionary quality control (QC) provisions of Title IV of the Agricultural Improvement Act of 2018 (86 FR 44575). This rule became effective August 13, 2021. USDA also published a correction to that interim final rule on September 2, 2021 (86 FR 49229). The interim final rule established requirements on the use and Federal oversight of third-party contractors for the Supplemental Nutrition Assistance Program's (SNAP) QC system in State agencies; Federal QC reviewer access to State eligibility computer systems containing SNAP household information; the use of FNS' existing management evaluation process to annually review at least two State agency QC systems for integrity purposes; and inclusion of SNAP cases originally processed by the Social Security Administration in the annual review of QC cases. The rule also clarified which QC records must be kept for QC recordkeeping purposes, that QC cases must be final when submitted to FNS for Federal review, and that the OMB-approved FNS 380 QC form and all of its supporting documentation must be submitted to FNS upon completion of the State's case review.
The interim final rule also included 7 CFR 275.2(c)(4) because the rule included information-collection activities that required revision of existing OMB-approved collections. Per the interim final rulemaking, paragraph (c)(4) states that compliance with paragraph (c)(1) will not be required until paragraph (c)(4) is removed or contains a compliance date, after review of such requirements by OMB pursuant to the Paperwork Reduction Act (PRA). On July 29, 2022, OMB concluded its review of and approved the PRA requirements for the two affected collections requiring revision, OMB 0584-0074—Worksheet for the Supplemental Nutrition Assistance Program's Quality Control Reviews and OMB 0584-0303—Supplemental Nutrition Assistance Program Regulations, Part 275—Quality Control.
One comment on the interim final rule was received, sharing the commenter's general thoughts about SNAP's integrity; however, the comment was not germane to the interim final rule. No other comments were received by the November 1, 2021, comment date.
As such, USDA is adopting the interim final rule and its correction as final. In doing so, USDA is also removing 7 CFR 275.2(c)(4) from the rule due to OMB's approval of information collection activities included in 7 CFR 275.2(c)(1).
This action also affirms the information contained in the interim final rule concerning Executive Orders 12866 and the Regulatory Flexibility Act, Executive Orders 13563, 13175, and 12988.
Grant programs—social programs, Reporting and recordkeeping requirements.
Accordingly, the interim rule amending 7 CFR part 275, published August 13, 2021, at 86 FR 44575, and corrected September 2, 2021, at 86 FR 49229, is adopted as final with the following changes:
7 U.S.C. 2011-2036.
Federal Housing Finance Agency.
Final rule.
The Federal Housing Finance Agency (FHFA) is adopting as final, without change, a proposed rule that amends its Enterprise Duty to Serve Underserved Markets regulation to add a definition of “colonia census tract,” to serve as a census tract-based proxy for a “colonia.” The final rule also amends the definition of “high-needs rural region” in the regulation by substituting “colonia census tract” for “colonia.” In addition, the final rule revises the definition of “rural area” in the regulation to include all colonia census tracts regardless of their location. These changes will make certain activities by the Federal National Mortgage Association (Fannie Mae) and the
The final rule is effective July 1, 2023.
Ted Wartell, Associate Director, Office of Housing and Community Investment, 202-649-3157,
The Federal Housing Enterprises Financial Safety and Soundness Act of 1992 (Safety and Soundness Act) provides generally that the Enterprises “have an affirmative obligation to facilitate the financing of affordable housing for low- and moderate-income families.”
FHFA's current Duty to Serve regulation implements these statutory requirements.
FHFA has identified two main challenges that have hindered the Enterprises' Duty to Serve activities in colonias. The first challenge is an operational one that has prevented the Enterprises from easily identifying and verifying Duty to Serve-eligible loan purchases and outreach activities in colonias. The identification of a colonia under the existing Duty to Service regulation's definition relies on the identification of the community as a colonia using federal, State, tribal, or local definitions. These definitions are based on varied criteria and boundaries. Some rely on descriptive terms that may be meaningful only at the local level, such as neighborhood names, and are generally not tied to any standard geographic identifiers used by lenders such as census tracts. There is no specific, uniform definition of “colonia” that can be easily operationalized and included in a public database that the Enterprises and lenders can check to determine if a particular loan is located in an eligible colonia. As a result, the Enterprises and lenders must engage in a time-consuming and labor-intensive process that is susceptible to error to determine whether a particular loan falls within the specified boundary of a colonia that meets the definition.
In light of these challenges, Fannie Mae engaged a nonprofit organization with research capacities, the Housing Assistance Council (HAC), to conduct research and analysis in an effort to develop a nationwide, usable and programmatic methodology that would enable accurate targeting and tracking of loans in these communities. As part of this research, HAC mapped federal, State, tribal, and local definitions of colonia to census tracts.
The second challenge is related to the ability of the Duty to Serve program to effectively target eligible households in colonias due to the under-inclusion of colonias in the Duty to Serve regulation's existing “rural area” definition. Under the Duty to Serve regulation, an Enterprise is eligible to receive Duty to Serve credit for activities supporting colonias if the activities (
To address these challenges, FHFA published a Notice of Proposed Rulemaking (NPRM or proposed rule) in the
•
•
•
The public comment period on the proposed rule ended on December 5, 2022.
FHFA received 10 comments in response to the proposed rule. Comments were submitted by Fannie Mae, Freddie Mac, four nonprofit organizations, two policy advocacy organizations, and two individuals. FHFA has reviewed and considered all of the comments. The comments received and FHFA's responses are summarized by topic in the sections below.
A majority of the commenters supported the proposal to add a definition of “colonia census tract” to mean a census tract containing a colonia, which will serve as a proxy for the colonia. Both Enterprises, the four nonprofit organizations, and the two policy advocacy organizations stated that the proposal would improve and enhance the ability of the Enterprises to meet the credit needs of these high-poverty areas. Several of the commenters stated that the current regulation's definition of “colonia” does not fully reflect or encompass the evolving geographies and characteristics of colonias. Commenters stated that the proposed use of “colonia census tracts” as a proxy for colonias would result in a clear, functional, usable, and flexible methodology for identifying and verifying Duty to Serve-eligibility criteria, which would enhance stakeholder certainty with respect to targeting loan purchases and outreach to colonia census tracts.
Commenters stated that the proposed amendments would structurally incentivize the Enterprises to do more for hundreds of communities along the United States-Mexico border and greater southwest, and thereby help to increase liquidity in these underserved communities. Many of the commenters also suggested that the proposed use of colonia census tracts could “create a beneficial ripple effect” if replicated by other federal agencies that have colonia-focused programs. For example, three of the nonprofit organizations projected that widespread implementation of the proposal “would result in the real possibility of economically integrating colonia communities to their surrounding economies, supercharging efforts to address decades of disparities.” One of the policy advocacy organizations also predicted that adoption of the proposal by other federal agencies “could further comprehensive community development efforts to the benefit of all in those communities.”
In response to FHFA's Question 1 about the advantages and disadvantages of using colonia census tracts instead of colonias for purposes of identifying and verifying Duty to Serve-eligible activities, three nonprofits and the two policy advocacy organizations highlighted the advantages of, as well as their own experiences with, using colonia census tracts. The three nonprofit organizations stressed that the main advantage in using colonia census tracts is that it achieves stability in the methodology while maintaining flexibility to adapt to evolving geographies. Some commenters also stated that federal efforts to define colonias geographically have historically failed due to the evolving nature and characteristics of colonias, especially since the passage of the North American Free Trade Agreement (NAFTA) in 1994. The commenters noted that shifting geographic footprints, a lack of understanding as to what constitutes a colonia, and deference to contradictory parameters at the state level have all contributed to the failures to define colonias. As a result, the commenters stated that the Enterprises have lacked clear guidance on what counts as Duty to Serve-eligible activities in colonias, rendering any potential efforts to hone best practices in serving these unique communities unworkable. These commenters also emphasized the ease of obtaining, as well as the accuracy of using, colonia census tracts as opposed to the existing Duty to Serve definition of colonia. The commenters also provided examples of how they have successfully used colonia census tracts to target and direct resources to colonias, even when those colonias are surrounded by mixed-income non-colonia communities.
In response to FHFA's Question 2 on whether there are other ways to identify the geographic areas in which the Enterprises should receive Duty to Serve credit for eligible activities addressing colonias, one policy advocacy organization, HAC, noted that it had conducted extensive research and analysis in an effort to develop a nation-wide, usable and programmatic methodology that would enable accurate targeting and tracking of loans in colonias. The commenter stated that it found that other approaches have serious disadvantages when compared to the use of a census tract-based methodology. As a result, the commenter stated that its research, which it described as carefully considered, rigorous, and thoroughly reviewed by experts, concluded that the use of a census tract-based methodology would best enable mortgage lenders and other financial service providers to target and serve colonia communities more efficiently and effectively.
An individual commenter stated that while the proposed amendments would require that the Enterprises serve colonia census tracts, they would not hold the Enterprises accountable for serving colonias themselves, which the commenter further stated could undermine FHFA's rationale for proposing the amendments. Another individual commenter stated that the matters covered by the proposed rule reside with the Department of Housing and Urban Development, not FHFA and the Enterprises, and that the goal for FHFA should be conserving and preserving to put the Enterprises on stronger footing, not mandating more risk or serving the interests of specific administrations or FHFA Directors.
FHFA has considered the comments received on the use of colonia census tracts and continues to be persuaded that adding a definition of “colonia census tract” to serve as a census tract-based proxy for a “colonia” will enhance the ability of the Enterprises to meet the credit needs of these high-poverty areas. A census tract-based approach will also align FHFA's treatment of colonias under the Duty to Serve regulation with other census tract-based standards for Enterprise reporting to FHFA. For example, FHFA collects data at the census tract level to assess compliance with other Duty to Serve requirements and the Enterprise Housing Goals. Specifically, census tracts serve as the basis for identifying other geographically based underserved areas, including low-income areas and area median income to determine
Regarding the commenter's concern about holding the Enterprises accountable for serving colonias themselves, FHFA will encourage the Enterprises to work with local entities that specifically serve colonias to increase access to credit in these areas. Regarding the comment on FHFA's and the Enterprises' role in this area, FHFA clearly identified and described in the NPRM its statutory authority for regulating the Enterprises' Duty to Serve responsibilities and activities. These Duty to Serve responsibilities of each Enterprise include developing and executing a Plan describing the specific activities and objectives it will undertake to fulfill its Duty to Serve in each underserved market over a three-year period. In addition, FHFA issues Evaluation Guidance that describes procedures for preparing the Plans and the standards FHFA has established for evaluating and rating Enterprise compliance with the Plans, as well as the impact on each of the underserved markets.
A majority of the commenters also supported the proposal to revise the Duty to Serve regulation's definition of “high-needs rural region” to include colonia census tracts, and to revise the Duty to Serve regulation's definition of “rural area” to include all colonia census tracts, regardless of their location within or outside an MSA, due to the inherently rural nature and characteristics of all colonia census tracts. In response to FHFA's Question 3 about any advantages and disadvantages associated with revising the Duty to Serve “rural area” definition to incorporate all census tracts that contain a colonia regardless of their location, the nonprofit organizations and the policy advocacy organizations pointed out that a colonia's proximity to an MSA does not guarantee that it has access to public utilities and transportation infrastructure. The commenters stated that colonias embody a rural existence because they are often cut off from municipal services and denied integration into the surrounding economy as local governments have chosen not to incorporate them. For these reasons, the commenters described the proposal to include all colonia census tracts, regardless of their location, in the definition of “rural area” as a “commonsense measure” capable of further incentivizing the Enterprises to meet their Duty to Serve obligations. The commenters also highlighted as another benefit associated with revising the “rural area” definition that it would streamline the process of identifying Duty to Serve-eligible loans.
An individual commenter, while acknowledging that colonias are vastly underserved regions with similar characteristics to rural areas regardless of their location, stated that treating all colonia census tracts as rural, regardless of whether they are located within or outside an MSA, would differ from the regulation's use of an MSA-based standard for the other high-needs rural regions, which could lead to confusion and difficulty in implementing the proposed amendments.
A policy advocacy organization recommended that the regulation provide greater, or weighted, Duty to Serve credit for Enterprise activities in colonia census tracts located in rural areas as the latter term is defined in the current regulation, on the basis that the needs in such rural colonia census tracts are even greater than those in urban colonia census tracts. As an alternative, the commenter suggested that FHFA base the weighting differential on poverty rates rather than location, with greater Duty to Serve credit given to Enterprise activities in the highest poverty tracts.
After considering the comments, FHFA remains persuaded that the proposed amendments to revise the definitions of “high-needs rural region” and “rural area” to include all colonia census tracts, regardless of their location, is appropriate. While FHFA appreciates the recommendation that greater weight be given to Enterprise activities in colonia census tracts located in rural areas as currently defined in the regulation, the final rule does not adopt this suggestion. The NPRM described a number of challenges the Enterprises have encountered over the years in targeting colonias, including operational challenges that have prevented them from easily identifying and verifying Duty to Serve-eligible loan purchases and outreach activities in colonias. Another challenge the Enterprises have faced is their inability to effectively target eligible households in colonias due to the under-inclusion of colonias in the current Duty to Serve regulation's “rural area” definition. Placing greater weight on Enterprise activities in certain colonia census tracts would introduce a layer of complexity that may detract from the stated objective of the proposed amendments—to facilitate the Enterprises' ability to operationalize their Duty to Serve activities and thereby help increase liquidity in these underserved communities.
Regarding the comment about the proposal not relying on an MSA-based standard for colonia census tracts as is used for the other high-needs rural regions, FHFA notes that the rationale for departing from this standard was addressed in the NPRM. The NPRM stated that an analysis of 2020 census data found that only 260 of the 577 census tracts that contain colonias meet the current Duty to Serve “rural area” definition.
Therefore, FHFA believes that it is appropriate to amend the definitions of “high-needs rural region” and “rural area” in § 1282.1(b) to include all colonia census tracts regardless of their location. Accordingly, the final rule amends the definition of “high-needs rural region” by substituting “colonia census tract” for “colonia,” and revises the second component of the “rural area” definition (par. (ii)) to include colonia census tracts that would not otherwise satisfy the “rural area” definition.
The NPRM discusses how FHFA currently publishes and regularly updates on its website a Rural Areas Data file that specifies the census tracts in the other high-needs rural regions where Enterprise activities are eligible for Duty to Serve credit.
In the NPRM, FHFA stated that it would periodically update the colonia census tracts included in FHFA's Rural Areas Data file, for use by the Enterprises and other interested parties.
FHFA agrees that more frequent updates to the colonia census tracts included in the Rural Areas Data file may be necessary during the 10-year period after census tract boundaries are updated. The NPRM described FHFA's plan to periodically update the colonia census tracts in the file, by which FHFA meant on an “as needed” basis.
Both Enterprises provided recommendations on when the final rule should take effect. Fannie Mae expressed concern that if the final rule were to become effective some time after January 1, 2023, the Enterprises would have administrative challenges with applying two different definitions of “high-needs rural region” and “rural area” in 2023, as the current regulation's definitions would continue to apply until the final rule's new definitions became effective. Accordingly, Fannie Mae recommended that the final rule be effective on January 1, 2023. Although Freddie Mac did not recommend a specific effective date for the final rule, it requested a three-month implementation period to update its reporting platform.
FHFA has decided to make the final rule's effective date July 1, 2023, the beginning of the third calendar quarter of 2023. FHFA acknowledges that the Enterprises may encounter administrative challenges associated with applying two different definitions of “high-needs rural region” and “rural area” in 2023. However, as Freddie Mac commented, FHFA recognizes that the Enterprises will need time to prepare for their implementation of the final rule. An effective date of July 1, 2023 will give the Enterprises time after publication of the final rule to notify lenders and other stakeholders of the rule's amendments, adjust their marketing strategies and other outreach activities as necessary, and update their reporting platforms to be able to accurately report on loan purchases and other activities in colonia census tracts. In addition, because the Enterprises report to FHFA on their Duty to Serve performance on a quarterly basis, establishing the effective date as the beginning of the third calendar quarter will avoid their having to report based on two different definitions within the same calendar quarter.
The Regulatory Flexibility Act (5 U.S.C. 601
The Paperwork Reduction Act (PRA) (44 U.S.C. 3501
In accordance with the Congressional Review Act (5 U.S.C. 801
Mortgages; Reporting and recordkeeping requirements.
For the reasons stated in the preamble, under the authority of 12 U.S.C. 4501, 4502, 4511, 4513, 4526, and 4561-4566, FHFA amends part 1282 of subchapter E of 12 CFR chapter XII, as follows:
12 U.S.C. 4501, 4502, 4511, 4513, 4526, 4561-4566.
The addition and revision read as follows:
(i) A census tract outside of a metropolitan statistical area as designated by the Office of Management and Budget; or
(ii) A census tract in a metropolitan statistical area as designated by the Office of Management and Budget that is:
(A) Outside of the metropolitan statistical area's Urbanized Areas as designated by the U.S. Department of Agriculture's (USDA) Rural-Urban Commuting Area (RUCA) Code #1, and outside of tracts with a housing density of over 64 housing units per square mile for USDA's RUCA Code #2; or
(B) A colonia census tract that does not satisfy paragraphs (i) or (ii)(A) of this definition.
Federal Aviation Administration (FAA), DOT.
Final rule.
This action amends Very High Frequency (VHF) Omnidirectional Range (VOR) Federal Airways V-51, V-115, V-243, V-267, V-311, V-333, and V-415; and removes V-463 in support of the FAA's VOR Minimum Operational Network (MON) Program.
Effective date 0901 UTC, June 15, 2023. The Director of the Federal Register approves this incorporation by reference action under 1 CFR part 51, subject to the annual revision of FAA Order JO 7400.11 and publication of conforming amendments.
A copy of the Notice of Proposed Rulemaking (NPRM), all comments received, this final rule, and all background material may be viewed online at
FAA Order JO 7400.11G, Airspace Designations and Reporting Points, and subsequent amendments can be viewed online at
Paul Gallant, Rules and Regulations Group, Office of Policy, Federal Aviation Administration, 800 Independence Avenue SW, Washington, DC 20591; telephone: (202) 267-8783.
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 the 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 modifies the route structure as necessary to preserve the safe and efficient flow of air traffic within the National Airspace System (NAS).
The FAA published a notice of proposed rulemaking for Docket No. FAA-2023-0061 in the
An anonymous commenter wrote expressing strong support of the push for satellite navigation, but stated they did not agree with the removal of victor airways in the Chicago area. The only airway in this rule that approaches the Chicago area is V-51 which ends at Chicago Heights, IL. That segment of V-51 is not being removed, and it remains available for navigation.
Domestic VOR Federal airways are published in paragraph 6010(a) of FAA Order JO 7400.11, Airspace Designations and Reporting Points, which is incorporated by reference in 14 CFR 71.1 on an annual basis. This document amends the current version of that order, 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
FAA Order JO 7400.11G lists Class A, B, C, D, and E airspace areas, air traffic service routes, and reporting points.
This action amends 14 CFR part 71 by modifying VOR Federal Airways V-51, V-115, V-243, V-267, V-311, V-333, and V-415; and revoking V-463 in support of the FAA's VOR MON Program. This program aims to improve the efficiency of the NAS by transitioning from ground-based navigation systems to satellite based navigation. The changes are described as follows:
Full descriptions of the above amended routes are listed in the amendments to part 71 set forth below. Where new radials are used in a route description, the preamble includes both True and Magnetic degrees. However, only True degrees are stated in the regulatory text.
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. It, therefore: (1) is not a “significant regulatory action” under Executive Order 12866; (2) is not a “significant rule” under Department of Transportation (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 only affects air traffic procedures and air navigation, it is certified that this rule, when promulgated, does not have a significant economic impact on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.
The FAA determined that this action qualifies for categorical exclusion under the National Environmental Policy Act in accordance with FAA Order 1050.1F, “Environmental Impacts: Policies and Procedures,” paragraph 5-6.5.a., and 5-6.5.b. This airspace action is not expected to cause any potentially significant environmental impacts, and no extraordinary circumstances exist that warrant preparation of an environmental assessment.
Airspace, Incorporation by reference, Navigation (air).
In consideration of the foregoing, the Federal Aviation Administration amends 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.
From Pahokee, FL; INT Pahokee 010°and Treasure, FL, 193° radials; Treasure; INT Treasure 330° and Ormond Beach, FL, 183° radials; Ormond Beach; to Craig, FL. From Hinch Mountain, TN; Livingston, TN; to Louisville, KY. From Shelbyville, IN; INT Shelbyville 313° and Boiler, IN, 136° radials; Boiler; to Chicago Heights, IL.
From Crestview, FL; INT Crestview 001° and Montgomery, AL, 204° radials; Montgomery; INT Montgomery 323° and Vulcan, AL, 177° radials; Vulcan; to INT Vulcan 048° and Gadsden, AL 333° radials. From INT Hinch Mountain, TN, 160° and Volunteer, TN, 228° radials; to Volunteer. From Charleston, WV; to Parkersburg, WV.
From Craig, FL; Waycross, GA; Vienna, GA; LaGrange, GA; to INT LaGrange 342° and Gadsden, AL, 124° radials.
From Orlando, FL; Craig, FL; Dublin, GA; Athens, GA; to INT Athens 340° and Rome, GA, 077° radials.
From Hinch Mountain, TN; INT Hinch Mountain 160° and Electric City, SC, 274° radials; to Electric City.
From INT Rome, GA, 133° and Gadsden, AL, 091° radials to Rome. From Hinch Mountain, TN; to Lexington, KY.
From Montgomery, AL, to INT Montgomery 029°and Gadsden, AL, 124° radials. From INT Rome 060° and Foothills, SC, 258° radials; Foothills; Spartanburg, SC; to INT Spartanburg 101° and Charlotte, NC, 229° radials.
Federal Aviation Administration (FAA), DOT.
Final rule; correction.
A final rule was published in the
Effective 0901 UTC, June 15, 2023. The Director of the Federal Register approves this incorporation by reference action under 1 CFR part 51, subject to the annual revision of FAA Order JO 7400.11 and publication of conforming amendments.
Jennifer Ledford, Operations Support Group, Eastern Service Center, Federal Aviation Administration, 1701 Columbia Ave., College Park, GA 30337; Telephone (404) 305-5649.
The FAA published a final rule in the
Class D and Class E airspace designations are published in Paragraphs 5000, 6002, and 6005 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 D and E airspace designations listed in this document will subsequently be published in FAA Order JO 7400.11G.
This action amends (14 CFR) part 71 by replacing the reference to the Class D airspace in the Class E surface airspace description at Middle Georgia Regional Airport with reference to Class E airspace.
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. 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 minimal. Since this is a routine matter that only affects air traffic procedures and air navigation, it is certified that this rule, when promulgated, does not have a significant economic impact on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.
The FAA has determined that this action qualifies for categorical exclusion under the National Environmental Policy Act in accordance with FAA Order 1050.1F, “Environmental Impacts: Policies and Procedures,” paragraph 5-6.5a. This airspace action is not expected to cause any potentially significant environmental impacts, and no extraordinary circumstances warrant the preparation of an environmental assessment.
Airspace, Incorporation by reference, Navigation (air).
Accordingly, pursuant to the authority delegated to me, the amendment of Class E surface airspace for Middle Georgia Regional Airport, Macon, GA, in Docket No. FAA-2022-1614, as published in the
That airspace extending upward from the surface within a 4.9-mile radius of Middle Georgia Regional Airport, excluding the portion within the 5.5-mile radius of Robins AFB Airport that lies south of a line connecting the two points of intersection of the 5.5-mile radius circle centered on the Robins AFB Airport and the 4.1-mile radius of Middle Georgia Regional 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.
Federal Aviation Administration (FAA), DOT.
Final rule.
This action modifies the Class E airspace extending upward from 700 feet above the surface at Torrington Municipal Airport, WY by reducing the Class E airspace encircling the airport, removing the northwest extension and eastern procedure turn area, and adding a southeast extension. These modifications support the safety and management of instrument flight rules (IFR) operations at the airport.
Effective 0901 UTC, June 15, 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 and publication of conforming amendments.
A copy of the Notice of Proposed Rulemaking (NPRM), all comments received, this final rule, and all background material may be viewed online at
FAA Order JO 7400.11G, Airspace Designations and Reporting Points, and
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'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 the 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 modifies the Class E airspace at Torrington Municipal Airport, Torrington, WY, to support IFR operations at the airport.
The FAA published a notice of proposed rulemaking for Docket No. FAA-2022-1562 in the
The Class E5 airspace designation is published in paragraph 6005 of FAA Order JO 7400.11, Airspace Designations and Reporting Points, which is incorporated by reference in 14 CFR 71.1 on an annual basis. This document amends the current version of that order, 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
FAA Order JO 7400.11G lists Class A, B, C, D, and E airspace areas, air traffic service routes, and reporting points.
This action amends 14 CFR part 71 by modifying the Class E airspace beginning at 700 feet above the surface at Torrington Municipal Airport, WY. The current Class E airspace encircling the airport with a 7.7-mile radius is excessive. 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. The Class E airspace encircling the airport is reduced to a 7.5-mile radius which sufficiently contains departing IFR operations until they reach 1,200 feet above the surface.
The existing Class E airspace beginning at 700 feet above the surface contains an area east of the airport intended for procedure turn maneuvers that is no longer needed and is removed. Class E airspace beginning at 700 feet above the surface is designed to accommodate arriving IFR operations below 1,500 feet above the surface. No terrain penetrates to within 1,500 feet of arriving aircraft conducting a procedure turn, and the procedure is fully contained in the existing Denver Class E domestic en route airspace.
The existing extension to the northwest is removed as it is no longer needed. The Class E airspace beginning at 700 feet above the surface that encircles the airport within a 7.5-mile radius is sufficient to contain arriving IFR operations below 1,500 feet above the surface from northwest of the airport.
An extension is added to the Class E airspace beginning at 700 feet above the surface that is 2.8 miles wide extending 9.6 miles southeast of the airport to accommodate arriving IFR operations below 1,500 feet above the surface.
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. 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 only affects air traffic procedures and air navigation, it is certified that this rule, when promulgated, does not have a significant economic impact on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.
The FAA has determined that this action qualifies for categorical exclusion under the National Environmental Policy Act in accordance with FAA Order 1050.1F, “Environmental Impacts: Policies and Procedures,” paragraph 5-6.5.a. This airspace action is not expected to cause any potentially significant environmental impacts, and no extraordinary circumstances exist that warrant preparation of an environmental assessment.
Airspace, Incorporation by reference, Navigation (air).
In consideration of the foregoing, the Federal Aviation Administration amends 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 700 feet above the surface within a 7.5-mile radius of the airport, and that airspace 1.4 miles each side of the 116° bearing extending from the 7.5-mile radius to 9.6 miles southeast of the airport.
Federal Aviation Administration (FAA), DOT.
Final rule.
This action amends Class E airspace extending upward from 700 feet above the surface for Maine Coast Memorial Heliport, Ellsworth, Maine; Maine General Medical Center/Augusta Heliport, Augusta, Maine; and Maine General Medical Center-Waterville Heliport, Waterville, Maine as instrument approach procedures have been designed for each heliport.
Effective 0901 UTC, June 15, 2023. The Director of the Federal Register approves this incorporation by reference action under 1 CFR part 51, subject to the annual revision of FAA Order JO 7400.11 and publication of conforming amendments.
A copy of the notice of proposed rulemaking (NPRM), all comments received, this final rule, and all background material may be viewed online at
FAA Order JO 7400.11G, Airspace Designations and Reporting Points, and subsequent amendments can be viewed online at
John Fornito, Operations Support Group, Eastern Service Center, Federal Aviation Administration, 1701 Columbia Avenue, College Park, GA 30337; Telephone: (404) 305-6364.
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 establishes airspace in Ellsworth, Augusta, and Waterville, ME, to support instrument flight rules (IFR) operations in the area.
The FAA published a notice of proposed rulemaking for Docket No. FAA-2023-0099 in the
Class E airspace designations are published in paragraph 6005 of FAA Order JO 7400.11, Airspace Designations and Reporting Points, which is incorporated by reference in 14 CFR 71.1 on an annual basis. This document amends the current version of that order, 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
FAA Order JO 7400.11G lists Class A, B, C, D, and E airspace areas, air traffic service routes, and reporting points.
This action amends 14 CFR part 71 by establishing a 6-mile radius of Class E airspace extending upward from 700 feet above the surface for Maine Coast Memorial Heliport, Ellsworth, Maine; Maine General Medical Center/Augusta Heliport, Augusta, Maine; and Maine General Medical Center-Waterville Heliport, Waterville, Maine as instrument approach procedures have been designed for each heliport. Controlled airspace is necessary for the safety and management of IFR operations in the area.
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. 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 minimal. Since this is a routine matter that only affects air traffic procedures and air navigation, it is certified that this rule, when promulgated, does not have a significant economic impact on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.
The FAA has determined that this action qualifies for categorical exclusion under the National Environmental Policy Act in accordance with FAA Order 1050.1F, “Environmental Impacts: Policies and Procedures,” paragraph 5-6.5a.
This airspace action is not expected to cause any potentially significant environmental impacts, and no extraordinary circumstances exist that warrant the preparation of an environmental assessment.
Airspace, Incorporation by reference, Navigation (air).
In consideration of the foregoing, the Federal Aviation Administration amends 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 700 feet above the surface within a 6.0-mile radius of the point in space coordinates for Maine Coast Memorial Heliport.
That airspace extending upward from 700 feet above the surface within a 6.0-mile radius of the point in space coordinates for Maine General Medical Center/Augusta Heliport.
That airspace extending upward from 700 feet above the surface within a 6.0-mile radius of the point in space coordinates for Maine General Medical Center-Waterville Heliport.
Bureau of Safety and Environmental Enforcement, Interior.
Final rule.
The Bureau of Safety and Environmental Enforcement (BSEE) issues this final rule to clarify and formalize its regulations related to decommissioning responsibilities of Outer Continental Shelf (OCS) oil, gas, and sulfur lessees and grant holders to ensure compliance with lease, grant, and regulatory obligations. This rule implements provisions of the proposed rule intended to clarify decommissioning responsibilities of right-of-use and easement (RUE) grant holders and to formalize BSEE's policies regarding performance by predecessors ordered to decommission OCS facilities. This rule withdraws the proposal to amend BSEE's regulations to require BSEE to proceed in reverse chronological order against predecessor lessees, owners of operating rights, and grant holders when requiring such entities to perform their accrued decommissioning obligations if the current lessees, owners, or holders have failed to perform.
This rule is effective May 18, 2023.
Kirk Malstrom, BSEE, at
On October 16, 2020, the Bureau of Ocean Energy Management (BOEM) and BSEE published a proposed rule entitled “Risk Management, Financial Assurance and Loss Prevention.” (85 FR 65904). In this final rule, the Department of the Interior (Department or DOI) implements certain proposed revisions to regulations administered by BSEE. BOEM intends to issue a new proposed rule for the provisions within its regulatory purview.
The BSEE-administered portion of the proposed rule would have established that BSEE could only proceed in reverse chronological order against predecessor lessees, owners of operating rights, and grant holders when requiring them to perform their accrued decommissioning obligations if the current lessees, owners, or holders failed to perform. The BSEE-administered provisions also proposed to clarify decommissioning responsibilities for RUE grant holders, promulgate as regulations BSEE policy surrounding the obligations of predecessors when ordered to decommission, and require that any party appealing and seeking to stay a final decommissioning order post a surety bond.
This final rule focuses on clarifying decommissioning obligations of RUE grant holders and promulgating as regulations BSEE policy regarding the obligations of predecessors ordered to perform decommissioning. BSEE has decided to withdraw its proposal that would have established the reverse chronological order constraint on BSEE's pursuit of predecessor lessees, owners of operating rights, and grant holders for performance of their accrued decommissioning obligations. BSEE has also chosen not to finalize the proposed appeal bonding requirements.
To ease the reading of this preamble and for reference purposes, the following acronyms and abbreviations are used in the preamble:
BSEE derives its authority primarily from the OCS Lands Act (OCSLA), which authorizes the Secretary of the Interior (Secretary) to regulate oil and gas exploration, development, and production operations on the OCS. Secretary's Order 3299 delegated authority to perform certain of these regulatory functions to BSEE. To carry out its responsibilities, BSEE regulates offshore oil and gas operations to enhance the safety of exploration for and development of oil and gas on the OCS, and to ensure that those operations protect the environment, conserve the natural resources of the OCS, and implement advancements in technology. BSEE's regulatory program covers a wide range of facilities and activities, including decommissioning requirements, which are the primary focus of this rulemaking. Detailed information concerning BSEE's regulations and guidance to the offshore oil and gas industry may be found on BSEE's website at:
For a comprehensive discussion of the proposed rule provisions, please refer to the notice of proposed rulemaking published in the
BSEE may issue an order to predecessors to perform accrued decommissioning obligations if subsequent assignees have failed to perform them. In the proposed rule, BSEE proposed to require such predecessors to take certain actions following receipt of an order to perform, including:
(1) Beginning maintenance and monitoring within 30 days,
(2) Designating an operator for decommissioning within 60 days, and
(3) Submitting a decommissioning plan within 90 days.
Multiple commenters asserted that the proposed 30/60/90-day timeframes for taking those actions were too short. In this final rule, BSEE is moving the provisions to § 250.1708(a), retaining the 30-day timeframe for beginning maintenance and monitoring, and extending the timeframes for compliance with the other two requirements as follows:
(1) Designate an operator (or agent) for the decommissioning activities within 90 days of receiving the order; and
(2) Submit a decommissioning plan to BSEE within 150 days of receiving the order.
These revised timeframes provide clarity and consistency and allow sufficient time to implement the decommissioning process expeditiously and effectively.
In the proposed rule, BSEE proposed to require a party that files an appeal of a BSEE decommissioning order and seeks to obtain a stay of that order during the appeal to post a surety bond in an amount adequate to ensure completion of the decommissioning activities. Multiple commenters asserted that such a surety bond is not necessary in light of other existing and adequate financial assurance requirements designed to secure decommissioning obligations. BSEE agrees with these commenters and is not finalizing the proposed appeal bond provisions in § 250.1709 and 30 CFR 290.7.
The proposed rule would have limited BSEE's ability to issue decommissioning orders by requiring BSEE to issue the orders to predecessors through an RCO process,
The proposed rule would have added references to the predecessors of various interest holders in the definitions of “you” and “I” applicable to the regulations in part 250 subpart Q. A commenter noted that these revisions should be applicable only to the regulations regarding the accrued decommissioning obligations of predecessors. BSEE has rephrased the definitions in this final rule to better reflect this intended outcome.
The Bureaus divided the comments received on the proposed rule into separate BOEM and BSEE dockets. In this section, BSEE addresses comments received on its proposals, beginning with an overview of comments and then proceeding to comments by section number.
In response to the proposed rule, BOEM and BSEE received approximately 36 unique sets of comments from various entities, including individual companies, industry organizations, non-governmental organizations, and private citizens. Of those 36 commenters, 21 submitted comments on the BSEE-administered provisions. Some entities submitted comments on both BOEM and BSEE provisions. All relevant comments are posted at the Federal e-Rulemaking portal:
Other commenters expressed general opposition to the proposed rule and many of its key provisions. For example, one non-governmental organization suggested that BOEM and BSEE should “withdraw” the proposed rule. For a discussion of the substantive comments in opposition to specific provisions and BSEE's responses, refer to later parts of this section.
(1) Begin maintaining and monitoring within 30 days of receiving the order (as proposed);
(2) Designate the operator or agent for the decommissioning activities within 90 days of receiving the order (as opposed to 60 days in proposed rule); and
(3) Submit a decommissioning plan to BSEE within 150 days of receiving the order (as opposed to 90 days in proposed rule).
BSEE also retains discretion to extend or shorten these timeframes under extenuating circumstances to effectively implement the decommissioning process.
While these commenters broadly appreciated the RCO approach, they expressed divergent views as to how BSEE should issue decommissioning orders when current interest holders fail to perform their obligations. Some commenters urged BSEE to issue orders to the immediate predecessor of any defaulting party before engaging joint owners or co-lessees among the current set of interest holders. Other commenters expressed concern that BSEE would not use all available options to address decommissioning obligations with current interest holders before turning to predecessors.
The commenter also asserted that the proposed rule would result in a mismatch between BOEM's proposal to “base obligations on the financial strength of the strongest co-lessee” and BSEE's proposal to “place primary decommissioning responsibilities on the most recent and likely financially weakest co-lessee.” The overall effect would be to “shift the financial burden for decommissioning from large firms to smaller firms that have less ability to cover decommissioning costs,” the commenter said.
BSEE also disagrees that this rule diminishes BSEE's authority to enforce joint and several liability. This rule does not undermine any aspect of the joint and several liability regime. The commenter was primarily concerned with the proposed RCO requirements,
This section of the current regulations defines certain terms used throughout part 250 and clarifies their meaning as used in certain subparts or sections, as applicable.
BSEE proposed to amend § 250.105 by removing the terms and definitions for “Easement” and “Right-of-use” and replacing them with a new term and definition for “Right-of-Use and Easement (RUE).” The revision would make BSEE's regulations consistent with BOEM's regulations. The proposed amendment would clearly define an RUE grant as an authorization to use a portion of the seabed not encompassed by the holder's lease to construct, modify, or maintain platforms, artificial islands, facilities, installations, and other devices established to support the exploration, development, or production of oil and gas, mineral, or energy resources on the OCS or a State submerged lands lease.
BSEE considered the submitted comments and has included a slightly revised definition in the final rule. The revised definition adds after the word “construct,” “secure to the seafloor,
This section of the current regulations defines certain terms used throughout the decommissioning regulations in part 250 subpart Q.
BSEE proposed to revise the section heading to include the term “predecessor” and to revise paragraph (a)(2) to include the area of an RUE grant among the areas that, through decommissioning, must be returned to a condition that meets the requirements of BSEE and other applicable agencies. This revision aligns with the other proposed revisions to the decommissioning obligations associated with RUE grants. BSEE also proposed to add a new paragraph (d) defining the term “predecessor” to mean a prior lessee, operating rights owner, or RUE or ROW grant holder that is liable for accrued obligations on that lease or grant. This definition is designed to clarify which entities, including assignors, remain liable for the decommissioning obligations that accrued during their prior ownership of an interest in a lease or grant for purposes of the proposed provisions establishing BSEE's modified approach toward enforcement of such obligations.
BSEE considered the comments submitted on the proposed section and has included the proposed revisions in the final rule without any substantive changes.
This section of the current regulations identifies who is responsible and liable for decommissioning obligations.
BSEE proposed to add new paragraph (c) to this section and redesignate the existing paragraph (c) as paragraph (d). The new paragraph (c) would clarify that all holders of an RUE grant are jointly and severally liable, along with other liable parties, for meeting decommissioning obligations on their RUE, including those pertaining to a well, pipeline, platform, or other facility, or an obstruction, as the obligations accrue and until each obligation is met. BSEE also proposed to revise the current definition of “you” in existing paragraph (c) (redesignated as paragraph (d) under the proposed rule) to include RUE grant holders and predecessors-in-interest among the parties categorized as “you” or “I” for purposes of the part 250 subpart Q decommissioning regulations. These revisions were designed to ensure alignment between § 250.1701 and the other proposed revisions to subpart Q.
BSEE considered the comments submitted on this proposed section and has included the proposed revisions in the final rule with two minor changes. First, BSEE clarifies in new paragraph (c) that prior owners of operating rights who accrued decommissioning obligations for facilities or obstructions that remain on an RUE grant are still jointly and severally liable until those obligation are met. This revision provides consistency with paragraphs (a) and (b). Second, as discussed above in section III of this preamble, in response to public comment, BSEE has modified the incorporation of predecessors into the definitions of “you” and “I” to attach only “as appropriate in the context of the particular regulation.”
This section of the current regulations identifies certain operations or actions by which decommissioning obligations accrue.
BSEE proposed to revise paragraph (e) to clarify that all holders of a pipeline ROW grant would accrue the obligation to decommission. BSEE also proposed to redesignate paragraph (f) as paragraph (g) and add a new paragraph (f). Under the proposed paragraph (f), an entity would accrue decommissioning obligations when it is or becomes the holder of an RUE grant on which there is a well, pipeline, platform, other facility, or an obstruction. These proposed changes were designed to implement the RUE decommissioning principles discussed in the preamble to the proposed rule and to reflect BSEE practice related to multiple ROW grant holders.
BSEE considered the comments submitted on the proposed section and has included the proposed revisions in the final rule with a minor revision in paragraph (e) to add the word “grant” after “right-of-way” to ensure the proper term is utilized correctly.
This section of the current regulations identifies certain steps or actions that must be taken when a facility is no longer useful for operations.
BSEE proposed to revise paragraph (e) to clarify that an RUE grant holder must clear the seafloor of all facilities and obstructions created by its RUE grant operations. This revision was designed to ensure alignment between § 250.1703 and the other proposed revisions to subpart Q, including the RUE decommissioning principles discussed in the preamble to the proposed rule.
BSEE considered the comments submitted on the proposed section and has included the proposed revisions in the final rule with a minor correction of a typographical error by replacing the proposed rule's reference to “right-way” with the appropriate and intended “right-of-way.”
This section of the current regulations requires submittal of specified decommissioning applications and reports. This section also identifies the required timeframes to submit the applicable documents to BSEE and includes additional instructions.
BSEE proposed to add a new paragraph (b) in the table to provide that predecessors-in-interest who receive decommissioning orders under proposed § 250.1708 must submit a decommissioning plan for BSEE approval within 90 days of receiving the order. The proposed § 250.1708 would require that the decommissioning plan include a scope of work and schedule to address wells, pipelines, and platforms. This proposed revision reflects the changes in proposed § 250.1708, regarding decommissioning plans, discussed below.
After consideration of the comments received on this proposed section and as explained in the responses to comments in section III of this preamble, BSEE is extending the timeframe in paragraph (b) for order recipients to submit their decommissioning plan from 90 to 150 days. These changes are necessary to reflect corresponding edits to § 250.1708(a). BSEE is also changing the word “upon” in the first column of the proposed paragraph (b) to the word “after,” as a grammatical correction, and updating internal regulatory cross-
As provided for in the proposed rule, this new section explains how BSEE will issue decommissioning orders to predecessors-in-interest for accrued decommissioning obligations. Additionally, this section clarifies the actions predecessors must take once an order is issued.
BSEE proposed to add a new § 250.1708 (in place of the currently reserved § 250.1708). Under proposed paragraph (a) of this section, BSEE would issue decommissioning orders to predecessor lessees and other interest holders in reverse chronological order through the chain-of-title when holding such predecessors responsible for accrued decommissioning obligations. Also under proposed paragraph (a), BSEE would issue such orders to groups of predecessors organized according to changes in the designated operator over time, as well as to any predecessor who assigned interests to a party that has defaulted.
Proposed paragraph (b) would require recipients of such predecessor-in-interest orders to identify a single entity to begin maintaining and monitoring any facility identified in the order within 30 days of receiving it. It would also require recipients to designate a single entity as the operator for decommissioning operations within 60 days of receiving the order. Further, it would require recipients to submit a decommissioning plan within 90 days of receiving the order that included the scope of work and schedule for site clearance of all facilities, pipelines, and obstructions identified in the order. Finally, proposed paragraph (b) would require recipients to perform the required decommissioning in the time and manner specified by BSEE in its decommissioning plan approval.
Proposed paragraph (c) would specify that failure by a predecessor-in-interest to comply with an order to maintain and monitor a facility and to submit a decommissioning plan may result in various enforcement actions, including civil penalties and disqualification as an operator.
Proposed paragraph (d) would allow BSEE to depart from the RCO sequence and to issue orders to any or all predecessors-in-interest to perform their respective accrued decommissioning obligations when:
(1) None of the predecessors who had been ordered to perform obtained approval of a decommissioning plan or performed decommissioning according to an approved decommissioning plan;
(2) The regional supervisor determined that there was an emergency condition, safety concern, or environmental threat, such as improperly maintained and monitored facilities, leaking wells or vessels, sustained casing pressure on wells, or lack of required valve testing; or
(3) The regional supervisor determined that applying the RCO sequence would unreasonably delay decommissioning.
Proposed paragraph (e) would clarify that BSEE's issuance of decommissioning orders to additional predecessors-in-interest does not relieve any current lessee or grant holder, or any other predecessor, of its obligations to comply with any prior decommissioning order or to satisfy its accrued decommissioning obligations.
Proposed paragraph (f) would provide that the appeal of any decommissioning order did not prevent BSEE from proceeding against other predecessors under proposed paragraph (d).
BSEE considered comments on the proposed revisions and has modified § 250.1708 of the final rule as discussed here and above in section III. BSEE discarded proposed paragraphs (a) and (d) because it is not proceeding with the proposed RCO process. Proposed paragraphs (b) and (c) are now paragraphs (a) and (b) respectively in the final rule with minor revisions. Proposed paragraphs (e) and (f) are redesignated as paragraphs (c) and (d) respectively in the final rule.
BSEE is revising paragraph § 250.1708(a) in the final rule by adding “unless otherwise specified in the order” to acknowledge its authority under existing regulations to order performance on timelines other than those established in paragraphs (a)(1) through (a)(3), when warranted by the circumstances.
(2) Designate the operator or agent for the decommissioning activities within 90 days of receiving the order; and
(3) Submit a decommissioning plan to BSEE within 150 days of receiving the order.
This section of the current regulations identifies the timeframes and certain required actions when removing platforms and facilities.
BSEE proposed to expand the first sentence of paragraph (a) to provide that an RUE grant holder must remove all platforms and other facilities within 1 year after the RUE grant terminates unless the grant holder receives approval to maintain the structure to conduct other activities. This proposed revision was designed to ensure alignment between § 250.1725 and the other proposed revisions to part 250 Subpart Q regarding the RUE decommissioning principles discussed in the preamble to the proposed rule.
BSEE has considered the comments submitted on the relevant topics of the proposed section, and BSEE has included the proposed language in the final rule without change.
E.O. 12866 provides that the Office of Information and Regulatory Affairs (OIRA) in the Office of Management and Budget (OMB) will review all significant rules. OIRA has reviewed this final rule and determined that, with the limited scope of proposed changes being finalized, it is no longer a significant action under E.O. 12866.
E.O. 13563 reaffirms the principles of E.O. 12866 while calling for improvements in the Nation's regulatory system to promote predictability, reduce uncertainty, and use the best, most innovative, and least burdensome tools for achieving regulatory ends. The E.O. directs agencies to consider regulatory approaches that reduce burdens and maintain flexibility and freedom of choice for the public where these approaches are relevant, feasible, and consistent with regulatory objectives. E.O. 13563 emphasizes that regulations must be based on the best available science and that the rulemaking process must allow for public participation and an open exchange of ideas. BSEE has developed this rule in a manner consistent with these requirements.
The Regulatory Flexibility Act (RFA), 5 U.S.C. 601-612, requires agencies to analyze the economic impact of regulations when there is likely to be a significant economic impact on a
BSEE completed a final regulatory flexibility analysis to assess the impact of this final rule on small entities. BSEE concludes its changes will not result in any incremental change to the existing burdens on small entities. This final rule merely clarifies and aligns current regulations regarding accrual of decommissioning liability with current policy and practice. The final rule provides clarity and transparency regarding the manner in which BSEE enforces those existing liabilities. Impacts on individual predecessors-in-interest that BSEE may approach in any particular circumstances are highly case-dependent and too uncertain to evaluate at a general level. Regardless, the final rule largely leaves existing regulation and BSEE practice unchanged.
BSEE did not receive any public comments on the IRFA, or that addressed impacts on small businesses.
In response to public comments on other issues, BSEE discarded its proposals to enforce accrued decommissioning obligations against predecessor lessees, owners of operating rights, or grant holders in RCO following default by the current lessees, owners, or interest holders. BSEE also discarded its proposal to require any party appealing and seeking to stay a final decommissioning order to post a surety bond. Accordingly, any potential impacts on small entities arising from these proposed revisions will not be realized.
This final rule focuses on clarifying the decommissioning responsibilities of RUE grant holders and formalizing BSEE's practices associated with decommissioning orders to predecessors-in-interest. BSEE is making its procedures for enforcing decommissioning compliance more transparent. This will provide the affected companies with greater certainty regarding when they may be approached and how they will be expected to comply with BSEE's decommissioning orders. BSEE considers these changes to be a regulatory codification of long-standing practice. As a result, BSEE concludes that all companies—large or small—operating on the OCS will not face an increased burden over the current baseline of regulatory requirements and current practice.
The RFA defines a small entity as either a small business, a small not-for-profit organization, or a small governmental jurisdiction. BSEE determined that the final rule will not impact small not-for-profit organizations or small government jurisdictions. Thus this analysis focuses on impacts to small businesses.
The final rule will affect OCS lessees and RUE and pipeline ROW grant holders. BSEE adopts and incorporates the relevant analysis from BOEM's IRFA analysis. BOEM estimated that 455 companies have ownership interests in OCS leases and grants. The definition of small business varies from industry to industry to reflect industry size differences. Companies that will operate under this final rule are classified primarily under North American Industry Classification System (NAICS) codes 211120 (“Crude Petroleum Extraction”), 211130 (“Natural Gas Extraction”), and 486110 (“Pipeline Transportation of Crude Oil and Natural Gas”). For NAICS classifications 211120 and 211130, the Small Business Administration defines a small business as one with fewer than 1,250 employees; for NAICS code 486110, as one with fewer than 1,500 employees. Based on this criterion, approximately 319 (70 percent) of the companies subject to this final rule met the definition of a small business. All these small businesses are potentially impacted by this rule. Therefore, BSEE expects that the final rule will affect a substantial number of small entities.
BSEE notes that small businesses that acquire interests in OCS leases and grants do so with full knowledge of the joint and several liability regulatory framework. This framework binds them to a decommissioning obligation until it is met, even when that obligation might be contingent upon an assignee's default. This final rule clarifies and aligns BSEE's regulatory framework governing liability and decommissioning obligation with its current policy and practice. Therefore, BSEE believes the additional cost of this final rule is zero for all affected companies, including small businesses, because the rule reinforces the current baseline. For these reasons, BSEE believes the final rule is unlikely to significantly affect small businesses.
This rule will clarify and add transparency to existing requirements. The changes will not have any negative impact on the economy or any economic sector, productivity, jobs, the environment, or other units of government. The changes codified in the final rule clarify interested parties' decommissioning liabilities for facilities on RUE grants and provide predecessors-in-interest with explicit decommissioning compliance expectations. Accordingly, this rule is not a major rule under 5 U.S.C. 804(2) of the Congressional Review Act because implementation of this rule will not:
(a) Have an annual effect on the economy of $100 million or more;
(b) Result in a major increase in costs or prices for consumers, individual industries, Federal, State, or local government agencies, or geographic regions; or
(c) Result in significant adverse effects on competition, employment, investment, productivity, innovation, or on the ability of U.S.-based enterprises to compete with foreign-based enterprises in domestic and export markets.
This rule does not impose an unfunded mandate on State, local, or Tribal governments, or the private sector of more than $189 million per year.
This final rule does not effect a taking of private property or otherwise have takings implications under E.O. 12630. Therefore, a takings implication assessment is not required.
Under the criteria in section 1 of E.O. 13132, this rule does not have sufficient
This rule complies with the requirements of E.O. 12988. Specifically, this rule:
(a) Meets the criteria of section 3(a) requiring that all regulations be reviewed to eliminate errors and ambiguity and be written to minimize litigation; and
(b) Meets the criteria of section 3(b)(2) requiring that all regulations be written in clear language and contain clear legal standards.
BSEE strives to strengthen its government-to-government relationships with American Indian and Alaska Native Tribes through a commitment to consultation with the Tribes and recognition of their right to self-governance and Tribal sovereignty. We are also respectful of our responsibilities for consultation with Alaska Native Claims Settlement Act (ANCSA) Corporations. We have evaluated the rule under the Department's consultation policy, under Departmental Manual part 512 chapters 4 and 5, and under the criteria in E.O. 13175 and determined that there are no substantial direct effects on Tribes.
This final rule contains a collection of information that we have submitted to OMB for review and approval under the Paperwork Reduction Act of 1995 (44 U.S.C. 3501
The proposed rule was published in the
This final rule will add new collections of information under 30 CFR part 250 Subpart Q related to the decommissioning of oil, gas, and sulfur infrastructure on the OCS. These regulatory requirements are the subject of this information collection request.
We use the information collected under Subpart Q to ensure that OCS operations are carried out in a safe and environmentally protective manner, do not interfere with the rights of other OCS users, and balance the conservation and development of OCS resources. The following regulatory changes will affect the annual burden hours; however, they will not impact non-hour cost burdens.
The final rule will formalize and make explicit BSEE practice and expectations surrounding enforcement of accrued decommissioning obligations against predecessors-in-interest following failure to perform by current lessees, operating rights holders, and grantees.
After consideration of the public comments and as explained in section III of this preamble, BSEE is extending the timeframe for submitting decommissioning plans in new § 250.1708(a) from 90 to 150 days. The final rule will require all predecessors-in-interest who receive a decommissioning order to submit a work plan and schedule as directed under §§ 250.1704(b) and 250.1708(a). BSEE considers this necessary to protect the public from incurring future decommissioning costs and to prevent safety and environmental risks posed by delayed decommissioning. Within 150 days of receiving a decommissioning order under § 250.1708, the recipients must submit a work plan and schedule that addresses all wells, platforms, other facilities, pipelines, and site clearance. This requirement will add an estimated 4,320 annual burden hours to the existing OMB control number (+4,320 annual burden hours).
After consideration of the public comments and as explained in section III of this preamble, BSEE is discarding its proposal to require any party appealing and seeking a stay of a decommission order to post a surety bond.
A detailed environmental analysis under NEPA is not required if a rule is covered by a categorical exclusion (see 43 CFR 46.205). This rule meets the criteria set forth at 43 CFR 46.210(i) for a Departmental categorical exclusion because this rule is “of an administrative, financial, legal, technical, or procedural nature.” We have also determined that the rule does not implicate any of the extraordinary circumstances listed in 43 CFR 46.215 that would require further analysis under NEPA.
In developing this rule, we did not conduct or use a study, experiment, or survey requiring peer review under the Data Quality Act (Pub. L. 106-554, app. C, sec. 515, 114 Stat. 2763, 2763A-153-154).
Under E.O. 13211, agencies are required to prepare and submit to OMB a statement of energy effects for “significant energy actions.” This statement should include details of any adverse effects on energy supply, distribution, or use (including a shortfall in supply, price increases, and increased use of foreign supplies) expected to result from the action and a discussion of reasonable alternatives and their effects.
The rule does not add new regulatory compliance requirements that lead to adverse effects on the Nation's energy supply, distribution, or use. The rule is not expected to affect the cost of energy. The provision regarding decommissioning responsibility for facilities on RUE grants does not increase the cost borne by industry but could share the financial burden and responsibility among applicable parties in a manner consistent with current regulatory and industry practice. Moreover, because BSEE's regulatory changes apply only after activities (
BSEE is required by E.O. 12866, E.O. 12988, and Presidential memorandum of June 1, 1998, to write all rules in plain language. This means that each rule BSEE publishes must:
(1) Be logically organized;
(2) Use the active voice to address readers directly;
(3) Use clear language rather than jargon;
(4) Be divided into short sections and sentences; and
(5) Use lists and tables wherever possible.
BSEE has drafted this rule in compliance with these requirements.
Administrative practice and procedure, Continental shelf, Environmental impact statements, Environmental protection, Federal lands, Government contracts, Investigations, Mineral resources, Oil and gas exploration, Outer continental shelf, Penalties, Pipelines, Rights-of-way, Reporting and recordkeeping requirements, Sulfur.
For the reasons stated in the preamble, BSEE amends 30 CFR part 250 as follows:
30 U.S.C. 1751; 31 U.S.C. 9701; 33 U.S.C. 1321(j)(1)(C); 43 U.S.C. 1334.
(a) * * *
(2) Returning the lease, pipeline right-of-way, or the area of a right-of-use and easement to a condition that meets the requirements of BSEE and other agencies that have jurisdiction over decommissioning activities.
(d)
(a) Lessees, owners of operating rights, and their predecessors are jointly and severally liable for meeting decommissioning obligations for facilities on leases, including the obligations related to lease-term pipelines, as the obligations accrue and until each obligation is met.
(b) All holders of a right-of-way grant and their predecessors are jointly and severally liable for meeting decommissioning obligations for facilities on their right-of-way, including right-of-way pipelines, as the obligations accrue and until each obligation is met.
(c) All right-of-use and easement grant holders and prior lessees or owners of operating rights of the parcel on whose leases there existed facilities or obstructions that remain on the right-of-use and easement grant are jointly and severally liable for meeting decommissioning obligations, including obligations for any well, pipeline, platform or other facility, or an obstruction, on their right-of-use and easement, as the obligations accrue and until each obligation is met.
(d) In this subpart, the terms “you” or “I” refer to lessees and owners of operating rights as to facilities installed under the authority of a lease; to pipeline right-of-way grant holders as to facilities installed under the authority of a pipeline right-of-way grant; and to right-of-use and easement grant holders as to facilities constructed, modified, or maintained under the authority of the right-of-use and easement grant. Predecessors to any of these interest holders are also included within the scope of these terms as appropriate in the context of the particular regulation.
(e) Are or become a holder of a pipeline right-of-way grant on which there is a pipeline, platform, other facility, or an obstruction;
(f) Are or become the holder of a right-of-use and easement grant on which there is a well, pipeline, platform, other facility, or an obstruction; or
(e) Clear the seafloor of all obstructions created by your lease, pipeline right-of-way, or right-of-use and easement operations;
(a) When BSEE issues an order to predecessors to perform accrued decommissioning obligations, the order recipients must, unless otherwise specified in the order:
(1) Within 30 days of receiving the order, begin maintaining and monitoring, through a single entity identified to BSEE, any facility, including wells and pipelines, as identified by BSEE in the order and in accordance with applicable requirements under this part (including, but not limited to, testing safety valves and sensors, draining vessels, and performing pollution inspections);
(2) Within 90 days of receiving the order, designate a single entity to serve as operator or agent for the decommissioning operations;
(3) Within 150 days of receiving the order, submit through the entity identified in paragraph (a)(2) of this section a decommissioning plan for approval by the Regional Supervisor that includes the scope of work and a reasonable decommissioning schedule for all wells, platforms and other facilities, pipelines, and site clearance, as identified in the order; and
(4) Perform the required decommissioning in the time and manner specified by BSEE in its decommissioning plan approval.
(b) Failure to comply with the obligations under paragraph (a) of this section to maintain and monitor a facility or to submit a decommissioning plan may result in a Notice of Incident of Noncompliance and potentially other enforcement actions, including civil penalties and disqualification as an operator.
(c) BSEE's issuance of orders to any predecessors will not relieve any current lessee or grant holder, or any other predecessor, of its obligations to comply with any prior decommissioning order or to satisfy any accrued decommissioning obligations.
(d) A pending appeal, pursuant to 30 CFR part 290, of any decommissioning order does not preclude BSEE from proceeding against any or all predecessors other than the appellant.
(a) You must remove all platforms and other facilities within 1 year after the lease, pipeline right-of-way, or right-of-use and easement terminates, unless you receive approval to maintain the structure to conduct other activities. * * *
Federal Communications Commission
Final rule; announcement of effective date.
In this document, the Federal Communications Commission (Commission) announces that the Office of Management and Budget (OMB) has approved, for a period of three years, the information collections adopted in Report and Order in MB Docket No. 20-74, FCC 21-21,
The amendments to 47 CFR 73.6010, 73.6023, and 74.720, published at 86 FR 21217 on April 22, 2021, are effective May 18, 2023.
Kevin Harding, Media Bureau, Video Division, at (202) 418-1600 or
This document announces that OMB approved the information collection requirements in 47 CFR 73.6010, 73.6023, and 74.720, on April 7, 2023. These rules were modified in the Report and Order in MB Docket No. 20-74, FCC 21-21,
As required by the Paperwork Reduction Act of 1995 (44 U.S.C. 3507), the FCC is notifying the public that it received final OMB approval on April 7, 2023, for the information collection requirements contained in 47 CFR 73.6023, 73.6010, and 74.720. Under 5 CFR part 1320, an agency may not conduct or sponsor a collection of information unless it displays a current, valid OMB Control Number.
No person shall be subject to any penalty for failing to comply with a collection of information subject to the Paperwork Reduction Act that does not display a current, valid OMB Control Number. The OMB Control Numbers for the information collection requirements in these rules are 3060-0016, 3060-0017, 3060-0928 and 3060-0932.
The foregoing notice is required by the Paperwork Reduction Act of 1995, Public Law 104-13, October 1, 1995, and 44 U.S.C. 3507.
The total annual reporting burdens and costs for the respondents are as follows:
Federal Aviation Administration (FAA), DOT.
Notice of proposed rulemaking (NPRM).
The FAA proposes to supersede Airworthiness Directive (AD) 2021-26-11, which applies to all Rolls-Royce Deutschland Ltd. & Co. KG (RRD) Model RB211-Trent 875-17, 877-17, 884-17, 884B-17, 892-17, 892B-17, and 895-17 engines. AD 2021-26-11 requires replacing the affected fuel pump on at least one affected engine. Since the FAA issued AD 2021-26-11, the FAA has determined that replacing all affected fuel pumps on all installed engines is necessary to address the unsafe condition. This proposed AD would require replacing the affected fuel pump on at least one engine before further flight and replacing all affected fuel pumps within a specified compliance time, and would also prohibit installing any affected engine onto any airplane or any affected fuel pump onto any engine, 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 NPRM by June 2, 2023.
You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:
•
•
•
•
• For EASA service information that is proposed for IBR in this NPRM, contact EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; phone: +49 221 8999 000; email:
• You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 1200 District Avenue, Burlington, MA 01803. For information on the availability of this material at the FAA, call (817) 222-5110.
Sungmo Cho, Aviation Safety Engineer, ECO Branch, FAA, 1200 District Avenue, Burlington, MA 01803; phone: (781) 238-7241; 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 Sungmo Cho, Aviation Safety Engineer, ECO Branch, FAA, 1200 District Avenue, Burlington, MA 01803. 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 2021-26-11, Amendment 39-21870 (86 FR 71367, December 16, 2021) (AD 2021-26-11), for all RRD Model RB211-Trent 875-17, 877-17, 884-17, 884B-17, 892-17, 892B-17, and 895-17 engines. AD 2021-26-11 was prompted by an MCAI originated by EASA, which is the Technical Agent for the Member States of the European Union. EASA issued EASA AD 2021-0245, dated November 10, 2021 (EASA AD 2021-0245), to correct an unsafe condition identified as failure of the variable stator vane system.
AD 2021-26-11 requires replacing the affected fuel pump on at least one engine. The FAA issued AD 2021-26-11 to prevent failure of the variable stator
Since the FAA issued AD 2021-26-11, EASA superseded EASA AD 2021-0245 and issued EASA AD 2022-0225, dated November 21, 2022 (EASA AD 2022-0225) (referred to after this as the MCAI). The MCAI states that reports of single engine events caused by water contamination resulted in loss of engine thrust. An investigation determined that certain engines were exposed to unacceptable levels of water contamination, which caused corrosion on the fuel pump's internal components. This corrosion led to debris release and filter blockages in variable stator vane actuator control units, which resulted in the variable stator vane system failing in the closed position.
The FAA has since determined that in addition to replacing the affected fuel pump on at least one engine before further flight, replacing all affected fuel pumps installed on all engines within a specified compliance time and prohibiting installation of any affected engine onto any airplane or any affected fuel pump onto any engine is necessary to address the unsafe condition. Subsequently, the manufacturer published service information, which describes procedures for replacing the fuel pump.
Additionally, the FAA has determined that the estimated labor cost in AD 2021-26-11 requires revision as it indicates 4.5 work-hours are required to replace the affected fuel pump. The correct estimated labor cost for replacement of the affected fuel pump is estimated to be 9 work-hours. The FAA has updated the cost estimate in this proposed AD to reflect the correct number of work-hours.
The FAA is proposing this AD to prevent failure of the variable stator vane system. This condition, if not addressed, could result in dual-engine loss of thrust control or in-flight engine shutdown, and reduced control of the airplane.
You may examine the MCAI in the AD docket at
The FAA reviewed EASA AD 2022-0225, which specifies procedures for replacing the affected fuel pump. EASA AD 2022-0225 also specifies not to install an affected engine onto any airplane or an affected part onto any engine. 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 the same type design.
This proposed AD would retain none of the requirements of AD 2021-26-11. This proposed AD would require accomplishing the actions specified in the MCAI described previously, except for any differences identified as exceptions in the regulatory text of this proposed AD and except as discussed under “Differences Between this Proposed AD and the MCAI.” This proposed AD would also prohibit installation of any affected engine onto any airplane or any affected fuel pump onto any engine.
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 since coordinated with other manufacturers and CAAs to use this process. As a result, the FAA proposes to incorporate by reference EASA AD 2022-0225 in the FAA final rule. This proposed AD would, therefore, require compliance with EASA AD 2022-0225 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 the EASA AD 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-0225. Service information required by the EASA AD for compliance will be available at
Where paragraph (1) of EASA AD 2022-0225 requires replacing the affected part within 30 days after November 17, 2021 (the effective date of EASA AD 2021-0245), this AD requires replacing an affected fuel pump on at least one engine before further flight after the effective date of this AD.
Where paragraphs (3) and (4) of EASA AD 2022-0225 refer to November 17, 2021 (the effective date of EASA AD 2021-0245), this AD requires using the effective date of this AD.
The FAA estimates that this AD, if adopted as proposed, would affect 2 engines installed on 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 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.
The FAA must receive comments on this airworthiness directive (AD) by June 2, 2023.
This AD replaces AD 2021-26-11, Amendment 39-21870 (86 FR 71367, December 16, 2021).
This AD applies to Rolls-Royce Deutschland Ltd. & Co. KG Model RB211-Trent 875-17, 877-17, 884-17, 884B-17, 892-17, 892B-17, and 895-17 engines.
Joint Aircraft System Component (JASC) Code 7314, Engine Fuel Pump.
This AD was prompted by reports of single engine events caused by water contamination, which led to corrosion on the fuel pump that resulted in loss of engine thrust. The FAA is issuing this AD to prevent failure of the variable stator vane system. The unsafe condition, if not addressed, could result in dual-engine loss of thrust control or in-flight engine shutdown, and reduced control of the airplane.
Comply with this AD within the compliance times specified, unless already done.
Except as specified in paragraphs (h) and (i) of this AD: Perform all required actions within the compliance times specified in, and in accordance with, European Union Aviation Safety Agency (EASA) AD 2022-0225, dated November 21, 2022 (EASA AD 2022-0225).
(1) Where paragraph (1) of EASA AD 2022-0225 specifies to replace the affected part with a fuel pump that is not an affected part, on at least one of the affected engines within 30 days after 17 November 2021 [the effective date of EASA AD 2021-0245], this AD requires replacing an affected fuel pump on at least one engine before further flight after the effective date of this AD.
(2) Where paragraph (2) of EASA AD 2022-0225 refers to its effective date, this AD requires using the effective date of this AD.
(3) Where paragraphs (3) and (4) of EASA AD 2022-0225 refer to November 17, 2021 (the effective date of EASA AD 2021-0245), this AD requires using the effective date of this AD.
(4) This AD does not adopt the Remarks paragraph of EASA AD 2022-0225.
(5) Where the service information referenced in EASA AD 2022-0225 specifies to scrap fuel pumps, this AD requires removing those fuel pumps from service.
(6) Where the service information referenced in EASA AD 2022-0225 specifies to return fuel pumps, this AD requires removing those fuel pumps from service.
Although the service information referenced in EASA AD 2022-0225 specifies to submit certain information to the manufacturer, this AD does not include that requirement.
(1) The Manager, ECO Branch, FAA, has the authority to approve AMOCs for this AD, if requested using the procedures found in 14 CFR 39.19. In accordance with 14 CFR 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 certification office, send it to the attention of the person identified in paragraph (k) of this AD and email to:
(2) Before using any approved AMOC, notify your appropriate principal inspector, or lacking a principal inspector, the manager of the local flight standards district office/certificate holding district office.
For more information about this AD, contact Sungmo Cho, Aviation Safety Engineer, ECO Branch, FAA, 1200 District Avenue, Burlington, MA 01803; phone: (781) 238-7241; 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 the AD specifies otherwise.
(i) European Union Aviation Safety Agency AD 2022-0225, dated November 21, 2022.
(ii) [Reserved]
(3) For EASA AD 2022-0225, contact EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; phone: +49 221 8999 000; email:
(4) You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 1200 District Avenue, Burlington, MA 01803. 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), DOT.
Notice of proposed rulemaking (NPRM).
The FAA proposes to supersede Airworthiness Directive (AD) 2021-05-03, which applies to certain Airbus Helicopters Model EC225LP helicopters. AD 2021-05-03 requires various inspections of a certain part-numbered left-hand (LH) engine fuel supply (fuel supply) hose and depending on the inspection results, reinstalling or removing the fuel supply hose from service. AD 2021-05-03 also requires installing an improved part and prohibits installing an affected fuel supply hose on any helicopter unless it is installed by following certain procedures. Since the FAA issued AD 2021-05-03, there were reports of difficulties using an adjusting tool to install the improved fuel supply hose. This proposed AD would continue to require the actions of 2021-05-03 and expand the applicability, expand the parts installation limitations, and require using an improved adjusting tool and updated procedures. This proposed AD would also update certain compliance times and clarify certain requirements. The FAA is proposing this AD to address the unsafe condition on these products.
The FAA must receive comments on this proposed AD by June 2, 2023.
You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:
•
•
•
•
• For Airbus Helicopters service information identified in this NPRM, contact Airbus Helicopters, 2701 North Forum Drive, Grand Prairie, TX 75052; telephone (972) 641-0000 or (800) 232-0323; fax (972) 641-3775; or at
• You may view this service information at the FAA, Office of the Regional Counsel, Southwest Region, 10101 Hillwood Pkwy., Room 6N-321, Fort Worth, TX 76177. For information on the availability of this material at the FAA, call (817) 222-5110.
Hal Jensen, Aerospace Engineer, Operational Safety Branch, Compliance & Airworthiness Division, FAA, 26805 E 68th Ave., Mail Stop: Room 214, Denver, CO 80249; telephone (303) 342-1080; 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 Hal Jensen, Aerospace Engineer, Operational Safety Branch, Compliance & Airworthiness Division, FAA, 26805 E 68th Ave., Mail Stop: Room 214, Denver, CO 80249; telephone (303) 342-1080; email
The FAA issued AD 2021-05-03, Amendment 39-21864 (86 FR 72824, December 23, 2021) (AD 2021-05-03), for certain Airbus Helicopters Model EC225LP helicopters. AD 2021-05-03 requires visually inspecting a certain part-numbered LH fuel supply hose for twisting, and if needed, borescope inspecting the entire length of the inside of the fuel supply hose for twisting. Depending on the inspection results, AD 2021-05-03 requires reinstalling or removing the fuel supply hose from service. Additionally, AD 2021-05-03 prohibits installing that part-numbered LH fuel supply hose on any helicopter unless that LH fuel supply hose is installed by following certain procedures described in the manufacturer's service bulletin. Finally, AD 2021-05-03 also requires modifying your helicopter by removing LH fuel supply hose part number (P/N) 704A34416087 from service and installing the improved LH fuel supply hose P/N 704A34416101.
AD 2021-05-03 was prompted by EASA AD 2021-0156, dated July 2, 2021 (EASA AD 2021-0156), which superseded EASA AD 2019-0092, dated April 26, 2019 (EASA AD 2019-0092), issued by EASA, which is the Technical Agent for the Member States of the
EASA AD 2021-0156 retained the requirements of EASA AD 2019-0092 and required replacing the affected part with the improved part. EASA AD 2021-0156 also allowed a terminating action for the inspection requirements once the improved part had been installed according to the installation requirements.
Since the FAA issued AD 2021-05-03, EASA issued AD 2022-0087, dated May 16, 2022 (EASA AD 2022-0087) to supersede EASA AD 2021-0156. EASA advises of difficulties that were reported during installation of the improved LH fuel supply hose due to using an inappropriately shaped adjusting tool. Accordingly, EASA AD 2022-0087 retains the requirements of EASA AD 2021-0156 and requires replacing the affected part with the improved part by following updated modification instructions and using an improved adjusting tool. The updated modification instructions also specify updated torque values for the junction nuts and re-tightening instructions for helicopters modified with previous instructions. EASA AD 2022-0087 requires a repetitive inspection for fuel leakage for those helicopters modified with previous instructions and considers the re-tightening of the junction nuts of the improved part as terminating action for the repetitive inspection requirements.
Accordingly, this proposed AD would expand the applicability of AD 2021-05-03 by adding LH fuel supply hose P/N 704A34416101. The FAA also determined to update certain compliance times by adding calendar compliance times to factor in varying fleet usage and clarified the actions in paragraphs (g)(1)(i) and (ii) of AD 2021-05-03. This proposed AD also updates the parts installation limitations for LH fuel supply hose P/N 704A34416087 and adds parts installation limitations for LH fuel supply hose P/N 704A34416101. Lastly, this NPRM updates the Costs of Compliance section by correcting the number of work-hours to replace an LH fuel supply hose.
These helicopters been approved by EASA and are approved for operation in the United States. Pursuant to the FAA's bilateral agreement with the European Union, EASA has notified the FAA about the unsafe condition described in its AD. The FAA is proposing this AD after evaluating all known relevant information and determining that the unsafe condition described previously is likely to exist or develop on other helicopters of the same type design.
The FAA reviewed Airbus Helicopters Alert Service Bulletin (ASB) No. EC225-28A026, Revision 1, dated May 6, 2022 (ASB EC225-28A026 Rev 1), which specifies procedures for modifying the adjusting tool and replacing the LH fuel supply hose by using the modified adjusting tool. ASB EC225-28A026 Rev 1 also specifies updated allowable torque limits for the junction nuts and, for helicopters that have previously accomplished Airbus Helicopters ASB No. EC225-28A026, Revision 0, dated May 21, 2021, ASB EC225-28A026 Rev 1 specifies procedures to repetitively inspect the junction nuts for fuel leakage until the LH engine is removed and the updated allowable torque limit is applied to the junction nuts.
This proposed AD would also require Airbus Helicopters ASB No. EC225-71A019, Revision 2, dated May 21, 2021, which the Director of the Federal Register approved for incorporation by reference as of January 27, 2022 (86 FR 72824, December 23, 2021).
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 the
The FAA also reviewed Airbus Helicopters ASB No. EC225-71A019, Revision 1, dated February 28, 2019. This service information specifies procedures for removing the fuel supply hose from the LH power plant, visually inspecting the fuel supply hose for twisting, and depending on inspection results, performing an endoscope inspection on the inside of the hose.
For helicopters with LH fuel supply hose P/N 704A34416087 installed, this proposed AD would require visually inspecting the LH fuel supply hose for twisting, and if needed, borescope inspecting the entire length of the inside of the fuel supply hose for twisting. Depending on the inspection results, this proposed AD would require reinstalling or removing the fuel supply hose from service. This proposed AD would also require modifying your helicopter by removing LH fuel supply hose P/N 704A34416087 from service and installing improved LH fuel supply hose P/N 704A34416101 using updated procedures. Additionally, for helicopters modified with the improved LH fuel supply hose P/N 704A34416101 using previous procedures or if the installation procedures cannot be determined, this proposed AD would require repetitive inspections for fuel leakage and, depending on the results, tightening the junction nuts of this improved fuel supply hose with the LH side engine removed. Tightening the junction nuts would provide terminating action for the repetitive fuel leakage inspections. Lastly, this proposed AD would require installation limitations for LH fuel supply hose P/N 704A34416087 and LH fuel supply hose P/N 704A34416101.
EASA AD 2022-0087 is applicable to all serial-numbered Model EC225LP helicopters, whereas this proposed AD would apply to Model EC225LP helicopters with certain part-numbered LH fuel supply hoses installed.
For helicopters modified with LH fuel supply hose P/N 704A34416101 in accordance with previous instructions or by installation of AH modification 0728745 prior to initial delivery of the helicopter from the manufacturer, EASA AD 2022-0087 requires re-tightening the junction nuts to the new torque values during the next (re)installation of the LH engine or of the improved fuel supply hose, whereas this proposed AD would require that action within 110 hours time-in-service with the LH side engine removed for helicopters with LH fuel supply hose P/N 704A34416101 installed with previous instructions, by installation of AH modification 0728745 prior to initial delivery of the helicopter from the manufacturer, or if the previously accomplished installation procedures cannot be determined. Also, for those helicopters, depending on the interim fuel leakage inspection results,
The FAA estimates that this AD, if adopted as proposed, would affect up to 28 helicopters of U.S. Registry. Labor rates are estimated at $85 per work-hour. Based on these numbers, the FAA estimates the following costs to comply with this proposed AD.
Visually inspecting the LH fuel supply hose for twisting would take about 1 work-hour for an estimated cost of $85 per helicopter and $2,380 for the U.S. fleet. Borescope inspecting the LH fuel supply hose would take about 8 work-hours for an estimated cost of $680 per helicopter.
Replacing an LH fuel supply hose would take up to 11 work-hours and parts would cost about $2,363 for an estimated replacement cost of $3,298 per replacement.
Inspecting for fuel leakage would take about 1 work-hour for an estimated cost of $85 per helicopter, per inspection cycle. Removing the LH engine and tightening the LH fuel supply hose fittings would take 8 work-hours for an estimated cost of $680 per helicopter.
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, 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 June 2, 2023.
This AD replaces AD 2021-05-03, Amendment 39-21864 (86 FR 72824, December 23, 2021).
This AD applies to Airbus Helicopters Model EC225LP helicopters, certificated in any category, with a left-hand side (LH) engine fuel supply (fuel supply) hose part number (P/N) 704A34416087 or P/N 704A34416101 installed.
Joint Aircraft Service Component (JASC) Code: 2820, Aircraft Fuel Distribution System.
This AD was prompted by a report of an incorrect installation of the LH fuel supply hose P/N 704A34416087. The FAA is issuing this AD to prevent restricted fuel flow to the LH engine. The unsafe condition, if not addressed, could result in a decrease of the LH engine power when accelerating to a power setting corresponding to One Engine Inoperative power and subsequent reduced control of the helicopter.
Comply with this AD within the compliance times specified, unless already done.
(1) For helicopters with LH fuel supply hose P/N 704A34416087 installed, within 110 hours time-in-service (TIS) or 6 months after the effective date of this AD, whichever occurs first, visually inspect the LH fuel supply hose for twisting as shown in Figures 1 and 2 of Airbus Helicopters Alert Service Bulletin (ASB) No. EC225-71A019, Revision 2, dated May 21, 2021 (ASB EC225-71A019 Rev 2). If the LH fuel supply hose has any twisting or if it cannot be determined if the LH fuel supply hose has any twisting, before further flight, borescope inspect the entire length of the inside of the fuel supply hose for twisting as shown in Figures 3 through 5 of ASB EC225-71A019 Rev 2.
(i) If the inside of the LH fuel supply hose has any twisting, before further flight, remove the LH fuel supply hose from service and install an airworthy LH fuel supply hose in accordance with the actions required by paragraphs (g)(2) or (4) of this AD.
(ii) If the inside of the LH fuel supply hose does not have any twisting, reinstall the LH fuel supply hose by following the Accomplishment Instructions, paragraph 3.B.3.b., of ASB EC225-71A019 Rev 2.
(2) For helicopters with LH fuel supply hose P/N 704A34416087 installed, within 1,200 hours TIS or 36 months after the effective date of this AD, whichever occurs first, modify your helicopter by removing from service LH fuel supply hose P/N 704A34416087 and installing LH fuel supply hose P/N 704A34416101 in accordance with the Accomplishment Instructions, paragraph 3.B.2.b., of Airbus Helicopters ASB No. EC225-28A026, Revision 1, dated May 6, 2022 (ASB EC225-28A026 Rev 1).
(3) For helicopters with LH fuel supply hose P/N 704A34416101 previously installed by accomplishing Airbus Helicopters ASB No. EC225-28A026, Revision 0, dated May 21, 2021, by installation of AH modification 0728745 prior to initial delivery of the helicopter from the manufacturer, or if the previously accomplished installation procedures cannot be determined, accomplish the actions required by paragraph (g)(3)(i) of this AD.
(i) Within 15 hours TIS or 7 days after the effective date of this AD, whichever occurs first, and thereafter at intervals not to exceed 15 hours TIS or 7 days, whichever occurs first, inspect the LH fuel supply hose for fuel leakage in the area of each junction nut (items 1a and 1b) as depicted in Figure 1 of ASB EC225-28A026 Rev 1.
(A) If there is any fuel leakage, before further flight, remove the LH side engine and tighten each junction nut (items 1a and 1b) of the LH fuel supply hose by applying the torque depicted in Figure 1 of ASB EC225-28A026 Rev 1.
(B) If there is no fuel leakage, within 110 hours TIS after the effective date of this AD, remove the LH side engine and tighten each junction nut (items 1a and 1b) of the LH fuel supply hose by applying the torque depicted in Figure 1 of ASB EC225-28A026 Rev 1.
(ii) Tightening the junction nuts as required by paragraphs (g)(3)(i)(A) and (B) of this AD constitutes terminating action for the repetitive inspection required by paragraph (g)(3)(i) of this AD.
(4) For helicopters with LH fuel supply hose P/N 704A34416087 installed, as of the effective date of this AD, you may replace an LH fuel supply hose P/N 704A34416087 with an LH fuel supply hose P/N 704A34416087 or reinstall an LH fuel supply hose P/N 704A34416087 on any helicopter by following the Accomplishment Instructions, paragraph 3.B.3.b., of ASB EC225-71A019 Rev 2, until required to install LH fuel supply hose P/N 704A34416101 by paragraph (g)(2) of this AD, provided one of the conditions in paragraphs (g)(4)(i) through (iii) of this AD is met.
(i) If installing, the LH fuel supply hose P/N 704A34416087 is new (zero total hours TIS).
(ii) If reinstalling, before reinstallation, the LH fuel supply hose P/N 704A34416087 is inspected by accomplishing the actions required by the introductory text of paragraph (g)(1) of this AD and the inside of the LH fuel supply hose does not have any twisting.
(iii) If reinstalling, the initial delivery of the helicopter from the manufacturer was on or after November 30, 2018, and the LH fuel supply hose P/N 704A34416087 has never been previously reinstalled.
(5) For helicopters with an LH fuel supply hose P/N 704A34416101 installed, as of the effective date of this AD, do not remove LH fuel supply hose P/N 704A34416101 and replace it with LH fuel supply hose P/N 704A34416087 and do not install an LH engine with an LH fuel supply hose P/N 704A34416087 installed.
This paragraph provides credit for the actions specified in paragraph (g)(1) of this AD, if those actions were performed before the effective date of this AD using Airbus Helicopters ASB No. EC225-71A019, Revision 1, dated February 28, 2019.
Special flight permits may be permitted provided that there are no passengers on board and that helicopters identified in paragraph (g)(3) of this AD have no fuel leakage.
(1) The Manager, International Validation Branch, FAA, has the authority to approve AMOCs for this AD, if requested using the procedures found in 14 CFR 39.19. In accordance with 14 CFR 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, send it to the attention of the person identified in paragraph (k)(2) of this AD. Information may be emailed to:
(2) Before using any approved AMOC, notify your appropriate principal inspector, or lacking a principal inspector, the manager of the local flight standards district office/certificate holding district office.
(1) Refer to European Union Aviation Safety Agency (EASA) AD 2022-0087, dated May 16, 2022, for related information. This EASA AD may be found in the AD docket at
(2) For more information about this AD, contact Hal Jensen, Aerospace Engineer, Operational Safety Branch, Compliance & Airworthiness Division, FAA, 26805 E 68th Ave., Mail Stop: Room 214, Denver, CO 80249; telephone (303) 342-1080; email
(3) Service information identified in this AD that is not incorporated by reference is available at the contact information specified in paragraphs (l)(5) and (6) 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.
(3) The following service information was approved for IBR on [DATE 35 DAYS AFTER PUBLICATION OF THE FINAL RULE].
(i) Airbus Helicopters Alert Service Bulletin No. EC225-28A026, Revision 1, dated May 6, 2022.
(ii) [Reserved]
(4) The following service information was approved for IBR on January 27, 2022 (86 FR 72824, December 23, 2021).
(i) Airbus Helicopters Alert Service Bulletin No. EC225-71A019, Revision 2, dated May 21, 2021.
(ii) [Reserved]
(5) For Airbus Helicopters service information identified in this AD, contact Airbus Helicopters, 2701 North Forum Drive, Grand Prairie, TX 75052; telephone (972) 641-0000 or (800) 232-0323; fax (972) 641-3775; or at
(6) You may view this service information at the FAA, Office of the Regional Counsel, Southwest Region, 10101 Hillwood Pkwy., Room 6N-321, Fort Worth, TX 76177. For information on the availability of this material at the FAA, call (817) 222-5110.
(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) 2021-16-18, which applies to all Airbus SAS Model A330-200 Freighter, A330-200, A330-300, A330-800, A330-900, A340-200, A340-300, A340-500, and A340-600 series airplanes. AD 2021-16-18 requires repetitive inspections of certain fuel pumps for cavitation erosion, replacement if necessary, revision of the existing operator's minimum equipment list (MEL), and accomplishment of certain maintenance actions related to defueling and ground fuel transfer operations. Since the FAA issued AD 2021-16-18, new, more erosion resistant pumps were developed and the FAA determined that affected fuel pumps must be replaced with new, more erosion resistant pumps. This proposed AD would continue to require the actions in AD 2021-16-18 and would require replacement of affected parts, which would terminate the repetitive inspections, as specified in a European Union Aviation Safety Agency (EASA) AD, which is proposed for incorporation by reference. This proposed AD would also prohibit the installation of certain affected parts. The FAA is proposing this AD to address the unsafe condition on these products.
The FAA must receive comments on this proposed AD by June 2, 2023.
You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:
•
•
•
•
• For the EASA AD identified in this NPRM, you may contact EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; telephone +49 221 8999 000; email
• For Eaton service information identified in this NPRM, you may contact Eaton Limited, Customer Support, Abbey Park, Southhampton Road, Titchfield, Fareham, Hampshire, PO14 4QA, U.K.; telephone +01 329853000; Fax +01 329853714.
• 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.
Vladimir Ulyanov, Aerospace Engineer, Large Aircraft Section, FAA, International Validation Branch, 2200 South 216th St., Des Moines, WA 98198; telephone 206-231-3229; 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 Vladimir Ulyanov, Aerospace Engineer, Large Aircraft Section, FAA, International Validation Branch, 2200 South 216th St., Des Moines, WA 98198; telephone 206-231-3229; email
The FAA issued AD 2021-16-18, Amendment 39-21681 (86 FR 60560, November 3, 2021) (AD 2021-16-18), which applies to all Airbus SAS Model A330-201, A330-202, A330-203, A330-223, A330-223F, A330-243, A330-243F, A330-301, A330-302, A330-303, A330-321, A330-322, A330-323, A330-341, A330-342, A330-343, A330-841, A330-941, A340-211, A340-212, A340-213, A340-311, A340-312, A340-313, A340-541, and A340-642 airplanes. AD 2021-16-18 was prompted by EASA AD 2020-0283, dated December 17, 2020; corrected December 24, 2020 (EASA AD 2020-0283), issued by EASA, which is the Technical Agent for the Member States of the European Union.
AD 2021-16-18 requires repetitive inspections of certain fuel pumps for cavitation erosion, replacement if necessary, revision of the operator's existing MEL, and accomplishment of certain maintenance actions related to defueling and ground fuel transfer operations. The FAA issued AD 2021-16-18 to address fuel pump erosion caused by cavitation.
Since the FAA issued AD 2021-16-18, EASA superseded EASA AD 2020-0283, and issued EASA AD 2022-0197, dated September 22, 2022 (EASA AD 2022-0197) (also referred to as the MCAI), to correct an unsafe condition for all Airbus SAS Model A330-201, A330-202, A330-203, A330-223, A330-223F, A330-243, A330-243F, A330-301, A330-302, A330-303, A330-321, A330-322, A330-323, A330-341, A330-342, A330-343, A330-743L, A330-841, A330-941, A340-211, A340-212, A340-213, A340-311, A340-312, A340-313, A340-541, A340-542, A340-642 and A340-643 airplanes. Model A330-743L, A340-542, and A340-643 airplanes are not certificated by the FAA and are not included on the U.S. type certificate data sheet; this proposed AD therefore does not include those airplanes in the applicability.
The MCAI states that new, more erosion resistant pumps have been developed to address the unsafe condition. The MCAI states there have been reports of fuel pumps showing cavitation erosion. This condition, if not detected and corrected, could result, in a case where the pump is running dry, in an ignition source in the fuel tank, which may result in a fuel tank explosion and consequent loss of the airplane.
The FAA is proposing this AD to address the unsafe condition on these products. You may examine the MCAI in the AD docket at
Although this proposed AD does not explicitly restate the requirements of AD 2021-16-18, this proposed AD would retain the requirements of AD 2021-16-18. Those requirements are referenced in EASA AD 2022-0197, which, in turn, is referenced in paragraph (g) of this proposed AD.
EASA AD 2022-0197 specifies procedures for repetitive inspections of all affected parts; replacement of affected parts if necessary; replacement of certain part-numbered affected parts, which allows a terminating action for the repetitive inspections; updating of the applicable Master Minimum Equipment List (MMEL), and certain maintenance actions related to defueling and ground fuel transfer operations. EASA AD 2022-0197 also prohibits
The FAA also reviewed Eaton Service Bulletin 8810-28-06, Revision 2, dated March 1, 2019, which defines erosion cases and breakthrough.
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 designs.
This proposed AD would retain the requirements of AD 2021-16-18. This proposed AD would require accomplishing the actions specified in EASA AD 2022-0197 described previously, except for any differences identified as exceptions in the regulatory text of this proposed AD.” This proposed AD would also prohibit the installation of certain affected parts.
Note 4 of EASA AD 2022-0197 refers to EASA AD 2015-0194. EASA AD 2015-0194 corresponds to FAA AD 2016-20-10, Amendment 39-18676 (81 FR 71593, October 18, 2016 (AD 2016-20-10)). AD 2016-20-10 requires the replacement of fuel pumps that have part number (P/N) P/N 568-1-28300-001, 568-1-28300-002, 568-1-28300-100, or 568-1-28300-101 with a pump having a part number other than those part numbers. However, operators should be aware that this proposed AD will prohibit the installation P/N 568-1-28300-103 as of the effective date of the AD.
AD 2016-20-10 also requires the replacement of P/N 568-1-28300-101 within 72 months or 96 months after November 22, 2016 (the effective date of AD 2016-20-10), depending on the configuration of the installed fuel pumps. Paragraph (5) of EASA AD 2022-0197 specifies to replace P/N 568-1-28300-101 at location A within 5 years after the effective date of that AD. Paragraph (6) of EASA AD 2022-0197 specifies to replace P/N 568-1-28300-101 at location B within 7 years after the effective date of that AD. These new compliance times do not apply to those affected by AD 2016-20-10. Therefore, the FAA has clarified the compliance time in paragraph (h)(10) of this AD.
EASA AD 2022-0197 requires operators to “inform all flight crews” of revisions to the MMEL, and thereafter to “operate the aeroplane accordingly.” However, this proposed AD would not specifically require those actions as they are already required by FAA regulations.
FAA regulations (14 CFR 121.628(a)(2)) require operators to provide pilots with access to all of the information contained in the operator's MEL.
Furthermore, 14 CFR 121.628(a)(5) requires airplanes to be operated under all applicable conditions and limitations contained in the operator's MEL. Therefore, including a requirement in this proposed AD to operate the airplane according to the revised MEL would be redundant and unnecessary. Further, compliance with such a requirement in an AD would be impracticable to demonstrate or track on an ongoing basis; therefore, a requirement to operate the airplane in such a manner would be unenforceable.
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-0197 by reference in the FAA final rule. This proposed AD would, therefore, require compliance with EASA AD 2022-0197 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-0197 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-0197. Service information required by EASA AD 2022-0197 for compliance will be available at
The FAA estimates that this AD, if adopted as proposed, would affect 112 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
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 June 2, 2023.
This AD replaces AD 2021-16-18, Amendment 39-21681 (86 FR 60560, dated November 3, 2021) (AD 2021-16-18).
This AD applies to all Airbus SAS Airplanes, certificated in any category, and identified in paragraphs (c)(1) through (9) of this AD.
(1) Model 330-223F and -243F airplanes.
(2) Model A330-201, -202, -203, -223, and -243 airplanes.
(3) Model A330-301, -302, -303, -321, -322, -323, -341, -342, and -343 airplanes.
(4) Model A330-841 airplanes.
(5) Model A330-941 airplanes.
(6) Model A340-211, -212, and -213 airplanes.
(7) Model A340-311, -312, and -313 airplanes.
(8) Model A340-541 airplanes.
(9) Model A340-642 airplanes.
Air Transport Association (ATA) of America Code 28, Fuel.
This AD was prompted by reports of a fuel pump showing cavitation erosion that exposed the fuel pump power supply wires, and a determination that affected fuel pumps must be replaced with new, more erosion resistant pumps. The FAA is issuing this AD to address fuel pump erosion caused by cavitation. If this condition is not addressed, a pump running dry could result in a fuel tank explosion and consequent loss of the airplane.
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, European Union Aviation Safety Agency (EASA) AD 2022-0197, dated September 22, 2022 (EASA AD 2022-0197).
(1) Where EASA AD 2022-0197 refers to its effective date, this AD requires using the effective date of this AD.
(2) Where EASA AD 2022-0197 refers to “31 December 2020 [the effective date of EASA AD 2020-0283],” this AD requires using “December 8, 2021 (the effective date of AD 2021-16-18).”
(3) Where EASA AD 2022-0197 refers to “13 December 2019 [the effective date of EASA AD 2019-0291 at original issue],” this AD requires using “November 18, 2020 (the effective date of AD 2020-21-05, Amendment 39-21278 (85 FR 64963, October 14, 2020)).”
(4) Where EASA AD 2022-0197 refers to “17 November 2017 [the effective date of EASA AD 2017-0224],” this AD requires using “December 29, 2017 (the effective date of AD 2017-25-16, Amendment 39-19130 (82 FR 58718, December 14, 2017)).”
(5) Where EASA AD 2022-0197 refers to the master minimum equipment list (MMEL), this AD refers to the operator's minimum equipment list (MEL).
(6) Where paragraphs (15), (16), and (17) of EASA AD 2022-0197 specify to “inform all flight crews, and, thereafter, operate the aeroplane accordingly,” this AD does not require those actions as those actions are already required by existing FAA operating regulations (see 14 CFR 121.628(a)(2) and 121.628(a)(5)).
(7) Where the Definitions section of EASA AD 2022-0197 specifies “erosion cases and breakthrough” and refers to “Eaton Aerospace Ltd SB 8810-28-06 Revision 2 (or later revisions),” for this AD, use only Eaton Service Bulletin 8810-28-06, Revision 2, dated March 1, 2019.
(8) Note 4 of EASA AD 2022-0197 refers to EASA AD 2015-0194. EASA AD 2015-0194 corresponds to FAA AD 2016-20-10, Amendment 39-18676 (81 FR 71593, October 18, 2016) (AD 2016-20-10).
(9) This AD does not adopt the “Remarks” section of EASA AD 2022-0197.
(10) Where paragraphs (5) and (6) of EASA AD 2022-0197 specify a compliance time to replace part number (P/N) 568-1-28300-101, for airplanes identified in AD 2016-20-10, the compliance time to replace fuel pumps having P/N 568-1-28300-101, or a combination of P/N 568-1-28300-101 and certain other part numbers, is specified in paragraphs (h)(1) and (2) of AD 2016-20-10, as applicable.
Although the service information referenced in EASA AD 2022-0197 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)
(3)
For more information about this AD, contact Vladimir Ulyanov, Aerospace Engineer, Large Aircraft Section, FAA, International Validation Branch, 2200 South 216th St., Des Moines, WA 98198; telephone 206-231-3229; 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) Eaton Service Bulletin 8810-28-06, Revision 2, dated March 1, 2019.
(ii) European Union Aviation Safety Agency (EASA) AD 2022-0197, dated September 22, 2022 (EASA AD 2022-0197).
(3) For Eaton service information identified in this AD, contact Eaton Limited, Customer Support, Abbey Park, Southhampton Road, Titchfield, Fareham, Hampshire, PO14 4QA, U.K.; telephone + 01 329853000; Fax + 01 329853714.
(4) For EASA AD 2022-0197, contact EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; telephone +49 221 8999 000; email
(5) 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.
(6) 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.
Proposed rule; withdrawal.
The FAA is withdrawing the notice of proposed rulemaking published in the
The FAA is withdrawing the proposed rule published November 7, 2022 (87 FR 66974) as of April 18, 2023.
John Fornito, Operations Support Group, Eastern Service Center, Federal Aviation Administration, 1701 Columbia Avenue, College Park, GA 30337; telephone (404) 305-6364.
The FAA is withdrawing the NPRM for Docket No, FAA-2022-1347 (87 FR 66974; November 7, 2022) amending Class E airspace for Foothills Regional Airport, Morganton, NC, because it is duplicative of a previously published action. The FAA published a separate NPRM in the
The FAA determined that the NPRM published on November 7, 2022, is duplicative and unnecessary. Therefore, the FAA withdraws that NPRM.
Federal Aviation Administration (FAA), DOT.
Notice of proposed rulemaking (NPRM).
This action proposes to revoke Very High Frequency (VHF) Omnidirectional Range (VOR) Federal airway V-456 and the Mankato, MN, Low Altitude Reporting Point. The FAA is proposing this action due to the planned decommissioning of the VOR portion of the Mankato, MN (MKT), VOR/Distance Measuring Equipment (VOR/DME) navigational aid (NAVAID). The Mankato VOR is being decommissioned in support of the FAA's VOR Minimum Operational Network (MON) program.
Comments must be received on or before June 2, 2023.
Send comments identified by FAA Docket No. FAA-2023-0955 and Airspace Docket No. 22-AGL-37 using any of the following methods:
*
*
*
*
FAA Order JO 7400.11G, Airspace Designations and Reporting Points, and subsequent amendments can be viewed online at
Colby Abbott, Rules and Regulations Group, Office of Policy, Federal Aviation Administration, 800 Independence Avenue SW, Washington, DC 20591; telephone: (202) 267-8783.
The FAA's authority to issue rules regarding aviation safety is found in Title 49 of the United States Code.
The FAA invites interested persons to participate in this rulemaking by submitting written comments, data, or views. Comments are specifically invited on the overall regulatory, aeronautical, economic, environmental, and energy-related aspects of the proposal. The most helpful comments reference a specific portion of the proposal, explain the reason for any recommended change, and include supporting data. To ensure the docket does not contain duplicate comments, commenters should submit only one time if comments are filed electronically, or commenters should send only one copy of written comments if comments are filed in writing.
The FAA will file in the docket all comments it receives, as well as a report summarizing each substantive public contact with FAA personnel concerning this proposed rulemaking. Before acting on this proposal, the FAA will consider all comments it receives on or before the closing date for comments. The FAA will consider comments filed after the comment period has closed if it is possible to do so without incurring expense or delay. The FAA may change this proposal in light of the comments it receives.
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 Operations office (see
VOR Federal airways are published in paragraph 6010(a) and Domestic Low Altitude Reporting Points are published in paragraph 7001 of FAA Order JO 7400.11, Airspace Designations and Reporting Points, which is incorporated by reference in 14 CFR 71.1 on an annual basis. This document proposes to amend the current version of that order, FAA Order JO 7400.11G, dated August 19, 2022, and effective September 15, 2022. These updates would be published in the next update to FAA Order JO 7400.11. That order is publicly available as listed in the
FAA Order JO 7400.11G lists Class A, B, C, D, and E airspace areas, air traffic service routes, and reporting points.
The FAA is planning to decommission the VOR portion of the Mankato, MN, VOR/DME in November 2023. The Mankato VOR is one of the candidate VORs identified for discontinuance by the FAA's VOR MON program and listed in the Final policy statement notice, “Provision of Navigation Services for the Next Generation Air Transportation System (NextGen) Transition to Performance-Based Navigation (PBN) (Plan for Establishing a VOR Minimum Operational Network),” published in the
Although the VOR portion of the Mankato VOR/DME NAVAID is planned for decommissioning, the co-located DME portion of the NAVAID is being retained to support NextGen PBN flight procedure requirements.
The VOR Federal airway and reporting point affected by the planned Mankato, MN, VOR decommissioning are V-456 and the Mankato, MN, low altitude reporting point. With the planned decommissioning of the Mankato VOR, the remaining ground-based NAVAID coverage in the area is insufficient to enable the continuity of V-456. As such, V-456 and the Mankato low altitude reporting point are proposed to be revoked.
To address these proposed revocations, instrument flight rules (IFR) traffic could use adjacent VOR Federal airways V-24, V-26, V-398, and V-505 or receive air traffic control (ATC) radar vectors to fly around or through the affected area. Additionally, pilots equipped with RNAV capabilities could use Area Navigation (RNAV) route T-400 or navigate point to point using the existing fixes that would remain in place to support continued operations though the affected area. Visual flight rules (VFR) pilots who elect to navigate via the affected VOR Federal airways could also take advantage of the adjacent ATS routes or ATC services listed previously.
The FAA is proposing to amend 14 CFR part 71 by revoking VOR Federal airway V-456 and the Mankato, MN, low altitude reporting point. The VOR Federal airway and low altitude reporting point revocations are due to the planned decommissioning of the Mankato, MN, VOR. The proposed airway and low altitude reporting point actions are described below.
The FAA has determined that this proposed regulation only involves an established body of technical regulations for which frequent and routine amendments are necessary to keep them operationally current. 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 proposed rule, when promulgated, will 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).
In consideration of the foregoing, 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.
Federal Aviation Administration (FAA), DOT.
Notice of proposed rulemaking (NPRM).
This action proposes to amend Very High Frequency (VHF) Omnidirectional Range (VOR) Federal airways V-158 and V-172 in the vicinity of Polo, IL. The amendments are due to the planned decommissioning of the VOR portion of the Polo, IL (PLL), VOR/Distance Measuring Equipment (VOR/DME) navigational aid (NAVAID). The Polo VOR is being decommissioned as part of the FAA's VOR Minimum Operational Network (MON) program.
Comments must be received on or before June 2, 2023.
Send comments identified by FAA Docket No. FAA-2023-0965 and Airspace Docket No. 23-AGL-8 using any of the following methods:
*
*
*
*
FAA Order JO 7400.11G, Airspace Designations and Reporting Points, and subsequent amendments can be viewed online at
Colby Abbott, Rules and Regulations Group, Office of Policy, Federal Aviation Administration, 800 Independence Avenue SW, Washington, DC 20591; telephone: (202) 267-8783.
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 the 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 the National Airspace System (NAS) as necessary to preserve the safe and efficient flow of air traffic.
The FAA invites interested persons to participate in this rulemaking by submitting written comments, data, or views. Comments are specifically invited on the overall regulatory, aeronautical, economic, environmental, and energy-related aspects of the proposal. The most helpful comments reference a specific portion of the proposal, explain the reason for any recommended change, and include supporting data. To ensure the docket does not contain duplicate comments, commenters should submit only one time if comments are filed electronically, or commenters should send only one copy of written comments if comments are filed in writing.
The FAA will file in the docket all comments it receives, as well as a report summarizing each substantive public contact with FAA personnel concerning this proposed rulemaking. Before acting on this proposal, the FAA will consider all comments it receives on or before the closing date for comments. The FAA will consider comments filed after the comment period has closed if it is possible to do so without incurring
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 Operations office (see
VOR Federal airways are published in paragraph 6010(a) of FAA Order JO 7400.11, Airspace Designations and Reporting Points, which is incorporated by reference in 14 CFR 71.1 on an annual basis. This document proposes to amend the current version of that order, FAA Order JO 7400.11G, dated August 19, 2022, and effective September 15, 2022. These updates would be published in the next update to FAA Order JO 7400.11. That order is publicly available as listed in the
FAA Order JO 7400.11G lists Class A, B, C, D, and E airspace areas, air traffic service routes, and reporting points.
The FAA is planning to decommission the VOR portion of the Polo, IL, VOR/DME in January 2024. The Polo VOR is one of the candidate VORs identified for discontinuance by the FAA's VOR MON program and listed in the Final policy statement notice, “Provision of Navigation Services for the Next Generation Air Transportation System (NextGen) Transition to Performance-Based Navigation (PBN) (Plan for Establishing a VOR Minimum Operational Network),” published in the
Although the VOR portion of the Polo, IL, VOR/DME NAVAID is planned for decommissioning, the co-located DME portion of the NAVAID is being retained to support NextGen PBN flight procedure requirements.
The VOR Federal airways affected by the Polo VOR decommissioning are V-158 and V-172. With the planned decommissioning of the Polo VOR, the remaining ground-based NAVAID coverage in the area is insufficient to enable the continuity of the affected airways. As such, the proposed modifications to V-158 and V-172 would result in the airways being shortened due to the loss of the segments supported by the Polo VOR.
To address these proposed modifications, instrument flight rules (IFR) traffic could use adjacent VOR Federal airways V-6, V-24, V-216, and V-228 or receive air traffic control (ATC) radar vectors to fly around or through the affected area. Additionally, pilots equipped with RNAV capabilities could also use Area Navigation (RNAV) routes T-265, T-302, T-325, and T-354 or navigate point to point using the existing fixes that would remain in place to support continued operations though the affected area. Visual flight rules (VFR) pilots who elect to navigate via the affected VOR Federal airways could also take advantage of the adjacent ATS routes or ATC services listed previously.
Prior to this NPRM, the FAA published a rule for Docket No. FAA-2022-1395 in the
Currently, the description of V-158 includes an exclusion for restricted area R-3302; however, the FAA revoked that restricted area in 2000. (65 FR 49483; August 14, 2000). The proposed change updates the V-158 description by removing the obsolete reference to R-3302.
The FAA is proposing an amendment to 14 CFR part 71 by amending VOR Federal airways V-158 and V-172 due to the planned decommissioning of the VOR portion of the Polo, IL, VOR/DME. The proposed airway actions are described below.
The NAVAID radials contained in the VOR Federal airway descriptions below are unchanged and stated in degrees True north.
The FAA has determined that this proposed regulation only involves an established body of technical regulations for which frequent and routine amendments are necessary to keep them operationally current. 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 proposed rule, when promulgated, will 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).
In consideration of the foregoing, the Federal Aviation Administration
49 U.S.C. 106(f), 106(g); 40103, 40113, 40120; E.O. 10854, 24 FR 9565, 3 CFR, 1959-1963 Comp., p. 389.
From Mason City, IA; INT Mason City 106° and Dubuque, IA, 293° radials; to Dubuque.
From Columbus, NE; Omaha, IA; INT Omaha 066° and Newton, IA, 262° radials; Newton; Cedar Rapids, IA.
Federal Aviation Administration (FAA), DOT.
Notice of proposed rulemaking (NPRM).
This action proposes to revoke Alaskan VOR Federal AirwayV-318 in the vicinity of Level Island, AK. The FAA is proposing this action due to the airways lack of use.
Comments must be received on or before June 2, 2023.
Send comments identified by FAA Docket No. FAA-2023-0916 and Airspace Docket No. 22-AAL-85 using any of the following methods:
*
*
*
*
FAA Order JO 7400.11G, Airspace Designations and Reporting Points, and subsequent amendments can be viewed online at
Steven Roff, Rules and Regulations Group, Office of Policy, Federal Aviation Administration, 800 Independence Avenue SW, Washington, DC 20591; telephone: (202) 267-8783.
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 the 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 the route structure as necessary to preserve the safe and efficient flow of air traffic within the National Airspace System (NAS).
The FAA invites interested persons to participate in this rulemaking by submitting written comments, data, or views. Comments are specifically invited on the overall regulatory, aeronautical, economic, environmental, and energy-related aspects of the proposal. The most helpful comments reference a specific portion of the proposal, explain the reason for any recommended change, and include supporting data. To ensure the docket does not contain duplicate comments, commenters should submit only one time if comments are filed electronically, or commenters should send only one copy of written comments if comments are filed in writing.
The FAA will file in the docket all comments it receives, as well as a report summarizing each substantive public contact with FAA personnel concerning this proposed rulemaking. Before acting on this proposal, the FAA will consider all comments it receives on or before the closing date for comments. The FAA will consider comments filed after the comment period has closed if it is possible to do so without incurring expense or delay. The FAA may change this proposal in light of the comments it receives.
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 Operations office (see
Alaskan VOR Federal Airways are published in paragraph 6010 of FAA Order JO 7400.11, Airspace Designations and Reporting Points, which is incorporated by reference in 14 CFR 71.1 on an annual basis. This document proposes to amend the current version of that order, FAA Order JO 7400.11G, dated August 19, 2022 and effective September 15, 2022. These updates would be published in the next update to FAA Order JO 7400.11. That order is publicly available as listed in the
FAA Order JO 7400.11G lists Class A, B, C, D, and E airspace areas, air traffic service routes, and reporting points.
Alaskan Federal Airway V-318 is no longer used by air traffic control or requested by pilots. The airway offers indirect routing between the Level Island, AK, VOR and the Annette Island, AK, VOR. It once offered the lowest minimum enroute altitude (MEA) on a Federal Airway between the Level Island, AK, VOR and the Annette Island, AK, VOR making it desirable for pilots requiring a lower altitude to avoid inclement weather. Federal AirwayV-317 offers direct routing between the Level Island, AK, VOR and the Annette Island, AK, VOR and now has a global navigation satellite system MEA equal to that of V-318. Pilots no longer request V-318 because V-317 offers direct routing and has the same MEA.
The FAA is proposing an amendment to 14 CFR part 71 by revoking Alaskan VOR Federal Airway V-318 in its entirety. The existing Alaskan VOR Federal Airway V-317 would mitigate the loss of Federal Airway V-318. Federal Airway V-317 provides more economic and efficient routing for aircraft.
The FAA has determined that this proposed regulation only involves an established body of technical regulations for which frequent and routine amendments are necessary to keep them operationally current. 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 proposed rule, when promulgated, will 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).
In consideration of the foregoing, 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.
Environmental Protection Agency (EPA).
Proposed rule.
On September 6, 2022, the Commonwealth of Kentucky, through the Kentucky Energy and Environment Cabinet (Cabinet), Division of Air Quality (DAQ), submitted a request for the Environmental Protection Agency (EPA) to redesignate the Kentucky portion (hereinafter referred to as the “Louisville, KY Area” or “Area”) of the Louisville, Kentucky-Indiana, 2015 8-hour ozone nonattainment area (hereinafter referred to as the “Louisville, KY-IN Area”) to attainment for the 2015 8-hour ozone National Ambient Air Quality Standards (NAAQS or standards) and to approve a State Implementation Plan (SIP) revision containing a maintenance plan for the Area. EPA is proposing to approve the Commonwealth's plan for maintaining attainment of the 2015 8-hour ozone standard in the Louisville, KY-IN Area, including the regional motor vehicle emission budgets (MVEBs) for nitrogen oxides (NO
Comments must be received on or before May 18, 2023.
Submit your comments, identified by Docket ID No. EPA-R04-OAR-2022-0789 at
Sarah LaRocca, Air Regulatory Management Section, Air Planning and Implementation Branch, Air and Radiation Division, U.S. Environmental Protection Agency, Region 4, 61 Forsyth Street SW, Atlanta, Georgia 30303-8960. The telephone number is (404) 562-8994. Ms. Sarah LaRocca can also be reached via electronic mail at
EPA is proposing to take the following separate but related actions addressing the September 6, 2022, submittal: (1) to approve Kentucky's plan for maintaining the 2015 ozone NAAQS (maintenance plan), including the associated MVEBs for the Louisville, KY Area and incorporate the plan into the SIP, and (2) to redesignate the Louisville, KY Area to attainment for the 2015 8-hour ozone NAAQS. EPA is also notifying the public of the status of EPA's adequacy determination for the MVEBs for the Louisville, KY Area. The Louisville, KY-IN Area is composed of Bullitt, Jefferson, and Oldham Counties in Kentucky, and Clark and Floyd Counties in Indiana. These proposed actions are summarized below and described in greater detail throughout this notice of proposed rulemaking.
EPA is proposing to approve Kentucky's maintenance plan for its portion of the Louisville, KY-IN Area as meeting the requirements of section 175A (such approval being one of the Clean Air Act (CAA or Act) criteria for redesignation to attainment status) and incorporate it into the SIP. The maintenance plan is designed to keep the Louisville, KY-IN Area in attainment of the 2015 8-hour ozone NAAQS through 2035. The maintenance plan includes 2019 and 2035 MVEBs for NO
EPA also proposes to determine that the Louisville, KY Area has met the requirements for redesignation under section 107(d)(3)(E) of the CAA. Accordingly, EPA is proposing to approve a request to change the legal designation of Bullitt, Jefferson, and Oldham Counties in Kentucky, as found at 40 CFR part 81, from nonattainment to attainment for the 2015 8-hour ozone NAAQS.
EPA is also notifying the public of the status of EPA's adequacy process for the MVEBs for the Louisville, KY-IN Area. The Adequacy comment period began on September 14, 2022, with EPA's posting of the availability of Kentucky's submission on EPA's Adequacy website (
In summary, this notice of proposed rulemaking is in response to Kentucky's September 6, 2022, redesignation request and associated SIP submission that addresses the specific issues summarized above and the necessary elements described in section 107(d)(3)(E) of the CAA for redesignation of the Kentucky portion of the Louisville, KY-IN Area to attainment for the 2015 8-hour ozone NAAQS and the associated MVEBs.
On October 1, 2015, EPA revised both the primary and secondary NAAQS for ozone to a level of 0.070 parts per million (ppm) to provide increased protection of public health and the environment.
Upon promulgation of a new or revised ozone NAAQS, section 107(d) of the CAA requires EPA to designate as nonattainment any area that is violating the NAAQS (or that contributes to ambient air quality in a nearby area that is violating the NAAQS). As part of the designations process for the 2015 8-hour ozone NAAQS, the Louisville, KY-IN Area was designated as a “Marginal” ozone nonattainment area, effective August 3, 2018.
The CAA provides the requirements for redesignating a nonattainment area to attainment. Specifically, section 107(d)(3)(E) of the CAA allows for redesignation providing that: (1) The EPA Administrator determines that the area has attained the applicable NAAQS; (2) the Administrator has fully approved the applicable implementation plan for the area under section 110(k); (3) the Administrator determines that the improvement in air quality is due to permanent and enforceable reductions in emissions resulting from implementation of the
EPA provided guidance on redesignation in the General Preamble for the Implementation of title I of the CAA Amendments of 1990 on April 16, 1992 (57 FR 13498) and supplemented that guidance on April 28, 1992 (57 FR 18070). EPA has provided further guidance on processing redesignation requests in the following documents:
1. “Ozone and Carbon Monoxide Design Value Calculations,” Memorandum from Bill Laxton, Director, Technical Support Division, June 18, 1990;
2. “Maintenance Plans for Redesignation of Ozone and Carbon Monoxide Nonattainment Areas,” Memorandum from G.T. Helms, Chief, Ozone/Carbon Monoxide Programs Branch, April 30, 1992;
3. “Contingency Measures for Ozone and Carbon Monoxide (CO) Redesignations,” Memorandum from G.T. Helms, Chief, Ozone/Carbon Monoxide Programs Branch, June 1, 1992;
4. “Procedures for Processing Requests to Redesignate Areas to Attainment,” Memorandum from John Calcagni, Director, Air Quality Management Division, September 4, 1992 (hereinafter referred to as the “Calcagni Memorandum”);
5. “State Implementation Plan (SIP) Actions Submitted in Response to Clean Air Act (CAA) Deadlines,” Memorandum from John Calcagni, Director, Air Quality Management Division, October 28, 1992;
6. “Technical Support Documents (TSDs) for Redesignation of Ozone and Carbon Monoxide (CO) Nonattainment Areas,” Memorandum from G.T. Helms, Chief, Ozone/Carbon Monoxide Programs Branch, August 17, 1993;
7. “State Implementation Plan (SIP) Requirements for Areas Submitting Requests for Redesignation to Attainment of the Ozone and Carbon Monoxide (CO) National Ambient Air Quality Standards (NAAQS) On or After November 15, 1992,” Memorandum from Michael H. Shapiro, Acting Assistant Administrator for Air and Radiation, September 17, 1993 (hereinafter referred to as the “Shapiro Memorandum”);
8. “Use of Actual Emissions in Maintenance Demonstrations for Ozone and CO Nonattainment Areas,” Memorandum from D. Kent Berry, Acting Director, Air Quality Management Division, November 30, 1993;
9. “Part D New Source Review (Part D NSR) Requirements for Areas Requesting Redesignation to Attainment,” Memorandum from Mary D. Nichols, Assistant Administrator for Air and Radiation, October 14, 1994 (hereinafter referred to as the “Nichols Memorandum”); and
10. “Reasonable Further Progress, Attainment Demonstration, and Related Requirements for Ozone Nonattainment Areas Meeting the Ozone National Ambient Air Quality Standard,” Memorandum from John S. Seitz, Director, Office of Air Quality Planning and Standards, May 10, 1995.
On September 6, 2022, Kentucky requested that EPA redesignate the Louisville, KY Area to attainment for the 2015 8-hour ozone NAAQS and approve the associated SIP revision submitted on the same date containing a maintenance plan for the Area. EPA's evaluation indicates that the Louisville, KY Area meets the requirements for redesignation as set forth in CAA section 107(d)(3)(E), including the maintenance plan requirements under CAA section 175A and associated MVEBs. As a result of these proposed findings, EPA is proposing to take the actions summarized in Section I of this notice. EPA's analysis and rationale for this proposal is provided below.
As stated above, in accordance with the CAA, EPA proposes to approve the 2015 8-hour ozone NAAQS maintenance plan, including the associated MVEBs, and incorporate it into the Kentucky SIP, and to redesignate the Louisville, KY Area to attainment for the 2015 8-hour ozone NAAQS. The five redesignation criteria provided under CAA section 107(d)(3)(E) are discussed in greater detail for the Area in the following paragraphs of this section.
For redesignating a nonattainment area to attainment, the CAA requires EPA to determine that the area has attained the applicable NAAQS.
EPA reviewed complete, quality-assured, and certified ozone monitoring data from monitoring stations in the Louisville, KY-IN Area for the 2015 8-hour ozone NAAQS for 2019 through 2021 and has determined that the design values for each monitor in the Louisville, KY-IN Area are equal to or less than the standard of 0.070 ppm for that time period. Based on this air quality monitoring data, EPA is proposing to determine that the Louisville, KY-IN Area has attained the 2015 8-hour ozone NAAQS. The fourth-highest 8-hour ozone values at each monitor for 2019 through 2021 and the 3-year averages of these values (
The highest
For redesignating a nonattainment area to attainment, the CAA requires EPA to determine that the state has met all applicable requirements under section 110 and part D of title I of the CAA,
Section 110(a)(2)(D)(i)(I) of the Act, referred to as the “good neighbor provision” or the “interstate transport provision,” requires that SIPs contain measures to prevent sources in a state from significantly contributing to air quality problems in another state. To implement this provision, EPA has required certain states to establish programs to address the interstate transport of air pollutants. The section 110(a)(2)(D)(i)(I) requirements for a state are not linked with a particular nonattainment area's designation and classification in that state. EPA believes that the requirements linked with a particular nonattainment area's designation and classification are the relevant measures to evaluate in reviewing a redesignation request. The transport SIP submittal requirements, where applicable, continue to apply to a state regardless of the designation of any one particular area in the state. Thus, EPA does not believe that the CAA's interstate transport requirements should be construed to be applicable for purposes of redesignation.
In addition, EPA believes other section 110 elements that are neither connected with nonattainment plan submissions nor linked with an area's attainment status are not applicable requirements for purpose of redesignation. The area will still be subject to these requirements after the area is redesignated. The section 110 and part D requirements which are linked with a particular area's designation and classification are the relevant measures to evaluate in reviewing a redesignation request. This approach is consistent with EPA's existing policy on applicability (
Under its longstanding interpretation of the CAA, EPA has interpreted section 107(d)(3)(E) to mean, as a threshold matter, that the part D provisions which are “applicable” and which must be approved in order for EPA to redesignate an area include only those which came due prior to a state's submittal of a complete redesignation request.
Under section 182(a)(2)(A), states with ozone nonattainment areas that were designated prior to the enactment of the 1990 CAA amendments were required to submit, within six months of classification, all rules and corrections to existing VOC reasonably available control technology (RACT) rules that were required under section 172(b)(3) of the CAA (and related guidance) prior to the 1990 CAA amendments. The Area is not subject to the section 182(a)(2) RACT “fix up” requirement for the 2015 ozone NAAQS because it was designated as nonattainment for this standard after the enactment of the 1990 CAA amendments. Furthermore, the Commonwealth complied with this requirement under the 1-hour ozone NAAQS for the Jefferson County, Kentucky, portion of the Louisville, KY-IN Area.
Section 182(a)(2)(B) requires each state with a Marginal or higher ozone nonattainment area classification that implemented, or was required to implement, a vehicle inspection and maintenance (I/M) program prior to the 1990 CAA amendments to submit a SIP revision providing for an I/M program no less stringent than that required prior to the 1990 amendments or already in the SIP at the time of the amendments, whichever is more stringent. The Louisville, KY Area is not subject to the section 182(a)(2)(B) requirement because the Area was designated as nonattainment for the 2015 8-hour ozone standard after the enactment of the 1990 CAA amendments.
Regarding the permitting and offset requirements of section 182(a)(2)(C) and section 182(a)(4), Kentucky currently has a fully approved part D NSR program in place. However, EPA has determined that areas being redesignated need not comply with the requirement that a NSR program be approved prior to redesignation, provided that the area demonstrates maintenance of the NAAQS without part D NSR, because PSD requirements will apply after redesignation. A more detailed rationale for this view is described in the Nichols Memorandum. Kentucky's PSD program will become applicable in the Louisville, KY Area upon redesignation to attainment.
Section 182(a)(3) requires states to submit periodic inventories and emissions statements. Section 182(a)(3)(A) requires states to submit a periodic inventory every three years. As discussed below in the section of this notice titled
EPA interprets the conformity SIP requirements
Thus, for the reasons discussed above, EPA proposes to find that the Louisville, KY Area has satisfied all applicable requirements for purposes of redesignation under section 110 and part D of title I of the CAA.
EPA has fully approved the applicable Kentucky SIP for the Louisville, KY Area under section 110(k) of the CAA for all requirements applicable for purpose of redesignation. EPA may rely on prior SIP approvals in approving a redesignation request,
For redesignating a nonattainment area to attainment, the CAA requires EPA to determine that the air quality improvement in the area is due to permanent and enforceable reductions in emissions resulting from implementation of the SIP, applicable Federal air pollution control regulations, and other permanent and enforceable reductions.
State measures adopted into the SIP and Federal measures enacted in recent years have resulted in permanent emission reductions. Kentucky's September 6, 2022, submittal identifies SIP-approved state measures, some of which implement Federal requirements, that have been implemented to date.
Additionally, Federal measures enacted in recent years have also resulted in permanent emission reductions in the Louisville, KY Area. The Federal measures that have been implemented include the following.
EPA issued the Safer Affordable Fuel-Efficient (SAFE) Vehicles Rule on March 20, 2020, as an update to Phase 2. This new standard sets fuel economy and CO
On December 30, 2021, EPA published the
The group of CSAPRs addressed the 1997 ozone and PM
EPA proposes to find that the improvements in air quality in the Louisville, KY Area are due to real, permanent and enforceable reductions in NO
For redesignating a nonattainment area to attainment, the CAA requires EPA to determine that the area has a fully approved maintenance plan pursuant to section 175A of the CAA.
Section 175A of the CAA sets forth the elements of a maintenance plan for areas seeking redesignation from nonattainment to attainment. Pursuant to section 175A, the plan must demonstrate continued attainment of the applicable NAAQS for at least 10 years after the Administrator approves a redesignation to attainment. Eight years after the redesignation, the state must submit a revised maintenance plan which demonstrates that attainment will continue to be maintained for the remainder of the 20-year period following the initial 10-year period. To address the possibility of future NAAQS violations, the maintenance plan must contain contingency measures as EPA deems necessary to assure prompt correction of any future 2015 8-hour ozone violations. The Calcagni Memorandum provides further guidance on the content of a maintenance plan, explaining that a maintenance plan should address five requirements: the attainment emissions inventory, maintenance demonstration, monitoring plan, verification of continued attainment, and a contingency plan. As discussed more fully below, EPA has
As discussed above, the Louisville, KY-IN Area has an attaining design value for the 2015 8-hour ozone NAAQS based on quality-assured monitoring data for the 3-year period from 2019-2021.
The emissions inventory is composed of four major types of sources: Point, non-point, on-road, and non-road mobile. Complete descriptions of how the Commonwealth developed these inventories are located in Appendices A, B, C, and D of the September 6, 2022, SIP submittal.
For point sources, Kentucky developed the 2019 attainment year inventory using emissions collected by the District and the Division directly for all sources, with the exception of airports and railyards, which were developed using the 2017 NEI.
To calculate tons per ozone season/tons per summer day (tpsd) emissions, Kentucky used two methods, depending on whether a source reported seasonal operations or annual operations. With respect to point sources in the Louisville, KY Area that reported seasonal operations, Kentucky used that seasonal data to calculate summer emissions by dividing by 92 days (for the summer months of June, July and August). With respect to sources reporting annual data, Kentucky calculated tons per summer day emissions were by dividing annual emissions by four and then by the 92 days of summer.
In order to develop projected year emissions, Kentucky used EPA's 2016v2 modeling platform. The 2016v1 emissions modeling platform is a product from the National Emissions Inventory Collaborative, a collaboration between state and regional air agencies, EPA, and Federal Land Management agencies, and includes a full suite of base year (2016) and projection year (2023 and 2028) inventories, ancillary emission data, and scripts and software for preparing the emissions for air quality modeling. The 2016v2 emissions modeling platform was developed by EPA as an update to the 2016v1 platform because new data, model versions, and methods became available following the release of 2016v1.
For non-point sources, the 2019 attainment year inventory was developed using the 2017 NEI and with future year inventories from the EPA 2016v2 modeling platform and Microsoft TREND Function (linear regression). The 2019 emissions were interpolated based on 2017 NEI emissions and 2023, 2028, and 2032 projected emissions.
EPA's 2016v2 was used to develop non-point projected year emissions in the same manner as described above for point sources.
The 2019 on-road emissions in the Kentucky submittal and all projected years inventories were developed using the most recent information from the travel demand model (TDM) designed by Kentuckiana Regional Planning and Development Agency (KIPDA) and data obtained from EPA MOVES3 (Motor Vehicle Emissions Simulator).
Some non-road mobile emissions in the U.S. are from the non-road equipment segment (
The 2019 base year inventory for the Area, as well as the projected
The redesignation request includes a maintenance plan which includes the following features:
(i) Shows compliance with and maintenance of the 2015 8-hour ozone NAAQS by providing information to support the demonstration that current and future emissions of NO
(ii) Uses 2019 as the attainment year and includes future emissions inventory projections for 2025, 2030, and 2035. The 2019 emissions were calculated by linear interpolation between 2017 and 2023. Emissions for 2025, 2030, and 2035 were calculated by linear interpolation using 2023, 2026 and 2032.
(iii) Identifies an “out year” at least 10 years after the time necessary for EPA to review and approve the maintenance plan. Per 40 CFR part 93, NO
(iv) Provides actual (2019) and projected emissions inventories, in tpsd, for the Louisville, KY Area, as shown in Tables 2 and 3, below.
Tables 2 and 3 summarize the 2019 and future projected emissions of NO
As discussed in Section VI, below, a safety margin is the difference between the attainment level of emissions (from all sources) and the projected level of emissions (from all sources) in the maintenance plan. The attainment level of emissions is the level of emissions during one of the years in which the area met the NAAQS. Kentucky selected 2019 as the attainment emissions inventory year for the Louisville, KY Area and calculated safety margins for 2035 (see Table 4). Because the interim MVEB year of 2019 is also the base year for the maintenance plan inventory, there is no safety margin for 2019; therefore, no adjustments were made to the MVEBs for 2019. Kentucky, in consultation with the Louisville, KY-IN Area transportation partners, allocated a portion of the available safety margin to the 2035 MVEBs for the entire Louisville, KY-IN Area.
Kentucky has allocated 2.98 tpsd (9.9 percent) of the available NO
There are seven ozone monitors in the Louisville, KY-IN Area; five in the Kentucky portion and two in the Indiana portion. Kentucky will continue to operate the monitors in the Kentucky portion of the Louisville, KY-IN Area in compliance with 40 CFR part 58 and has thus addressed the requirement for the monitoring. EPA approved Kentucky's 2021 ambient air monitoring network plan on October 27, 2021.
Kentucky, through the Cabinet and District, has the legal authority to enforce and implement the maintenance plan for the Area. This includes the authority to adopt, implement, and enforce any subsequent emissions control contingency measures determined to be necessary to correct future ozone attainment problems.
Additionally, under the Air Emissions Reporting Requirements (AERR) (40 CFR part 51, subpart A), every three years the Cabinet and Division are required to develop a comprehensive, annual, statewide emissions inventory that is due twelve to eighteen months after the completion of the inventory year. Both the Cabinet and Division will update the AERR inventory every three years and will use the updated emissions inventory to track the progress of maintenance of the NAAQS. The maintenance plan states that emissions information will be compared to the 2019 attainment year and the 2035 projected maintenance year inventories to assess emission trends, as necessary, and to assure continued compliance with the standard.
Section 175A of the CAA requires that a maintenance plan include such contingency measures as EPA deems necessary to assure that the state will promptly correct a violation of the NAAQS that occurs after redesignation. The maintenance plan should identify the contingency measures to be adopted, a schedule and a procedure for adoption and implementation, and a time limit for action by the state. A state should also identify specific indicators to be used to determine when the contingency measures need to be implemented. The maintenance plan must include a requirement that a state will implement all measures with respect to control of the pollutant that were contained in the SIP before redesignation of the area to attainment in accordance with section 175A(d).
In the September 6, 2022, submittal, Kentucky states that, at a minimum, contingency measures must include all measures with respect to the control of ozone contained in the SIP for the Area before the redesignation, that all such measures are in effect for the Area, and that DAQ and the District will continue to implement these measures. The contingency measures in the maintenance plan include a two-tiered triggering mechanism to determine when contingency measures are needed and a process of developing and implementing appropriate control measures.
Kentucky refers to the first-tier response as an “indicator” response. An indicator response is triggered if (1) there is an annual fourth high monitored value of 0.071 ppm or greater in a single ozone season or (2) periodic emission inventory updates reveal excessive or unanticipated growth greater than 10 percent in ozone precursor emissions within the Area. For the indicator response, Kentucky will evaluate existing control measures to see if further emission reduction measures should be implemented. Kentucky commits to implementing necessary controls as expeditiously as possible, but no later than 12 months from the conclusion of the most recent ozone season (October 31).
Kentucky refers to the second-tier response as an “action level response.” The action level trigger is the occurrence of a three-year average of the fourth highest monitored value of 0.071 ppm or greater (
Kentucky states that potential contingency measures may be chosen from the following list; however, the Commonwealth and the District reserve the right to implement other contingency measures if new control programs should be developed and deemed more advantageous for the Area:
• Implementation of a program to require additional emission reductions on stationary sources, including RACT for point sources of VOC and NO
• Implementation of a program to enhance inspection of stationary sources;
• Implementation of fuel programs, including incentives for alternative fuels;
• Restriction of certain roads or lanes to, or construction of such roads or lanes for use by, passenger buses or high-occupancy vehicles;
• Trip-reduction ordinances;
• Employer-based transportation management plans, including incentives;
• Programs for new construction and major reconstructions of paths or tracks for use by pedestrians or by non-motorized vehicles when economically feasible and in the public interest;
• Implementation of a modern vehicle inspection/maintenance program;
• Implementation of diesel retrofit programs, including incentives for performing retrofits for fleet vehicle operations; and
• Additional engine idling reduction programs.
EPA preliminarily finds that the maintenance plan adequately provides the five basic required components of a maintenance plan: the attainment emissions inventory, maintenance demonstration, monitoring plan, verification of continued attainment, and a contingency plan. Therefore, EPA proposes to find that the maintenance plan SIP revision submitted by Kentucky for the Louisville, KY Area meets the requirements of section 175A of the CAA and is approvable.
Under section 176(c) of the CAA, new transportation plans, programs, and projects, such as the construction of new highways, must “conform” to (
Under the CAA, states are required to submit at various times control strategy SIPs and maintenance plans for nonattainment areas. These control strategy SIPs (including reasonable further progress and attainment demonstration requirements) and maintenance plans create MVEBs for criteria pollutants and/or their precursors to address pollution from cars and trucks. Per 40 CFR part 93, a MVEB must be established for the last year of the maintenance plan. A state may adopt MVEBs for other years as well. The MVEB is the portion of the total allowable emissions in the maintenance demonstration that is allocated to highway and transit vehicle use and emissions.
After interagency consultation with the transportation partners for the Louisville, KY-IN Area, MVEBs for NO
Kentucky, in consultation with the transportation partners for the Louisville, KY-IN Area chose to allocate a portion of the available safety margin to the 2035 NO
Through this proposed rulemaking, EPA is proposing to approve the MVEBs for NO
When reviewing submitted “control strategy” SIPs or maintenance plans containing MVEBs, EPA may affirmatively find the MVEB contained therein adequate for use in determining transportation conformity. Once EPA affirmatively finds the submitted MVEB is adequate for transportation conformity purposes, that MVEB must be used by state and federal agencies in determining whether proposed transportation projects conform to the SIP as required by section 176(c) of the CAA.
EPA's substantive criteria for determining adequacy of a MVEB are set out in 40 CFR 93.118(e)(4). The process for determining adequacy consists of three basic steps: public notification of a SIP submission, a public comment period, and EPA's adequacy determination. This process for determining the adequacy of submitted MVEBs for transportation conformity purposes was initially outlined in EPA's May 14, 1999, guidance, “Conformity Guidance on Implementation of March 2, 1999, Conformity Court Decision.” EPA adopted regulations to codify the adequacy process in the Transportation Conformity Rule Amendments for in an action titled “New 8-Hour Ozone and PM
As discussed earlier, Kentucky's maintenance plan includes NO
EPA's proposed actions establish the basis upon which EPA may take final action on the issues being proposed for approval. Approval of Kentucky's redesignation request would change the legal designation of Bullitt, Jefferson, and Oldham Counties, found at 40 CFR part 81, from nonattainment to attainment for the 2015 8-hour ozone NAAQS. Approval of Kentucky's associated SIP revision would also incorporate a plan for maintaining the 2015 8-hour ozone NAAQS in the Area through 2035 into the Kentucky SIP. The maintenance plan establishes NO
EPA is proposing to: (1) approve the maintenance plan for the Louisville, KY Area, including the NO
If finalized, approval of the redesignation request would change the official 2015 8-hour ozone NAAQS designation of Bullitt, Jefferson, and Oldham Counties in Kentucky from nonattainment to attainment, as found at 40 CFR part 81.
Under the CAA, redesignation of an area to attainment and the accompanying approval of a maintenance plan under section 107(d)(3)(E) are actions that affect the status of a geographical area and do not impose any additional regulatory requirements on sources beyond those imposed by state law. A redesignation to attainment does not in and of itself create any new requirements, but rather results in the applicability of requirements contained in the CAA for areas that have been redesignated to attainment. Moreover, the Administrator is required to approve a SIP submission that complies with the provisions of the Act and applicable Federal regulations.
• Are not significant regulatory actions 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);
• Do not impose an information collection burdens under the provisions of the Paperwork Reduction Act (44 U.S.C. 3501
• Are 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
• Do 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);
• Do not have Federalism implications as specified in Executive Order 13132 (64 FR 43255, August 10, 1999);
• Are not economically significant regulatory actions based on health or safety risks subject to Executive Order 13045 (62 FR 19885, April 23, 1997);
• Are not significant regulatory actions subject to Executive Order 13211 (66 FR 28355, May 22, 2001); and
• Are 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.
In addition, the SIP is not approved to apply on any Indian reservation land or in any other area where EPA or an Indian tribe has demonstrated that a tribe has jurisdiction. In those areas of Indian country, the rules do not have tribal implications as specified by Executive Order 13175 (65 FR 67249, November 9, 2000).
Executive Order 12898 (Federal Actions To Address Environmental Justice in Minority Populations and Low-Income Populations, 59 FR 7629, Feb. 16, 1994) directs Federal agencies to identify and address “disproportionately high and adverse human health or environmental effects” of their actions on minority populations and low-income populations to the greatest extent practicable and permitted by law. EPA defines environmental justice (EJ) as “the fair treatment and meaningful involvement of all people regardless of race, color, national origin, or income with respect to the development, implementation, and enforcement of environmental laws, regulations, and policies.” EPA further defines the term fair treatment to mean that “no group of people should bear a disproportionate burden of environmental harms and risks, including those resulting from the negative environmental consequences of industrial, governmental, and commercial operations or programs and policies.”
The Cabinet and District did not evaluate EJ considerations as part of its redesignation request or SIP submittal; the CAA and applicable implementing regulations neither prohibit nor require such an evaluation. EPA did not perform an EJ analysis and did not consider EJ as part of Kentucky's redesignation request or SIP submittal in these actions. Consideration of EJ is not required as part of these actions, and there is no information in the record inconsistent with the stated goal of E.O. 12898 of achieving EJ for people of color, low-income populations, and Indigenous peoples.
Environmental protection, Air pollution control, Carbon monoxide, Incorporation by reference, Intergovernmental relations, Nitrogen dioxide, Ozone, Reporting and recordkeeping requirements, Volatile organic compounds.
Environmental protection, Air pollution control, National parks, Wilderness areas.
42 U.S.C. 7401
National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.
Proposed rule; request for comments.
This rulemaking proposes fishing year 2023 recreational management measures for Georges Bank cod, Gulf of Maine cod, and Gulf of Maine haddock. The measures are intended to ensure the recreational fishery achieves, but does not exceed, fishing year 2023 catch limits for Gulf of Maine cod and haddock, and the recreational catch target for Georges Bank cod.
Comments must be received by 5 p.m. EST on May 3, 2023.
You may submit comments on this document, identified by NOAA-NMFS-2023-0054, by either of the following methods:
•
To review
Kyle Molton, Fishery Management Specialist, (978) 281-9236.
The recreational fishery for Gulf of Maine (GOM) cod and GOM haddock is managed under the Northeast Multispecies Fishery Management Plan (FMP). The multispecies fishing year starts on May 1 and runs through April 30 of the following calendar year. The FMP sets sub-annual catch limits (sub-ACL) for the recreational fishery each fishing year for both stocks. These sub-ACLs are a fixed proportion of the overall catch limit for each stock. The FMP also includes proactive recreational accountability measures (AM) to prevent the recreational sub-ACLs from being exceeded and reactive AMs to correct the cause or mitigate the effects of an overage if one occurs.
The proactive AM provision in the FMP provides a process for the Regional Administrator, in consultation with the New England Fishery Management Council (Council), to develop recreational management measures for the upcoming fishing year to ensure that the recreational sub-ACL is achieved, but not exceeded. The provisions governing this action can be found in the FMP's implementing regulations at 50 CFR 648.89(f)(3).
The 2023 recreational sub-ACL for GOM cod established by Framework Adjustment 63 (87 FR 42375; July 15, 2022), is 192 mt, the same as the 2022 recreational sub-ACL. The Council included in Framework Adjustment 65 a 610 mt recreational sub-ACL for GOM haddock. The Council-recommended 2023 sub-ACL for GOM haddock would be reduced from 3,634 mt in 2022, a reduction of approximately 83 percent. This rule does not set sub-ACLs for any stocks; the Council recommended sub-ACLs for Framework Adjustment 65 will be considered in a separate rulemaking.
Using the Council-recommended GOM cod and GOM haddock 2023 sub-ACLs and a peer-reviewed bio-economic model developed by NMFS's Northeast Fisheries Science Center that predicts fishing behavior under different management measures, we estimated 2023 recreational GOM cod and haddock removals under several combinations of minimum sizes, slot limits, possession limits, and closed seasons. The bio-economic model considers measures for the two stocks in conjunction because cod are commonly caught while recreational participants are targeting haddock, linking the catch and effort for each stock to the other. The bio-economic model results suggest that measures for GOM cod can be liberalized slightly without the 2023 recreational fishery's sub-ACL being exceeded. However, the model also suggests that status quo measures for GOM haddock would result in catch exceeding the Council-recommended recreational sub-ACL. With any given model, however, there exists some level of uncertainty in the accuracy of model predictions. As in past years, we used preliminary data from the Marine Recreational Information Program (MRIP) for this fishing year. Incorporation of new waves, or data updates, may result in changes in model estimates. MRIP data can be uncertain and highly variable from year to year.
For each of the sets of management measures, 100 simulations of the bio-economic model were conducted, and the number of simulations which yielded recreational mortality estimates under the sub-ACL was used as an estimate of the probability that the simulated set of measures will not result in an overage of the sub-ACL. Measures that do not result in model-estimated removals under the sub-ACL greater than 50 percent of the time are generally considered unsatisfactory. The results of initial bio-economic model runs were shared with the Council and its Recreational Advisory Panel (RAP) and Groundfish Committee for review at their January meetings.
The RAP and Groundfish Committee were presented with options that reduced the GOM haddock limit to 10 fish per angler (from 20) with status quo minimum size and season. These GOM haddock measures were combined with varying GOM cod seasons, including status quo seasons (April 1-14 and September 1-October 7), an extended fall season (September 1-October 31) with a status quo April season, and an extended fall season (September 1-October 31) while eliminating the April open season (Table 1, Option 1). Each of these measures resulted in catch
The RAP and the Groundfish Committee both supported modifying the season for GOM cod, to eliminate the April open season and extend the fall season to include all of September and October. The Council also supported this approach and ultimately recommended to NMFS opening the GOM cod season from September 1 through October 31 with a 1-fish limit per angler and a 22-inch (55.9 cm) minimum size. These measures are expected to adequately constrain recreational catch of GOM cod based on bio-economic model estimates. We are proposing these Council-recommended measures for GOM cod for fishing year 2023 (Table 1).
For GOM haddock, the RAP was interested in exploring options that would allow a higher limit than the 10-fish limit options presented. RAP members noted that in order to preserve bookings for party and charter operators, a higher 15-fish bag limit would be appropriate; however, they acknowledged that a higher minimum size would be needed to offset any increase in the limit above 10-fish. As a result, the RAP recommended to the Groundfish Committee a 15-fish limit for GOM haddock with a status quo season, but an increase in the minimum size to 18 inches (45.7 cm), or larger, if needed (from 17 inches (43.2 cm)). The Groundfish Committee forwarded the RAP recommendation to the Council, but also forwarded additional options to the Council for consideration, including a 15-fish limit for GOM haddock with an 18-inch (45.7 cm) minimum size and a closure for March and April (only March is currently closed to GOM haddock harvest) to further limit haddock catch if needed. The Committee also asked the Council to consider additional options including a 17-inch (43.2-cm) minimum size for GOM haddock. The RAP and Committee options were analyzed using the bio-economic model and results were presented to the Council at its January meeting.
The Council discussed the RAP and Groundfish Committee discussion and recommendations regarding GOM haddock at their meeting on January 25, 2023. The bio-economic model results showed that the RAP motion for a status quo GOM haddock season (March closed), a 15-fish limit, and an 18-inch (45.7-cm) minimum size would result in catch well below the sub-ACL (Table 1, Option 2), with expected catch approximately 154 mt lower than a 10-fish limit and 17-inch (43.2-cm) minimum size. The RAP preferred option would also result in approximate 50 mt of additional dead discards due to added mortality of discarded fish under the 18-inch (45.7-cm) minimum size. Options that would close the month of May would result in even further unnecessary reductions in catch of GOM haddock if an 18-inch (45.7-cm) minimum size were implemented. The model also showed that a 15-fish limit coupled with a 17-inch (43.2-cm) minimum size and a March and April closure would also adequately reduce catch, but a 15-fish limit and 17-inch (43.2-cm) minimum size with only March closed would not. While concerns about increasing dead discards with a higher 18-inch (45.7-cm) minimum size where discussed, the Council ultimately recommended the same measures as the RAP for GOM haddock: A status quo season (March closed); a 15-fish limit; and an 18-inch (45.7-cm) minimum size (Table 1, Option 2).
The Council-recommended measures for GOM haddock are very likely to result in catch below the recreational sub-ACL (Table 1, Option 2); however, we are concerned that the Council recommended measures are expected to unnecessarily constrain catch and increase dead discards of GOM haddock compared to other options with a 17-inch (43.2- m) minimum size 10-fish bag limit (Table 1, Option 1). While charter and party vessels may benefit from a 15-fish limit, and may be able to effectively target haddock over 18 inches (45.7 cm), the GOM haddock stock is dominated by relatively young year classes of haddock that are beginning to recruit to the fishery. Advisors on the RAP have suggested that private anglers are more likely to fish closer to shore than for-hire vessels, and therefor may encounter fewer large haddock, which would be problematic under an 18-inch minimum (45.7 cm) size. Smaller haddock are subject to higher discard mortality, especially during the summer and fall months than larger haddock so an increase in discards would convert the majority of potential landings of haddock between 17 and 18 inches (43.2 and 45.7 cm, respectively) into dead discards. While the bio-economic model cannot currently be used to specifically evaluate mode-based measures, the model results suggest that an overall 10-fish limit at 17 inches (43.2 cm) (Table 1, Option 1) would result in higher landings, lower dead discards, more fishing trips, and higher angler satisfaction compared to a 15-fish limit with an 18-inch (45.7 cm) minimum size (Table 1, Option 2), with a very small increase in the risk of exceeding the recreational sub-ACL. Additionally, while a 15-fish limit may result in higher bookings for party and charter vessels, data show that only a small proportion of anglers or trips actually harvest 10 or more haddock per angler; increasing the minimum size from 17 to 18 inches (43.2 and 45.7 cm, respectively) is expected to further reduce the number of haddock harvested per angler. In fishing year 2022, the average number of haddock harvested on angler trips targeting cod or haddock was just 2.3 haddock per angler, 3.6 per angler on for-hire trips, and 2.2 per angler on private trips.
As a result of these concerns, we are proposing to implement the Council-recommended measures for the for-hire angling mode (March closure, 15-fish limit, 18-inch (45.7 cm) minimum size) but proposing alternative measures for the private angling mode. We are proposing to implement a status quo season (March closure), a 10-fish limit, and a 17-inch (43.2 cm) minimum size for the private angling mode (Table 1, Option 3). These mode-based measures are intended to balance the different needs of the for-hire mode and the private mode, where a larger bag limit may be helpful to encourage for-hire bookings. In addition to the proposed measures, we are also soliciting public comment on the Council-recommended measures (Table 1, Option 2), and an additional option originally presented to the RAP and Groundfish Committee that also retains the status quo season and minimum size (17 inches (43.2 cm)) for GOM haddock but would establish a 10-fish limit for both the for-hire and private mode (Table 1, Option 1). We are especially interested in public comments that would allow us to better evaluate the potential tradeoffs between a 10-fish limit with a 17-inch (43.2 cm) minimum size and a 15-fish limit with an 18-inch (45.7 cm) minimum size, including angler preferences for haddock size and bag limits, and considerations when booking for-hire trips.
Similar to the recreational fishery for GOM cod and haddock, GB cod is managed under the Northeast Multispecies FMP and the fishing year starts on May 1 and runs through April 30 of the following calendar year. Unlike GOM cod and haddock the FMP does not set a sub-ACL for the recreational fishery each fishing year for GB cod. Instead, the Council establishes a recreational annual catch target for GB cod. The catch target is not an allocation or sub-ACL but sets an expectation for recreational catch for the fishing year for management purposes that is not expected to result in an overage of the overall GB cod ACL. After considering a number of catch target options, the Council recommended a catch target of 113 mt in Framework Adjustment 65, which will be considered in a separate rulemaking.
The FMP provides a process for the Regional Administrator, in consultation with the Council, to develop recreational management measures for GB cod for fishing years 2023 and 2024 to prevent the recreational fishery from exceeding the annual recreational catch target for GB. The provisions governing this authority can be found in the FMP's implementing regulations at 50 CFR 648.89(g).
Unlike GOM cod and haddock, there is not currently a peer-reviewed bio-economic model available to evaluate the potential impacts of various recreational measures for GB cod. Instead, the RAP, Groundfish Committee, and Council were presented with catch data from recent fishing years and a projection of fishing year 2022 expected catch. Measures were then evaluated based on estimates of the percent reduction in catch from the fishing year 2022 projection. The 2022 catch projection is 218 mt, so a harvest reduction of approximately 48 percent would be required to remain below the Council recommended catch target of 113 mt in fishing year 2023.
Current measures for GB cod include a closed season from May 1 through July 31, a 5-fish limit, and a slot limit with a 22-inch (55.9 cm) minimum size and a 28-inch (71.1 cm) maximum size (Table 2). These measures where implemented as part of Framework Adjustment 63 on July 15, 2022 (87 FR 42375; July 15, 2022), so they were not in place for the full fishing year in 2022. If status quo measures were in place for the full fishing year in 2023, a landings reduction of about 28 percent would be expected if all states implemented complementary measures based on catch during periods when status quo measures would close the fishery in 2023. In fishing year 2022 two states with significant GB cod catch, New York and New Jersey, did not implement complementary state measures. Should any state, particularly those with significant GB cod catch, not implement complementary state measures in 2023, this may lead to regulatory confusion, as federally-permitted for-hire vessels and all vessels fishing in Federal waters must comply with Federal regulations but for hire vessels not holding a Federal multispecies permit and private recreational vessels fishing exclusively in state waters would be subject to state regulations only.
The Council discussed alternative options to further reduce GB cod catch including increases to the minimum size with and without a maximum size limit. The Council also looked at potential modifications to the open season to further reduce catch. The Council ultimately recommended eliminating the maximum size limit (slot), increasing the minimum size from 22 to 23 inches (55.9 to 58.4 cm, respectively), and shifting the closed season back 1 month to close June, July, and August instead of May, June, and July (Table 2). The Council-recommended measures are expected to reduce catch approximately 48 percent from fishing year 2022 to 2023 (Table 2).
We are proposing to implement the Council's recommended recreational measures for GB cod for fishing year 2023 (Table 2). Based on a review of recent catch data these measures are expected to adequately constrain total catch to the Council-recommended catch target. While there is uncertainty as to whether the states of New York and New Jersey will implement complementary measures in their state waters for GB cod, Council and NMFS staff are working with both states to encourage adoption of complementary measures. We will also conduct outreach to the recreational communities in all affected states regarding Federal measures for GB cod, which is expected to increase awareness of Federal measures, reduce regulatory confusion among anglers, and increase the effectiveness of proposed measures.
NMFS is issuing this proposed rule pursuant to section 305(d) of the Magnuson-Stevens Act. The reason for using this regulatory authority is: In a previous action taken pursuant to section 304(b), the Council designed the FMP to authorize NMFS to take this action pursuant to MSA section 305(d). See 50 CFR 648.89(f)(3) and (g). The NMFS Assistant Administrator has determined that this proposed rule is consistent with the Northeast Multispecies FMP and other applicable law, subject to further consideration after public comment.
Due to timing constraints resulting from the Council-recommend measures being finalized on January 25, 2023, NMFS is providing a 15-day comment period. This rulemaking proposes modifications to management measures for GOM cod and haddock and GB cod under existing NMFS authority to implement annual recreational fishing measures, in consultation with the Council. The Northeast multispecies fishing year begins on May 1 of each year and continues through April 30 of the following calendar year. Delaying final action on these proposed measures to allow for a longer comment period than the minimum 15-day amount allowed for by the Magnuson-Stevens Act would result in significant regulatory confusion for the industry and has the potential to negatively impact for-hire fishing business operations and bookings. Delayed
The Chief Counsel for Regulation of the Department of Commerce certified to the Chief Counsel for Advocacy of the Small Business Administration that this proposed rule, if adopted, would not have a significant economic impact on a substantial number of small entities.
For RFA purposes only, NMFS established a small business size standard for businesses, including their affiliates, whose primary industry is commercial fishing (see 50 CFR 200.2). A business primarily engaged in commercial fishing (NAICS code 11411) is classified as a small business if it is independently owned and operated, is not dominant in its field of operation (including its affiliates), and has combined annual receipts less than $11.0 million for all its affiliated operations worldwide. A small for-hire recreational fishing business is defined as a firm with receipts of up to $8.0 million. Having different size standards for different types of fishing activities creates difficulties in categorizing businesses that participate in multiple fishing related activities. For purposes of this assessment, business entities have been classified into the SBA-defined categories based on which activity produced the highest percentage of average annual gross revenues from 2019-2021, the most recent 3-year period for which data are available. This classification is now possible because vessel ownership data are included in the Northeast permit database. The ownership data identify all individuals who own fishing vessels. Using this information, vessels can be grouped together according to common owners. Each of the resulting groups was treated as a single fishing business for purposes of this analysis. Revenues summed across all vessels in a group and the activities that generate those revenues form the basis for determining whether the entity is a large or small business. As the for-hire owner is permitted and required to comply with these measures and can be held liable under the law for violations of the proposed regulations, for-hire business entities are considered directly affected in this analysis. Private anglers are not considered “entities” under the Regulatory Flexibility Act (RFA).
For-hire fishing businesses are required to obtain a Federal charter/party Northeast multispecies fishing permit in order to carry passengers to catch Northeast multispecies including cod and haddock. Limited access permit holders may also take passengers for-hire but are not allowed to hold any open access permits. Thus, the affected businesses entities of concern are businesses that hold Federal Northeast multispecies for-hire fishing permits. While all business entities that hold for-hire permits could be affected by changes in recreational fishing restrictions, not all business that hold for-hire permits actively participate in a given year. Those who actively participate,
Using vessel ownership information and vessel trip report data, it was determined that the 140 for-hire vessels actively participating in the fishery are owned by 127 unique fishing business entities. The vast majority of the 127 fishing businesses were solely engaged in for-hire fishing, but some also earned revenue from commercial shellfish and/or finfish fishing. The highest percentage of annual gross revenues for all but 12 of the fishing businesses was from for-hire fishing.
Average annual gross revenue estimates calculated from the most recent 3 years (2019-2021) indicate that none of the 127 fishing business entities had annual receipts of more than $8.0 million from all of their fishing activities (for-hire, shellfish, and finfish). Therefore, all of the affected fishing business entities are considered “small” by the SBA size standards and thus this action will not disproportionately affect small versus large for-hire business entities. The measures proposed in this action are expected to have a mixed effect on small entities because they are expected to increase opportunities to harvest GOM cod and reduce opportunities to harvest GB cod and GOM haddock, compared to status quo measures. The proposed measures balance the needs of private and for-hire anglers by providing a higher GOM haddock bag limit for for-hire to encourage bookings and offset the potential impact of reduction in overall harvest. This action is not expected to have a significant or substantial effect on small entities. Under the proposed action, small entities would not be placed at a competitive disadvantage relative to large entities, and the regulations would not substantially reduce profit for any small entities. Based on these conclusions, an initial regulatory flexibility analysis is not required and none has been prepared.
This proposed rule contains no information collection requirements under the Paperwork Reduction Act of 1995.
This proposed rule has been determined to be not significant for purposes of Executive Order 12866.
Fisheries, Fishing, Recordkeeping and reporting requirements.
For the reasons set out in the preamble, NMFS proposes to amend 50 CFR part 648 as follows:
16 U.S.C. 1801
(b) * * *
(1) * * *
(c) * * *
(1) * * *
(i) * * *
(2) * * *
The Department of Agriculture has submitted the following information collection requirement(s) to Office of Management and Budget (OMB) for review and clearance under the Paperwork Reduction Act of 1995, Public Law 104-13. Comments are requested regarding: whether the collection of information is necessary for the proper performance of the functions of the agency, including whether the information will have practical utility; the accuracy of the agency's estimate of burden including the validity of the methodology and assumptions used; ways to enhance the quality, utility and clarity of the information to be collected; ways to 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 regarding this information collection received by May 18, 2023 will be considered. Written comments and recommendations for the proposed information collection should be submitted within 30 days of the publication of this notice on the following website
An agency may not conduct or sponsor a collection of information unless the collection of information displays a currently valid OMB control number and the agency informs potential persons who are to respond to the collection of information that such persons are not required to respond to the collection of information unless it displays a currently valid OMB control number.
This FOA provides competitive cooperative agreement funding to eligible entities to ensure technical assistance and training is delivered to rural communities in need of high-speed internet and rural broadband providers. Program funds must be used to support broadband technical assistance activities which include, but are not limited to, project planning and community engagement, operations support, financial sustainability, environmental compliance, engineering, accessing federal resources, and data collection and reporting. The goal of the program is to support the expansion of high-speed internet into unserved rural communities.
Failure to collect proper information from applicants could hinder the government's selection of funding recipients, and result in improper determinations of assistance, increase legal costs to the recipients as well as encumber customer service and, ultimately, slow the deployment of assistance to rural areas in need of high-speed internet. The timing of technical assistance is critical due to the historic levels of broadband funding made available under the IIJA. The programs created and funded under the IIJA are beginning to disburse funding and technical assistance is critical to ensure unserved rural communities are able to participate in these programs, successfully implement projects and properly manage funds.
The Department of Agriculture will submit the following information collection requirement(s) to OMB for review and clearance under the Paperwork Reduction Act of 1995, Public Law 104-13 on or after the date of publication of this notice. Comments are requested regarding: (1) whether the collection of information is necessary for the proper performance of the functions of the agency, including whether the information will have practical utility; (2) the accuracy of the agency's estimate of burden 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) ways to 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 regarding these information collections are best assured of having their full effect if received by
An agency may not conduct or sponsor a collection of information unless the collection of information displays a currently valid OMB control number and the agency informs potential persons who are to respond to the collection of information that such persons are not required to respond to the collection of information unless it displays a currently valid OMB control number.
Animal and Plant Health Inspection Service, USDA.
Revision to and extension of approval of an information collection; comment request.
In accordance with the Paperwork Reduction Act of 1995, this notice announces the Animal and Plant Health Inspection Service's intention to request a revision to and extension of approval of an information collection associated with the National Veterinary Accreditation Program application form.
We will consider all comments that we receive on or before June 20, 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
For information on the National Veterinary Accreditation Program application form, contact Dr. Todd Behre, Veterinary Medical Officer, National Veterinary Accreditation Program, VS, APHIS, 4700 River Road, Unit 64, Riverdale, MD 20737; (518)-281-2157;
NVAP is a voluntary program that is administered by APHIS. As part of this program, APHIS uses an NVAP application form to collect information regarding an applicant's eligibility for accreditation and, among other things, to update an individual's contact information and renew or revise his or her accreditation status.
We are asking the Office of Management and Budget (OMB) to approve our use of this information collection activity, as described, for an additional 3 years.
The purpose of this notice is to solicit comments from the public (as well as affected agencies) concerning our information collection. These comments will help us:
(1) Evaluate whether the collection of information is necessary for the proper performance of the functions of the Agency, including whether the information will have practical utility;
(2) Evaluate the accuracy of our estimate of the burden of the collection of information, including the validity of the methodology and assumptions used;
(3) Enhance the quality, utility, and clarity of the information to be collected; and
(4) Minimize the burden of the collection of information on those who are to respond, through use, as appropriate, of automated, electronic, mechanical, and other collection technologies;
All responses to this notice will be summarized and included in the request for OMB approval. All comments will also become a matter of public record.
The Tri-Cities Airport Authority, grantee of FTZ 204, submitted a notification of proposed production activity to the FTZ Board (the Board) on behalf of GSM Engineered Fabrics, LLC, located in Kingsport, Tennessee within FTZ 204. The notification conforming to the requirements of the Board's regulations (15 CFR 400.22) was received on April 12, 2023.
Pursuant to 15 CFR 400.14(b), FTZ production activity would be limited to the specific foreign-status material(s)/component(s) and specific finished product(s) described in the submitted notification (summarized below) and subsequently authorized by the Board. The benefits that may stem from conducting production activity under FTZ procedures are explained in the background section of the Board's website—accessible via
The proposed finished products include finished industrial woven and spiral link belts (duty rate—3.8%) used in liquid and solid separation.
The proposed foreign-status materials and components include rolls of woven polyester belt material, rolls of spiral polyphenylene sulfide belt material, and adhesive tape (duty rate ranges from 3.8% to 8%). The request indicates that certain materials/components are subject to duties under section 301 of the Trade Act of 1974 (section 301), depending on the country of origin. The applicable section 301 decisions require subject merchandise to be admitted to FTZs in privileged foreign status (19 CFR 146.41).
Public comment is invited from interested parties. Submissions shall be addressed to the Board's Executive Secretary and sent to:
A copy of the notification will be available for public inspection in the “Online FTZ Information System” section of the Board's website.
For further information, contact Diane Finver at
On December 14, 2022, Par Hawaii Refining, LLC submitted a notification of proposed production activity to the FTZ Board for its facility within Subzone 9A, in Kapolei, Hawaii.
The notification was processed in accordance with the regulations of the FTZ Board (15 CFR part 400), including notice in the
On November 19, 2020, in the U.S. District Court for the Southern District of Texas, Gustavo Cavazos (“Cavazos”) was convicted of violating 18 U.S.C. 554(a). Specifically, Cavazos was convicted of smuggling firearms from the United States to Mexico without the required licenses. As a result of his conviction, the Court sentenced Cavazos to time served, three years of supervised release and a $100 assessment.
Pursuant to Section 1760(e) of the Export Control Reform Act (“ECRA”),
BIS received notice of Cavazos's conviction for violating 18 U.S.C. 554. As provided in Section 766.25 of the Export Administration Regulations (“EAR” or the “Regulations”), BIS provided notice and opportunity for Cavazos to make a written submission to BIS. 15 CFR 766.25.
Based upon my review of the record and consultations with BIS's Office of Exporter Services, including its Director, and the facts available to BIS, I have decided to deny Cavazos's export privileges under the Regulations for a period of five years from the date of
Accordingly, it is hereby
A. Applying for, obtaining, or using any license, license exception, or export control document;
B. Carrying on negotiations concerning, or ordering, buying, receiving, using, selling, delivering, storing, disposing of, forwarding, transporting, financing, or otherwise servicing in any way, any transaction involving any item exported or to be exported from the United States that is subject to the Regulations, or engaging in any other activity subject to the Regulations; or
C. Benefitting in any way from any transaction involving any item exported or to be exported from the United States that is subject to the Regulations, or from any other activity subject to the Regulations.
A. Export, reexport, or transfer (in-country) to or on behalf of the Denied Person any item subject to the Regulations;
B. Take any action that facilitates the acquisition or attempted acquisition by the Denied Person of the ownership, possession, or control of any item subject to the Regulations that has been or will be exported from the United States, including financing or other support activities related to a transaction whereby the Denied Person acquires or attempts to acquire such ownership, possession or control;
C. Take any action to acquire from or to facilitate the acquisition or attempted acquisition from the Denied Person of any item subject to the Regulations that has been exported from the United States;
D. Obtain from the Denied Person in the United States any item subject to the Regulations with knowledge or reason to know that the item will be, or is intended to be, exported from the United States; or
E. Engage in any transaction to service any item subject to the Regulations that has been or will be exported from the United States and which is owned, possessed or controlled by the Denied Person, or service any item, of whatever origin, that is owned, possessed or controlled by the Denied Person if such service involves the use of any item subject to the Regulations that has been or will be exported from the United States. For purposes of this paragraph, servicing means installation, maintenance, repair, modification or testing.
On April 24, 2019, in the U.S. District Court for the Northern District of West Virginia, Darus Zehrbach (“Zehrbach”) was convicted of violating 18 U.S.C. 1001. Specifically, Zehrbach was convicted of knowingly and willfully making a materially false, fictitious, fraudulent statement and representation, that is, the defendant stated in a letter to an agent of the United States Department of Commerce that any shipment he had caused to be made to Iran had originated in China, when the defendant then and there knew that any shipment he had caused to be made to Iran had originated in the United States, in violation of 18 U.S.C. 1001(a)(2). Zehrbach was sentenced to six months in prison, one year of supervised release and a $100 assessment.
Pursuant to Section 1760(e) of the Export Control Reform Act (“ECRA”),
BIS received notice of Zehrbach's conviction for violating 18 U.S.C. 1001. As provided in Section 766.25 of the Export Administration Regulations (“EAR” or the “Regulations”), BIS provided notice and opportunity for Zehrbach to make a written submission to BIS. 15 CFR 766.25.
Based upon my review of the record, including Mr. Zehrbach's written submission, and consultations with BIS's Office of Exporter Services, including its Director, and the facts available to BIS, I have decided to deny Zehrbach's export privileges under the Regulations for a period of 10 years from the date of Zehrbach's conviction. The Office of Exporter Services has also decided to revoke any BIS-issued licenses in which Zehrbach had an interest at the time of his conviction.
Accordingly, it is hereby
A. Applying for, obtaining, or using any license, license exception, or export control document;
B. Carrying on negotiations concerning, or ordering, buying, receiving, using, selling, delivering, storing, disposing of, forwarding, transporting, financing, or otherwise servicing in any way, any transaction involving any item exported or to be exported from the United States that is subject to the Regulations, or engaging in any other activity subject to the Regulations; or
C. Benefitting in any way from any transaction involving any item exported or to be exported from the United States that is subject to the Regulations, or from any other activity subject to the Regulations.
A. Export, reexport, or transfer (in-country) to or on behalf of the Denied Person any item subject to the Regulations;
B. Take any action that facilitates the acquisition or attempted acquisition by the Denied Person of the ownership, possession, or control of any item subject to the Regulations that has been or will be exported from the United States, including financing or other support activities related to a transaction whereby the Denied Person acquires or attempts to acquire such ownership, possession or control;
C. Take any action to acquire from or to facilitate the acquisition or attempted acquisition from the Denied Person of any item subject to the Regulations that has been exported from the United States;
D. Obtain from the Denied Person in the United States any item subject to the Regulations with knowledge or reason to know that the item will be, or is intended to be, exported from the United States; or
E. Engage in any transaction to service any item subject to the Regulations that has been or will be exported from the United States and which is owned, possessed or controlled by the Denied Person, or service any item, of whatever origin, that is owned, possessed or controlled by the Denied Person if such service involves the use of any item subject to the Regulations that has been or will be exported from the United States. For purposes of this paragraph, servicing means installation, maintenance, repair, modification or testing.
On April 6, 2021, in the U.S. District Court for the District of Arizona, Damian Espinoza-Gonzalez (“Espinoza-Gonzalez”) was convicted of violating 18 U.S.C. 371 and 18 U.S.C. 554(a). Specifically, Espinoza-Gonzalez was convicted of conspiracy and of unlawfully smuggling, and attempting to smuggle, firearms and ammunition from the United States to Mexico. As a result of his conviction, the Court sentenced Espinoza-Gonzalez to time served, 36 months of supervised release, a $200 special assessment and $1,500 criminal fine.
Pursuant to Section 1760(e) of the Export Control Reform Act (“ECRA”),
BIS received notice of Espinoza-Gonzalez's conviction for violating 18 U.S.C. 371 and 18 U.S.C. 554. As provided in Section 766.25 of the Export Administration Regulations (“EAR” or the “Regulations”), BIS provided notice and opportunity for Espinoza-Gonzalez to make a written submission to BIS. 15 CFR 766.25.
Based upon my review of the record and consultations with BIS's Office of Exporter Services, including its Director, and the facts available to BIS, I have decided to deny Espinoza-Gonzalez's export privileges under the Regulations for a period of 10 years from the date of Espinoza-Gonzalez's conviction. The Office of Exporter Services has also decided to revoke any BIS-issued licenses in which Espinoza-Gonzalez had an interest at the time of his conviction.
Accordingly, it is hereby
A. Applying for, obtaining, or using any license, license exception, or export control document;
B. Carrying on negotiations concerning, or ordering, buying, receiving, using, selling, delivering, storing, disposing of, forwarding, transporting, financing, or otherwise servicing in any way, any transaction involving any item exported or to be exported from the United States that is subject to the Regulations, or engaging
C. Benefitting in any way from any transaction involving any item exported or to be exported from the United States that is subject to the Regulations, or from any other activity subject to the Regulations.
A. Export, reexport, or transfer (in-country) to or on behalf of the Denied Person any item subject to the Regulations;
B. Take any action that facilitates the acquisition or attempted acquisition by the Denied Person of the ownership, possession, or control of any item subject to the Regulations that has been or will be exported from the United States, including financing or other support activities related to a transaction whereby the Denied Person acquires or attempts to acquire such ownership, possession or control;
C. Take any action to acquire from or to facilitate the acquisition or attempted acquisition from the Denied Person of any item subject to the Regulations that has been exported from the United States;
D. Obtain from the Denied Person in the United States any item subject to the Regulations with knowledge or reason to know that the item will be, or is intended to be, exported from the United States; or
E. Engage in any transaction to service any item subject to the Regulations that has been or will be exported from the United States and which is owned, possessed or controlled by the Denied Person, or service any item, of whatever origin, that is owned, possessed or controlled by the Denied Person if such service involves the use of any item subject to the Regulations that has been or will be exported from the United States. For purposes of this paragraph, servicing means installation, maintenance, repair, modification or testing.
On January 17, 2019, in the U.S. District Court for the District of Arizona, Katie Ellen O'Brien (“O'Brien”) was convicted of violating 18 U.S.C. 554(a) and 18 U.S.C. 1001(a)(2). Specifically, O'Brien was convicted of making false statements or misrepresentations to the U.S. Government during the course of an investigation and smuggling and attempting to smuggle firearms from the United States to Mexico. As a result of her conviction, the Court sentenced O'Brien to 60 months confinement with credit for time served, three years supervised release, and a $600 special assessment.
Pursuant to Section 1760(e) of the Export Control Reform Act (“ECRA”),
BIS received notice of O'Brien's conviction for violating 18 U.S.C. 554 and 18 U.S.C. 1001. As provided in Section 766.25 of the Export Administration Regulations (“EAR” or the “Regulations”), BIS provided notice and opportunity for O'Brien to make a written submission to BIS. 15 CFR 766.25.
Based upon my review of the record and consultations with BIS's Office of Exporter Services, including its Director, and the facts available to BIS, I have decided to deny O'Brien's export privileges under the Regulations for a period of 10 years from the date of O'Brien's conviction. The Office of Exporter Services has also decided to revoke any BIS-issued licenses in which O'Brien had an interest at the time of her conviction.
Accordingly, it is hereby
A. Applying for, obtaining, or using any license, license exception, or export control document;
B. Carrying on negotiations concerning, or ordering, buying, receiving, using, selling, delivering, storing, disposing of, forwarding, transporting, financing, or otherwise servicing in any way, any transaction involving any item exported or to be exported from the United States that is subject to the Regulations, or engaging in any other activity subject to the Regulations; or
C. Benefitting in any way from any transaction involving any item exported or to be exported from the United States that is subject to the Regulations, or from any other activity subject to the Regulations.
A. Export, reexport, or transfer (in-country) to or on behalf of the Denied Person any item subject to the Regulations;
B. Take any action that facilitates the acquisition or attempted acquisition by the Denied Person of the ownership, possession, or control of any item subject to the Regulations that has been
C. Take any action to acquire from or to facilitate the acquisition or attempted acquisition from the Denied Person of any item subject to the Regulations that has been exported from the United States;
D. Obtain from the Denied Person in the United States any item subject to the Regulations with knowledge or reason to know that the item will be, or is intended to be, exported from the United States; or
E. Engage in any transaction to service any item subject to the Regulations that has been or will be exported from the United States and which is owned, possessed or controlled by the Denied Person, or service any item, of whatever origin, that is owned, possessed or controlled by the Denied Person if such service involves the use of any item subject to the Regulations that has been or will be exported from the United States. For purposes of this paragraph, servicing means installation, maintenance, repair, modification or testing.
Office of National Marine Sanctuaries (ONMS), National Ocean Service, National Oceanic and Atmospheric Administration (NOAA), Department of Commerce.
Notice of intent to prepare a draft environmental impact statement and hold public scoping meetings; request for comments.
In accordance with the National Marine Sanctuaries Act (NMSA) and National Environmental Policy Act (NEPA), NOAA is initiating the process to consider designating the submerged lands and waters surrounding the Pacific Remote Islands to the full extent of the U.S. Exclusive Economic Zone (EEZ) as a new national marine sanctuary. NOAA will prepare a draft environmental impact statement (DEIS) for the sanctuary designation process to discuss environmental impacts and inform decision makers and the public of reasonable alternatives that would avoid or minimize adverse impacts or enhance the quality of the human environment. NOAA is initiating the public scoping process to invite comments on the scope and significance of issues to be addressed in the DEIS that are related to designating this area as a national marine sanctuary. The results of this scoping process will assist NOAA in moving forward with the designation process, which would include the preparation and release of draft designation documents, as well as the formulation of alternatives for the DEIS.
Comments must be received by NOAA on or before June 2, 2023.
Meeting times, locations, and virtual meeting links will be made available at least 15 days before each meeting, and will be posted at
You may submit comments on this notice by any of the following methods:
•
•
•
Hoku Kaaekuahiwi Pousima, (808) 731-8441,
The National Marine Sanctuaries Act, as amended (NMSA), 16 U.S.C. 1431
On March 11, 2023, the Pacific Remote Islands Coalition submitted a nomination (
On March 24, 2023, President Biden issued a Presidential Memorandum in which he directed the Secretary to consider initiating the designation of a national marine sanctuary within 30 days to provide the most comprehensive and lasting protections to the significant natural and cultural resources of the submerged lands and waters surrounding the seven islands, atolls, and the reefs of the Pacific Remote Islands Marine National Monument, both within and outside the Monument boundary, to the full extent of the seaward limit of the EEZ, including marine life, shoals, seamounts, reefs, banks, and sediments high in minerals and sequestered carbon dioxide for the benefit of present and future generations. NOAA is initiating the process to designate this area as a national marine sanctuary based on the information included in the Pacific Remote Islands Coalition nomination, as well as the information provided in the Presidential Memorandum.
The diverse and intact ecosystems of the Pacific Remote Islands, including the pelagic seascapes and underwater seamounts, support a host of species from corals and marine mammals to seabirds and deep-sea species found nowhere else in the world. Many threatened, endangered, and depleted species thrive in the area, including the green and hawksbill turtles, pearl oysters, giant clams, sharks, rays, marlin, tuna, groupers, humphead and Napoleon wrasses, bumphead parrotfish, dolphins, and whales. Intact natural ecosystems such as the Pacific Remote Islands are often more resilient to the effects of climate change and can help in the fight against biodiversity loss.
Considering sanctuary designation for the area is also an opportunity to recognize the importance of Indigenous knowledge, stories, and cultural connections between lands and peoples, and celebrate the individual nature of cultures. Although uninhabited today, for centuries wayfinders of Pacific Island Indigenous Peoples visited these islands while navigating through the expanse of the vast Pacific Ocean. Native Hawaiians, Chamorro, and other Indigenous Peoples voyaged between distant communities across this vast swath of the Central and Western Pacific, wayfinding with great proficiency using the stars, winds, and currents. Their sail routes are being used once again by contemporary open-ocean wayfinders who are reinvigorating the legacy of their ancestors. Additionally, the bravery and sacrifice of the Hui Panalā'au—a group of 130 young men, mostly Native Hawaiian, who voluntarily occupied the islands of Jarvis, Baker, and Howland from 1935 to 1942 helped secure America's territorial claim.
In 2009, President George W. Bush, through Presidential Proclamation 8336, established the Pacific Remote Islands Marine National Monument, which protected the islands, atolls, and emergent reef, and approximately 50 nautical miles of water around each. In 2014, President Barack Obama, through Presidential Proclamation 9173, expanded the Monument to include 200 nautical miles—the full extent of the EEZ—around Jarvis and Wake Islands and Johnston Atoll. The Monument is cooperatively managed by the Secretary of Commerce (NOAA) and the Secretary of the Interior (U.S. Fish and Wildlife Service). Within the boundaries of the Monument, the U.S. Fish and Wildlife Service administers National Wildlife Refuges at Baker, Howland, and Jarvis Islands; Palmyra, Johnston, and Rose Atoll; and Kingman Reef. In addition, Wake Island and Johnson Atoll are under the administrative jurisdiction of the Department of Defense.
The areas around Howland and Baker Islands, Palmyra Atoll, and Kingman Reef that are outside the Monument and National Wildlife Refuge boundaries include ecologically significant deep-water habitats and an associated array of seamounts with exceptional value for their biodiversity; spawning and feeding grounds for skipjack, yellowfin, and bigeye tuna species; and multiple apex predators that play a vital role in maintaining ecological balance and resilience of the ecosystem. Research continues to reveal the importance of these relatively unexplored habitats to the health, nutrient cycling, and carbon sequestration of the ocean.
The Pacific Remote Islands Coalition nomination and Presidential Memorandum propose that a sanctuary should encompass the areas of the marine environment within the existing Pacific Remote Islands Marine National Monument, including the marine environment surrounding Wake, Johnston, and Palmyra Atolls; Howland, Baker, and Jarvis Islands; and Kingman Reef; extending to the outer limit of the EEZ (200 nautical miles), an area totaling approximately 24 million square kilometers (770,000 square miles). Wake, Johnston, and Palmyra Atolls; Howland, Baker, and Jarvis Islands; and Kingman Reef are all unincorporated territories of the United States.
The Monument will continue to be jointly managed by the Secretary of Commerce and the Secretary of the Interior. Designation of the proposed national marine sanctuary would strengthen and increase the long-term protections already existing in the Monument, and cannot diminish them. Sanctuary designation would provide another layer of protection to continue conserving and honoring this place.
A visual of the proposed national marine sanctuary, which may be considered for sanctuary designation, can be found at
With this notice, NOAA is initiating a public scoping process to gather input from individuals, Federal, State, territorial, and local agencies, Native Hawaiian Organizations, and other representatives of Indigenous Peoples with ancestral, historic, and cultural connections to the area. NOAA intends to use this process to determine the scope of issues for analysis in the DEIS. While the public may comment on all matters relevant to the proposed designation of a national marine sanctuary in the Pacific Remote Islands, NOAA specifically requests comments on the following topics:
• the spatial extent of the proposed sanctuary, and boundary alternatives NOAA should consider;
• the location, nature, and value of resources that would be protected by a sanctuary;
• specific threats to these resources;
• the regulatory framework most appropriate for management of the proposed sanctuary;
• the non-regulatory actions NOAA should prioritize within its draft management plan for the proposed sanctuary;
• the potential socioeconomic, cultural, and biological impacts of sanctuary designation;
• information regarding historic properties in the entire area under consideration for a sanctuary designation and the potential effects to those historic properties; and
• other information relevant to the designation and management of a national marine sanctuary.
The designation process includes the following well-established and highly participatory stages:
1. Public Scoping Process—Information collection and characterization, including the consideration of public comments received during scoping, and coordination under the NMSA section 304(a)(5) with the Western Pacific Regional Fishery Management Council on the preparation of draft fishing regulations as necessary to implement the proposed designation;
2. Preparation of Draft Documents—Preparation and release of draft designation documents, including: a DEIS, prepared pursuant to NEPA, that identifies boundary and/or regulatory alternatives; a draft management plan; and a notice of proposed rulemaking to define proposed sanctuary regulations. Draft documents would be used to initiate consultations with Federal, State, territorial, or local agencies, Tribes, and other interested parties, as appropriate;
3. Public Comment—Through public meetings and in writing, allow for public review and comment on a DEIS, draft management plan, and notice of proposed rulemaking;
4. Preparation of Final Documents—Preparation and release of a final environmental impact statement (FEIS), final management plan, including a response to public comments, and a final rule and regulations.
5. Review Period—The sanctuary designation and regulations would take effect after the end of a review period of forty-five days of a continuous session of Congress.
In accordance with the NMSA, NOAA must draft an environmental impact statement pursuant to NEPA when designating a national marine sanctuary. The input gathered during the public scoping process is fundamental to NOAA's development of a DEIS.
The NMSA directs ONMS to identify and designate as national marine sanctuaries areas of the marine (including the Great Lakes) environment that are of special national significance, provides authority for comprehensive and coordinated conservation and management of these marine areas, and directs ONMS to protect the resources of these areas. The purpose and need for the proposed action is to consider whether a sanctuary designation in the Pacific Remote Islands area would fulfill the purposes and policies outlined in section 301(b) of the NMSA, 16 U.S.C. 1431(b), and meet the sanctuary designation standards in section 303 of the NMSA, 16 U.S.C. 1433.
NOAA's proposed action is to consider designating the submerged lands and waters surrounding the Pacific Remote Islands to the full extent of the EEZ as a national marine sanctuary following the designation process in section 304 of the NMSA (16 U.S.C. 1434). As part of the sanctuary designation process, NOAA will develop designation materials, including a draft sanctuary management plan, proposed sanctuary regulations, and proposed terms of designation. Each national marine sanctuary has management programs developed with public input and crafted to meet the specific issues and protect resources found in that sanctuary.
The NEPA process will include preparation of a DEIS to consider alternatives and to describe potential effects of the proposed sanctuary designation on the human environment. The DEIS will evaluate a reasonable range of action alternatives that could include different options for management goals or actions, sanctuary regulations, and potential boundaries. The DEIS will also consider a No Action Alternative, wherein NOAA would not designate the proposed sanctuary. Any proposed sanctuary regulations would be separate from, but supplementary and complementary to, existing management authorities in the area.
The results of this public scoping process will assist NOAA in moving forward with the designation process, including preparation and release of draft documents, and formulating alternatives for the DEIS. Reasonable alternatives that are identified during the scoping period will be evaluated in the DEIS.
The DEIS will identify and describe significant environmental impacts and inform decision makers and the public of reasonable alternatives that would avoid or minimize adverse impacts or enhance the quality of the human environment. The proposed action may have impacts, or effects, on these areas:
• marine resources, including habitats, plants, birds, sea turtles, marine mammals, and special status species;
• maritime, cultural, and historic resources and properties, including Traditional Cultural Properties and archaeological sites; and
• human uses and socioeconomics, including research, recreation, education, cultural practices, and fishing.
Based on a preliminary evaluation of the resources listed above, NOAA expects impacts of the proposed action to include: continued or enhanced long-term protection of the Pacific Remote Islands'natural, cultural and historic resources; improved planning and coordination of research, monitoring, and management actions; reduced disturbance of special status species; reduced threats and stressors to the area's resources; and minimal disturbance during research or restoration actions conducted by or on behalf of the sanctuary.
NOAA will serve as the lead Federal agency for the NEPA process for the proposed action. Upon request of NOAA, any Federal agency with jurisdiction by law shall become a cooperating agency and any Federal agency with special expertise with respect to any environmental impact may become a cooperating agency. A State, Tribal, or local agency of similar qualifications may become a cooperating agency by agreement with NOAA in accordance with 40 CFR 1501.8.
NOAA expects to make the DEIS and other draft sanctuary designation documents available to the public in February 2024. NOAA expects to make the FEIS for sanctuary designation available to the public in December 2024. A Record of Decision will be issued no sooner than 30 days after the FEIS is made available to the public in accordance with 40 CFR 1506.11.
Federal permits, authorizations, or consultations may be required for the proposed action, including consultation under the Endangered Species Act, 16 U.S.C. 1531
National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.
Notice; proposed incidental harassment authorization; request for comments on proposed authorization and possible renewal.
NMFS has received a request from the Municipality of Skagway (MOS) for authorization to take marine mammals incidental to the Ore Terminal redevelopment in Skagway, Alaska. Pursuant to the Marine Mammal Protection Act (MMPA), NMFS is requesting comments on its proposal to issue an incidental harassment authorization (IHA) to incidentally take marine mammals during the specified activities. NMFS is also requesting comments on a possible one-time, 1-year renewal that could be issued under certain circumstances and if all requirements are met, as described in the Request for Public Comments section at the end of this notice. NMFS will consider public comments prior to making any final decision on the issuance of the requested MMPA authorization and agency responses will be summarized in the final notice of our decision.
Comments and information must be received no later than May 18, 2023.
Comments should be addressed to Jolie Harrison, Chief, Permits and Conservation Division, Office of Protected Resources, National Marine Fisheries Service and should be submitted via email to
Jenna Harlacher, Office of Protected Resources, NMFS, (301) 427-8401. Electronic copies of the application and supporting documents, as well as a list of the references cited in this document, may be obtained online at:
The MMPA prohibits the “take” of marine mammals, with certain exceptions. Sections 101(a)(5)(A) and (D) of the MMPA (16 U.S.C. 1361
Authorization for incidental takings shall be granted if NMFS finds that the taking will have a negligible impact on the species or stock(s) and will not have an unmitigable adverse impact on the availability of the species or stock(s) for taking for subsistence uses (where relevant). Further, NMFS must prescribe the permissible methods of taking and other “means of effecting the least practicable adverse impact” on the affected species or stocks and their habitat, paying particular attention to rookeries, mating grounds, and areas of similar significance, and on the availability of the species or stocks for taking for certain subsistence uses (referred to in shorthand as “mitigation”); and requirements pertaining to the mitigation, monitoring and reporting of the takings are set forth. The definitions of all applicable MMPA statutory terms cited above are included in the relevant sections below.
To comply with the National Environmental Policy Act of 1969 (NEPA; 42 U.S.C. 4321
This action is consistent with categories of activities identified in Categorical Exclusion B4 (IHAs with no anticipated serious injury or mortality) of the Companion Manual for NOAA Administrative Order 216-6A, which do not individually or cumulatively have the potential for significant impacts on the quality of the human environment and for which we have not identified any extraordinary circumstances that would preclude this categorical exclusion. Accordingly, NMFS has preliminarily determined that the issuance of the proposed IHA qualifies to be categorically excluded from further NEPA review. We will review all comments submitted in response to this notice prior to concluding our NEPA process or making a final decision on the IHA request.
On August 9, 2022, NMFS received a request from MOS for an IHA to take marine mammals incidental to Ore Terminal redevelopment in Skagway, Alaska. Following NMFS' review of the application and subsequent revised versions, MOS submitted a final application that was deemed adequate and complete on February 23, 2023. MOS's request is for take of 7 species (including 11 stocks) by Level B and Level A harassment. Neither MOS nor NMFS expect serious injury or mortality to result from this activity and, therefore, an IHA is appropriate.
MOS proposes to redevelop the Skagway Ore Terminal in Skagway, Alaska. The proposed project will cover construction from fall 2023 through spring 2024 to avoid construction during cruise ship season. A maximum of 152 days of pile installation and removal activity will occur, with some days including both impact and vibratory pile driving. This project involves installation and removal of 36 temporary steel pile guides, removal of 692 piles, and installation of 244 permanent steel piles. Two different installation methods will be used including vibratory pile driving and impact pile driving. Sounds resulting from pile installation and removal may result in the incidental take of marine mammals by Level A and Level B harassment in the form of auditory injury or behavioral harassment.
The proposed IHA would be effective from November 2023 through March 2024. The total expected work duration would be a max of 152 days with some days including both impact and vibratory pile driving (a total of 134 days of vibratory pile installation and 77 days of impact pile driving). This estimate is the maximum days of activity possible and is a conservative estimate that includes any potential delays. Because of the short construction season and limited winter daylight hours, construction would occur during both daylight hours and for a short time after sunset, with construction lighting.
The proposed activity will occur in Skagway, Alaska, within the Skagway Ore Basin (Figure 1). Skagway is the northernmost city in Southeast Alaska. The MOS is at the southwestern end of the 2.5-mile (4 kilometer) long Skagway River valley, which empties into Taiya inlet at the head of Lynn Canal. The Ore Terminal is a deep-water port that transitions sharply from a limited nearshore area into deep marine waters of Lynn Canal. The Ore Terminal basin area has nearly uniform depth of approximately 40 feet (12.2 meters) lower low water.
The proposed project will remove 269 steel and 423 creosote-treated timber piles from the existing Ore dock in Skagway Harbor. These piles will be removed using the vibratory hammer or directly pulled using a clamshell bucket. MOS proposes to install and remove 36 temporary steel piles using vibratory hammers; these piles will be removed by vibratory means by the end of construction. The temporary piles will act as supports or reaction frames to facilitate the installation of permanent piling. Steel permanent piles (248) will be installed to support the new dock structures, as part of the mooring dolphins, and as fender piles. Piles will be driven to the maximum depth feasible using a vibratory pile driver and partially driven and proofed using an impact pile driver to reach required depths. The piles would be installed using both methods over 152 days (Table 1).
Additional actions occurring under the proposed action that are not anticipated to generate in-water noise resulting in marine mammal harassment include vessel movements to support construction and out of water dock components. NMFS does not expect that these ancillary activities will harm or harass marine mammals and no incidental takes are expected as a result of these activities. Therefore, these activities are not discussed further in this document.
Proposed mitigation, monitoring, and reporting measures are described in detail later in this document (please see Proposed Mitigation and Proposed Monitoring and Reporting).
Sections 3 and 4 of the application summarize available information regarding status and trends, distribution and habitat preferences, and behavior and life history of the potentially affected species. NMFS fully considered all of this information, and we refer the reader to these descriptions, referenced here, instead of reprinting the information. Additional information regarding population trends and threats may be found in NMFS' Stock Assessment Reports (SARs;
Table 2 lists all species or stocks for which take is expected and proposed to be authorized for this activity, and summarizes information related to the population or stock, including regulatory status under the MMPA and Endangered Species Act (ESA) and potential biological removal (PBR), where known. PBR is defined by the MMPA as the maximum number of animals, not including natural mortalities, that may be removed from a marine mammal stock while allowing that stock to reach or maintain its optimum sustainable population (as described in NMFS' SARs). While no serious injury or mortality is expected to occur, PBR and annual serious injury and mortality from anthropogenic sources are included here as gross indicators of the status of the species or stocks and other threats.
Marine mammal abundance estimates presented in this document represent the total number of individuals that make up a given stock or the total number estimated within a particular study or survey area. NMFS' stock abundance estimates for most species represent the total estimate of individuals within the geographic area, if known, that comprises that stock. For some species, this geographic area may extend beyond U.S. waters. All stocks managed under the MMPA in this region are assessed in NMFS' 2021 Alaska Marine Mammal SARs. All values presented in Table 2 are the most recent available at the time of publication (including from the draft 2022 SARs) and are available online at:
On January 24, 2023, NMFS published the draft 2022 SARs (
NMFS Office of Protected Resources, Permits and Conservation Division has generally considered peer-reviewed data in draft SARs (relative to data provided in the most recent final SARs), when available, as the best available science, and has done so here for all species and stocks, with the exception of a new proposal to revise humpback whale and harbor porpoise stock structure. Given that the proposed changes to the stock structures involve application of NMFS's Guidance for Assessing Marine Mammals Stocks and could be revised following consideration of public comments, it is more appropriate to conduct our analysis in this proposed authorization based on the status quo stock structure identified in the most recent final SARs (2021; Carretta
As indicated above, all 7 species (with 11 managed stocks) in Table 2 temporally and spatially co-occur with the activity to the degree that take is reasonably likely to occur, and for which we have proposed authorization. In addition to what is included in Sections 3 and 4 of the application, the SARs, and NMFS' website, further localized data and detail informing the baseline for select species (
A previous monitoring report from the White Pass & Yukon Route Railroad Dock Dolphin Installation project includes local marine mammal sighting data from Skagway. From their 57-day (March-May) protected species monitoring, no minke whale, harbor porpoise, or Dall's porpoise were sighted near the project area in Skagway. Twenty-six killer whales were sighted on 4 days, including 2 sightings in March and the rest in April. Killer whales were observed traveling, diving and swimming, and were observed greater than 300 m from the project site. Additionally, 735 harbor seals were observed on 46 days of in-water activity, with sightings occurring in all months of the project. The majority of the harbor seal observations were near Yakutania Point, a harbor seal haulout site. Most of the sightings occurred at least 1,000 m from the project site, however harbor seals came as close as 150 m and as far as 5,000 m. Harbor seals were observed travelling, swimming, playing, milling, looking, hauled out, sinking, and feeding (Owl Ridge Natural Resource Consultants, 2019).
Prior to 2016, humpback whales were listed under the ESA as an endangered species worldwide. Following a 2015 global status review (Bettridge
There are two MMPA stocks of humpback whales in the North Pacific in NMFS Alaska Marine Mammal SAR. Humpback whales from the Western North Pacific stock are not likely to be observed in Southeast Alaska and are
Because DPSs do not overlap exactly with the existing MMPA stocks, there is the possibility that either the Hawaii DPS or the Mexico DPS could be in the project area (Muto
Southeast Alaska primarily provides summer feeding grounds for humpback whales that typically arrive in Southeast Alaska between March and November, although they could be present in Southeast Alaska year-round. Lynn Canal is within the North Pacific feeding and wintering area, and is a biologically import feeding ground for humpback whales (active June-August). However, these areas are outside of Taiya inlet and during months when the activity is not occurring.
Local observers in Taiya Inlet have historically reported humpback whales; however, no scientific surveys have documented the species in the area (Dahlheim
Steller sea lions were listed as threatened range-wide under the ESA on November 26, 1990 (55 FR 49204). Steller sea lions were subsequently partitioned into the western and eastern DPSs in 1997 (62 FR 24345, May 5, 1997). The eastern DPS remained classified as threatened until it was delisted in November 2013. The western DPS (those individuals west of the 144° W longitude or Cape Suckling, Alaska) was upgraded to endangered status following separation of the DPSs; it remains endangered today and considered a strategic stock under the MMPA. Both stocks of Steller sea lions are found in Southeast Alaska and have the potential to occur in the project area, however it is more likely they would be from the Eastern stock.
Critical habitat for Steller sea lions was designated by NMFS in 1993 based on the following essential physical and biological habitat features: terrestrial habitat (including rookeries and haulouts important for rest, reproduction, growth, social interactions) and aquatic habitat (including nearshore waters around rookeries and haulouts, free passage for migration, prey resources, and foraging habitats) (58 FR 45269).
During the White Pass & Yukon Route Railroad Dock Dolphin Installation project, Steller sea lions were sighted on 27 separate days with 165 individuals. Majority of the sightings occurred during April and May, with only six individuals sighted in March. Although a few sightings were 500 meters from pile driving activities, most sightings were recorded over 1,000 meters away from the pile driving site. Sightings were of single individuals and rafts up to 25 individuals. Steller sea lions were observed swimming, traveling, resting, porpoising, looking, sinking, and milling (Owl Ridge Natural Resource Consultants, 2019).
Gran Point is the closest major haulout and designated critical habitat area, approximately 24 miles (38.6 kilometers) from the Project site and outside of Taiya Inlet (NOAA, 2022b). Additionally, there is a nearby Steller sea lion haulout at the southern tip of Taiya Inlet utilized by Steller sea lions during the Eulachon run. The Lutak Inlet Eulachon run between April and May correlates with higher sea lion numbers near the Project site, with the Taiya Point haulout (approximately 10 miles (16.1 kilometers) away) being a popular land site (NOAA, 2022b). However, the Eulachon run is outside of the project work window.
Hearing is the most important sensory modality for marine mammals underwater, and exposure to anthropogenic sound can have deleterious effects. To appropriately assess the potential effects of exposure to sound, it is necessary to understand the frequency ranges marine mammals are able to hear. Not all marine mammal species have equal hearing capabilities (
The pinniped functional hearing group was modified from Southall
For more detail concerning these groups and associated frequency ranges, please see NMFS (2018) for a review of available information.
This section provides a discussion of the ways in which components of the specified activity may impact marine mammals and their habitat. The Estimated Take section later in this document includes a quantitative analysis of the number of individuals that are expected to be taken by this activity. The Negligible Impact Analysis and Determination section considers the content of this section, the Estimated Take section, and the Proposed Mitigation section, to draw conclusions regarding the likely impacts of these activities on the reproductive success or survivorship of individuals and whether those impacts are reasonably expected to, or reasonably likely to, adversely affect the species or stock through effects on annual rates of recruitment or survival.
Acoustic effects on marine mammals during the specified activity can occur from impact and vibratory pile driving and removal. The effects of underwater noise from MOS's proposed activities have the potential to result in Level A or Level B harassment of marine mammals in the action area.
The marine soundscape is comprised of both ambient and anthropogenic sounds. Ambient sound is defined as the all-encompassing sound in a given place and is usually a composite of sound from many sources both near and far. The sound level of an area is defined by the total acoustical energy being generated by known and unknown sources. These sources may include physical (
The sum of the various natural and anthropogenic sound sources at any given location and time—which comprise “ambient” or “background” sound—depends not only on the source levels (as determined by current weather conditions and levels of biological and shipping activity) but also on the ability of sound to propagate through the environment. In turn, sound propagation is dependent on the spatially and temporally varying properties of the water column and sea floor, and is frequency-dependent. As a result of the dependence on a large number of varying factors, ambient sound levels can be expected to vary widely over both coarse and fine spatial and temporal scales. Sound levels at a given frequency and location can vary by 10-20 dB from day to day (Richardson
In-water construction activities associated with the project would include vibratory pile removal, and impact and vibratory pile driving. The sounds produced by these activities fall into one of two general sound types: impulsive and non-impulsive. Impulsive sounds (
Two types of hammers would be used on this project: impact and vibratory. Impact hammers operate by repeatedly dropping a heavy piston onto a pile to drive the pile into the substrate. Sound generated by impact hammers is characterized by rapid rise times and high peak levels, a potentially injurious combination (Hastings and Popper, 2005). Vibratory hammers install piles by vibrating them and allowing the weight of the hammer to push them into the sediment. Vibratory hammers produce significantly less sound than impact hammers. Peak sound pressure levels (SPLs) may be 180 dB or greater, but are generally 10 to 20 dB lower than SPLs generated during impact pile driving of the same-sized pile (Oestman
The likely or possible impacts of MOS's proposed activity on marine mammals could involve both non-acoustic and acoustic stressors. Potential non-acoustic stressors could result from the physical presence of equipment and personnel; however, any impacts to marine mammals are expected to be primarily acoustic in nature. Acoustic stressors include effects of heavy equipment operation during pile driving.
The introduction of anthropogenic noise into the aquatic environment from pile driving is the primary means by which marine mammals may be harassed from the MOS's specified activity. In general, animals exposed to natural or anthropogenic sound may experience physical and psychological effects, ranging in magnitude from none to severe (Southall
NMFS defines a noise-induced threshold shift (TS) as a change, usually an increase, in the threshold of audibility at a specified frequency or portion of an individual's hearing range above a previously established reference level (NMFS, 2018). The amount of TS is customarily expressed in decibels (dB). A TS can be permanent or temporary. As described in NMFS (2018), there are numerous factors to consider when examining the consequence of TS, including, but not limited to, the signal temporal pattern (
Depending on the degree (elevation of threshold in dB), duration (
Many studies have examined noise-induced hearing loss in marine mammals (see Finneran (2015) and Southall
Disturbance may result in changing durations of surfacing and dives, number of blows per surfacing, or moving direction and/or speed; reduced/increased vocal activities; changing/cessation of certain behavioral activities (such as socializing or feeding); visible startle response or aggressive behavior (such as tail/fluke slapping or jaw clapping); and, avoidance of areas where sound sources are located. Pinnipeds may increase their haul out time, possibly to avoid in-water disturbance (Thorson and Reyff, 2006). Behavioral responses to sound are highly variable and context-specific and any reactions depend on numerous intrinsic and extrinsic factors (
Disruption of feeding behavior can be difficult to correlate with anthropogenic sound exposure, so it is usually inferred by observed displacement from known foraging areas, the appearance of secondary indicators (
Neuroendocrine stress responses often involve the hypothalamus-pituitary-adrenal system. Virtually all neuroendocrine functions that are affected by stress—including immune competence, reproduction, metabolism, and behavior—are regulated by pituitary hormones. Stress-induced changes in the secretion of pituitary hormones have been implicated in failed reproduction, altered metabolism, reduced immune competence, and behavioral disturbance (
The primary distinction between stress (which is adaptive and does not normally place an animal at risk) and “distress” is the cost of the response. During a stress response, an animal uses glycogen stores that can be quickly replenished once the stress is alleviated. In such circumstances, the cost of the stress response would not pose serious fitness consequences. However, when an animal does not have sufficient energy reserves to satisfy the energetic costs of a stress response, energy resources must be diverted from other functions. This state of distress will last until the animal replenishes its energetic reserves sufficient to restore normal function.
Relationships between these physiological mechanisms, animal behavior, and the costs of stress responses are well studied through controlled experiments and for both laboratory and free-ranging animals (
The MOS's construction activities could have localized, temporary impacts on marine mammal habitat and their prey by increasing in-water sound pressure levels and slightly decreasing water quality. However, the proposed location is not heavily used by marine mammals and is in close proximity to a heavily trafficked industrial area. Construction activities are of short duration and would likely have temporary impacts on marine mammal habitat through increases in underwater and airborne sound. Increased noise levels may affect acoustic habitat (see
Temporary and localized increase in turbidity near the seafloor would occur in the immediate area surrounding the area where piles are installed or removed. In general, turbidity associated with pile installation is localized to about a 25-ft (7.6 meter) radius around the pile (Everitt
The proposed activities would result in a minor loss of benthic habitat and potentially change underwater features for fish, but these changes are insignificant and limited to the area of redevelopment. The total seafloor area likely impacted by the project is relatively small compared to the available habitat in Southeast Alaska and does not include any Biologically Important Areas (BIA) or other habitat of known importance. The area is highly influenced by anthropogenic activities. Additionally, the total seafloor area affected by pile installation and removal is a small area compared to the vast foraging area available to marine mammals in the area. At best, the impact area provides marginal foraging habitat for marine mammals and fishes. Furthermore, pile driving at the project site would not obstruct movements or migration of marine mammals.
Avoidance by potential prey (
Sound may affect marine mammals through impacts on the abundance, behavior, or distribution of prey species (
Fish utilize the soundscape and components of sound in their environment to perform important functions such as foraging, predator avoidance, mating, and spawning (
Fish react to sounds that are especially strong and/or intermittent low-frequency sounds, and behavioral responses, such as flight or avoidance, are the most likely effects. Short duration, sharp sounds can cause overt or subtle changes in fish behavior and local distribution. The reaction of fish to noise depends on the physiological state of the fish, past exposures, motivation (
SPLs of sufficient strength have been known to cause injury to fish and fish mortality. However, in most fish species, hair cells in the ear continuously regenerate and loss of auditory function likely is restored when damaged cells are replaced with new cells. Halvorsen
The most likely impact to fish from pile driving activities at the project areas would be temporary behavioral avoidance of the area. The duration of fish avoidance of an area after pile driving stops is unknown, but a rapid return to normal recruitment, distribution and behavior is anticipated.
Construction activities, in the form of increased turbidity, have the potential to adversely affect forage fish in the project area. Forage fish form a significant prey base for many marine mammal species that occur in the project area. Increased turbidity is expected to occur in the immediate vicinity (on the order of 10 ft (3 m) or less) of construction activities. However, suspended sediments and particulates are expected to dissipate quickly within a single tidal cycle. Given the limited area affected and high tidal dilution rates, any effects on forage fish are expected to be minor or negligible. Finally, exposure to turbid waters from construction activities is not expected to be different from the current exposure; fish and marine mammals in the Passage Canal are routinely exposed to substantial levels of suspended sediment from natural and anthropogenic sources.
In summary, given the short-term and limited duration of sound associated with pile driving events and the relatively small areas being affected, pile driving activities associated with the proposed action are not likely to have a permanent adverse effect on any fish habitat, or populations of fish species. Any behavioral avoidance by fish of the disturbed area would be temporary and would still leave significantly large areas of fish and marine mammal foraging habitat in the nearby vicinity. Additionally, all in-water work will occur during the winter, when marine resident fish species are only present in limited numbers. Thus, we conclude that impacts of the specified activity are not likely to have more than short-term adverse effects on any prey habitat or populations of prey species. Further, any impacts to marine mammal habitat are not expected to result in significant or long-term consequences for individual marine mammals, or to contribute to adverse impacts on their populations.
This section provides an estimate of the number of incidental takes proposed for authorization through this IHA, which will inform both NMFS' consideration of “small numbers,” and the negligible impact determinations.
Harassment is the only type of take expected to result from these activities. Except with respect to certain activities not pertinent here, section 3(18) of the MMPA defines “harassment” as any act of pursuit, torment, or annoyance, which (i) has the potential to injure a marine mammal or marine mammal stock in the wild (Level A harassment); or (ii) has the potential to disturb a marine mammal or marine mammal stock in the wild by causing disruption of behavioral patterns, including, but not limited to, migration, breathing, nursing, breeding, feeding, or sheltering (Level B harassment).
Authorized takes would primarily be by Level B harassment, as use of the acoustic sources (
For acoustic impacts, generally speaking, we estimate take by considering: (1) acoustic thresholds above which NMFS believes the best available science indicates marine mammals will be behaviorally harassed or incur some degree of permanent hearing impairment; (2) the area or volume of water that will be ensonified above these levels in a day; (3) the density or occurrence of marine mammals within these ensonified areas; and, (4) the number of days of activities. We note that while these factors can contribute to a basic calculation to provide an initial prediction of potential takes, additional information that can qualitatively inform take estimates is also sometimes available (
NMFS recommends the use of acoustic thresholds that identify the received level of underwater sound above which exposed marine mammals would be reasonably expected to be behaviorally harassed (equated to Level B harassment) or to incur permanent threshold shift (PTS) of some degree (equated to Level A harassment).
MOS's proposed activity includes the use of continuous (vibratory pile driving) and impulsive (impact pile driving) sources, and therefore the RMS SPL thresholds of 120 and 160 dB re 1 μPa are applicable.
These thresholds are provided in the table below. The references, analysis, and methodology used in the development of the thresholds are described in NMFS' 2018 Technical Guidance, which may be accessed at:
Here, we describe operational and environmental parameters of the activity that are used in estimating the area ensonified above the acoustic thresholds, including source levels and transmission loss coefficient.
The sound field in the project area is the existing background noise plus additional construction noise from the proposed project. Marine mammals are expected to be affected via sound generated by the primary components of the project (
In order to calculate distances to the Level A harassment and Level B harassment thresholds for the methods and piles being used in this project, NMFS used acoustic monitoring data from other locations to develop source levels for the various pile types, sizes and methods (Table 5).
Transmission loss (TL) is the decrease in acoustic intensity as an acoustic pressure wave propagates out from a source. TL parameters vary with frequency, temperature, sea conditions, current, source and receiver depth, water depth, water chemistry, and bottom composition and topography. The general formula for underwater TL is:
The recommended TL coefficient for most nearshore environments is the practical spreading value of 15. This value results in an expected propagation environment that would lie between spherical and cylindrical spreading loss conditions, which is the most appropriate assumption for MOS's proposed activities. The Level B harassment zones for the proposed activities are shown in Table 6.
The ensonified area associated with Level A harassment is more technically challenging to predict due to the need to account for a duration component. Therefore, NMFS developed an optional User Spreadsheet tool to accompany the Technical Guidance that can be used to relatively simply predict an isopleth distance for use in conjunction with marine mammal density or occurrence to help predict potential takes. We note that because of some of the assumptions included in the methods underlying this optional tool, we anticipate that the resulting isopleth estimates are typically going to be overestimates of some degree, which may result in an overestimate of potential take by Level A harassment. However, this optional tool offers the best way to estimate isopleth distances when more sophisticated modeling methods are not available or practical. For stationary sources, such as pile installation or
In this section, we provide information about the occurrence of marine mammals, including density or other relevant information that will inform the take calculations.
For marine mammal density information in the Skagway area we use data from the Pacific Navy Marine Species Density Database (U.S. Navy, 2021) and sources specific to the Skagway area to estimate take for marine mammals. The Marine Species Density Database incorporates analyzed literature and research for marine mammal density estimates per season for the Gulf of Alaska and the Western Behm Canal. The Western Behm Canal is closer to the Project site and geographically more similar (an inlet compared to open ocean); therefore, density estimates for Western Behm Canal are used as proxies. Density estimates specific to Taiya Inlet or Lynn Canal are not available for any of the species addressed in this application, and therefore takes must be estimated based on the nearest available and most appropriate density estimates, plus site-specific knowledge and professional judgement. Table 7 density estimates are calculated based on the in-water work window (November-March) and based on winter density estimates of Western Behm Canal.
Here, we describe how the information provided above is synthesized to produce a quantitative estimate of the take that is reasonably likely to occur and proposed for authorization.
Using the overall area of disturbance generated by pile removal and installation given calculated distances to attenuation below disturbance (Level B harassment) thresholds, incidental take for each activity is estimated by the following equation:
Due to little observational data available for marine mammals in Taiya Inlet and Lynn Canal in the winter, this equation is a reasonable extrapolation for take estimates, which relies on the likelihood that a species is present within the ensonified area on a day where the proposed activity is occurring. The estimation of take by Level A harassment is based on the likelihood that marine mammals would enter the Level A harassment zone without detection.
In order to issue an IHA under section 101(a)(5)(D) of the MMPA, NMFS must set forth the permissible methods of taking pursuant to the activity, and other means of effecting the least practicable impact on the species or stock and its habitat, paying particular attention to rookeries, mating grounds,
In evaluating how mitigation may or may not be appropriate to ensure the least practicable adverse impact on species or stocks and their habitat, as well as subsistence uses where applicable, NMFS considers two primary factors:
(1) The manner in which, and the degree to which, the successful implementation of the measure(s) is expected to reduce impacts to marine mammals, marine mammal species or stocks, and their habitat, as well as subsistence uses. This considers the nature of the potential adverse impact being mitigated (likelihood, scope, range). It further considers the likelihood that the measure will be effective if implemented (probability of accomplishing the mitigating result if implemented as planned), the likelihood of effective implementation (probability implemented as planned); and,
(2) The practicability of the measures for MOS implementation, which may consider such things as cost and impact on operations.
NMFS proposed the following mitigation measures be implemented for MOS's pile installation and removal activities.
MOS must follow mitigation measures as specified below:
• Ensure that construction supervisors and crews, the monitoring team, and relevant MOS staff are trained prior to the start of all pile driving activity, so that responsibilities, communication procedures, monitoring protocols, and operational procedures are clearly understood. New personnel joining during the project must be trained prior to commencing work;
• Employ Protected Species Observers (PSOs) and establish monitoring locations as described in the application and the IHA. MOS must monitor the project area to the maximum extent possible based on the required number of PSOs, required monitoring locations, and environmental conditions. For all pile driving and removal, at least one PSO must be used. The PSO will be stationed as close to the activity as possible;
• The placement of the PSOs during all pile driving and removal activities will ensure that the entire shutdown zone is visible during pile driving activities. Should environmental conditions deteriorate such that marine mammals within the entire shutdown zone will not be visible (
• Monitoring must take place from 30 minutes prior to initiation of pile driving activity (
• Pre-start clearance monitoring must be conducted during periods of visibility sufficient for the lead PSO to determine that the shutdown zones indicated in Table 9 are clear of marine mammals. Pile driving may commence following 30 minutes of observation when the determination is made that the shutdown zones are clear of marine mammals;
• MOS must use soft start techniques when impact pile driving. Soft start requires contractors to provide an initial set of three strikes at reduced energy, followed by a 30-second waiting period, then two subsequent reduced-energy strike sets. A soft start must be implemented at the start of each day's impact pile driving and at any time following cessation of impact pile driving for a period of 30 minutes or longer;
• If a marine mammal is observed entering or within the shutdown zones indicated in Table 9, pile driving must be delayed or halted. If pile driving is delayed or halted due to the presence of a marine mammal, the activity may not commence or resume until either the animal has voluntarily exited and been visually confirmed beyond the shutdown zone (Table 9) or 15 minutes have passed without re-detection of the animal; and
• As proposed by MOS, in water activities will take place only between civil dawn and civil dusk and for a limited duration after dusk with lighting when PSOs can effectively monitor for the presence of marine mammals; during conditions with a Beaufort Sea State of 4 or less; when the entire shutdown zone and adjacent waters are visible (
MOS will establish shutdown zones for all pile driving activities. The purpose of a shutdown zone is generally to define an area within which shutdown of the activity would occur upon sighting of a marine mammal (or in anticipation of an animal entering the defined area). Shutdown zones would be based upon the Level A harassment zone for each pile size/type and driving method where applicable, as shown in Table 9.
For in-water heavy machinery activities other than pile driving, if a marine mammal comes within 10 m, work generating underwater noise will stop and vessels will reduce speed to the minimum level required to maintain steerage and safe working conditions. A 10 m shutdown zone would also serve to protect marine mammals from physical interactions with project vessels during pile driving and other construction activities, such as barge positioning or drilling. If an activity is delayed or halted due to the presence of a marine mammal, the activity may not commence or resume until either the animal has voluntarily exited and been visually confirmed beyond the shutdown zone indicated in Table 9 or 15 minutes have passed without re-detection of the animal. Construction activities must be halted upon observation of a species for which incidental take is not authorized or a species for which incidental take has been authorized but the authorized number of takes has been met entering or within the harassment zone.
All marine mammals will be monitored in the Level B harassment zones and throughout the area as far as visual monitoring can take place. If a marine mammal enters the Level B harassment zone, in-water activities will continue and the animal's presence within the estimated harassment zone will be documented.
MOS would also establish shutdown zones for all marine mammals for which take has not been authorized or for which incidental take has been authorized but the authorized number of takes has been met. These zones are equivalent to the Level B harassment zones for each activity. If a marine mammal species not covered under this IHA enters the shutdown zone, all in-water activities will cease until the animal leaves the zone or has not been observed for at least 15 minutes, and NMFS will be notified about species and precautions taken. Pile driving will proceed if the non-IHA species is observed to leave the Level B harassment zone or if 15 minutes have passed since the last observation.
If shutdown and/or clearance procedures would result in an imminent safety concern, as determined by MOS or its designated officials, the in-water
The placement of PSOs during all construction activities (described in the Proposed Monitoring and Reporting section) would ensure that the entire shutdown zone is visible. Should environmental conditions deteriorate such that the entire shutdown zone would not be visible (
PSOs would monitor the full shutdown zones and the remaining Level A harassment and the Level B harassment zones to the extent practicable. Monitoring zones provide utility for observing by establishing monitoring protocols for areas adjacent to the shutdown zones. Monitoring zones enable observers to be aware of and communicate the presence of marine mammals in the project areas outside the shutdown zones and thus prepare for a potential cessation of activity should the animal enter the shutdown zone.
Prior to the start of daily in-water construction activity, or whenever a break in pile driving of 30 minutes or longer occurs, PSOs would observe the shutdown and monitoring zones for a period of 30 minutes. The shutdown zone would be considered cleared when a marine mammal has not been observed within the zone for that 30-minute period. If a marine mammal is observed within the shutdown zones listed in Table 9, pile driving activity would be delayed or halted. If work ceases for more than 30 minutes, the pre-activity monitoring of the shutdown zones would commence. A determination that the shutdown zone is clear must be made during a period of good visibility (
Soft start procedures provide additional protection to marine mammals by providing warning and/or giving marine mammals a chance to leave the area prior to the hammer operating at full capacity. For impact pile driving, contractors would be required to provide an initial set of three strikes from the hammer at reduced energy, followed by a 30-second waiting period, then two subsequent reduced-energy strike sets. Soft start would be implemented at the start of each day's impact pile driving and at any time following cessation of impact pile driving for a period of 30 minutes or longer.
Based on our evaluation of MOS's proposed measures, as well as other measures considered by NMFS, NMFS has preliminarily determined that the proposed mitigation measures provide the means effecting the least practicable impact on the affected species or stocks and their habitat, paying particular attention to rookeries, mating grounds, and areas of similar significance.
In order to issue an IHA for an activity, section 101(a)(5)(D) of the MMPA states that NMFS must set forth requirements pertaining to the monitoring and reporting of such taking. The MMPA implementing regulations at 50 CFR 216.104(a)(13) indicate that requests for authorizations must include the suggested means of accomplishing the necessary monitoring and reporting that will result in increased knowledge of the species and of the level of taking or impacts on populations of marine mammals that are expected to be present while conducting the activities. Effective reporting is critical both to compliance as well as ensuring that the most value is obtained from the required monitoring.
Monitoring and reporting requirements prescribed by NMFS should contribute to improved understanding of one or more of the following:
• Occurrence of marine mammal species or stocks in the area in which take is anticipated (
• Nature, scope, or context of likely marine mammal exposure to potential stressors/impacts (individual or cumulative, acute or chronic), through better understanding of: (1) action or environment (
• Individual marine mammal responses (behavioral or physiological) to acoustic stressors (acute, chronic, or cumulative), other stressors, or cumulative impacts from multiple stressors;
• How anticipated responses to stressors impact either: (1) long-term fitness and survival of individual marine mammals; or (2) populations, species, or stocks;
• Effects on marine mammal habitat (
• Mitigation and monitoring effectiveness.
Marine mammal monitoring must be conducted in accordance with the conditions in this section and the IHA. Marine mammal monitoring during pile driving activities would be conducted by PSOs meeting NMFS' following requirements:
• Independent PSOs (
• At least one PSO would have prior experience performing the duties of a PSO during construction activity pursuant to a NMFS-issued incidental take authorization;
• Other PSOs may substitute education (degree in biological science or related field) or training for experience; and
• Where a team of three or more PSOs is required, a lead observer or monitoring coordinator would be designated. The lead observer would be required to have prior experience working as a marine mammal observer during construction.
PSOs must have the following additional qualifications:
• Ability to conduct field observations and collect data according to assigned protocols;
• Experience or training in the field identification of marine mammals, including the identification of behaviors;
• Sufficient training, orientation, or experience with the construction operation to provide for personal safety during observations;
• Writing skills sufficient to prepare a report of observations including but not limited to the number and species of marine mammals observed; dates and times when in-water construction activities were conducted; dates, times and reason for implementation of mitigation (or why mitigation was not implemented when required); and marine mammal behavior; and
• Ability to communicate orally, by radio or in person, with project personnel to provide real-time information on marine mammals observed in the area as necessary.
• MOS must employ up to five PSOs during all pile driving activities depending on the size of the monitoring and shutdown zones. A minimum of two PSOs (including the lead PSO) must be assigned to the active pile driving location to monitor the shutdown zones and as much of the Level B harassment zones as possible.
• MOS must establish the following monitoring locations with the best views of monitoring zones as described in the IHA and Application.
• Up to five monitors will be used at a time depending on the size of the monitoring area. PSOs would be deployed in strategic locations around the area of potential effects at all times during in-water pile driving and removal. PSOs will be positioned at locations that provide full views of the impact hammering monitoring zone and the Level A harassment Shutdown Zones. The stations will be at the Railroad Dock, Yakutania Point, and Dyea Point. The vibratory monitoring zone will be monitored using PSOs stationed on boats anchored near the shoreline. All PSOs would have access to high-quality binoculars, range finders to monitor distances, and a compass to record bearing to animals as well as radios or cells phones for maintaining contact with work crews.
Monitoring would be conducted 30 minutes before, during, and 30 minutes after all in water construction activities. In addition, PSOs would record all incidents of marine mammal occurrence, regardless of distance from activity, and would document any behavioral reactions in concert with distance from piles being driven or removed. Pile driving activities include the time to install or remove a single pile or series of piles, as long as the time elapsed between uses of the pile driving equipment is no more than 30 minutes.
MOS shall conduct briefings between construction supervisors and crews, PSOs, MOS staff prior to the start of all pile driving activities and when new personnel join the work. These briefings would explain responsibilities, communication procedures, marine mammal monitoring protocol, and operational procedures.
Acoustic monitoring will be conducted during in-water pile installation and removal, for each of the three scenarios (impact installation of steel piles, vibratory installation and removal of steel piles, and vibratory removal of timber piles). Collection of the acoustic data will be accomplished using a minimum of two hydrophones. At least one land-based microphone would also be deployed to record airborne sound levels. For underwater acoustic monitoring, the hydrophones will be placed such that there is a direct line of acoustic transmission through the water column between the impact or vibratory hammer and the hydrophones, without any interposing structures (including other piles) that could impede sound transfer, when possible. All acoustical recordings will be conducted at least 1 meter below the water surface and 1 meter above the sea floor, or as applicable to optimize sound recordings in the nearshore environment. Background noise recordings (in the absence of pile-related work) will also be made during the study to provide a baseline background noise profile.
All sensors, signal conditioning equipment, and sampling equipment will be calibrated at the start of the monitoring period to National Institute of Standards and Technology standards and will be rechecked at the start of each day.
A stationary two-channel hydrophone recording system will be deployed to record continuous sound associated with pile driving and removal activities during the monitoring period. Key methodological details are as follows:
• Prior to monitoring, water depth measurements will be made to ensure that hydrophones will not drag on the bottom during tidal changes. The hydrophones will be placed at least 1 meter below the surface and 1 meter above the seafloor. The depth with respect to the bottom may vary somewhat due to tidal changes and current effects.
• One hydrophone will be deployed to maintain a constant distance of approximately 10 meters from the pile-related noise source, and the other would be at a further distance from the pile-related noise source.
• The hydrophones, signal conditioning, and recording equipment will be configured to acquire maximum source levels without clipping recorded data.
Post-analysis of underwater sound level signals would include the following:
• Impact Pile Driving:
1. Determination of the maximum absolute value of the instantaneous pressure within each strike.
2. RMS value for the period of which 90 percent of the energy is represented (RMS 90, 5 percent to 95 percent) for each absolute peak pile strike.
3. Peak SPL and pulse duration for each pile strike.
4. Mean and standard deviation/error of the RMS 90 percent for all pile strikes of each pile.
5. Rise time.
6. Number of strikes per pile and per day.
7. Sound exposure level (SEL) of the single pile strike with the absolute peak (PK), mean SEL.
8. Minimum, maximum, mean, and median cumulative SEL (cumulative SEL = single strike SEL + 10*LOG (number of pile strikes)).
9. Frequency spectrum, between 20 Hz and 20 kHz, for up to eight successive strikes with similar sound level.
• Vibratory Pile Driving and Removal:
1. RMS values (median, standard deviation/error, minimum, and maximum) for each recorded pile. The 10-second, RMS-averaged values will be used for determining the source value and extent of the 120 dB underwater isopleth.
2. Frequency spectra will be provided for each functional hearing group as
3. All underwater source levels will be standardized to a reference distance of 10 meters (33 feet).
• Post-analysis of airborne noise will be presented in an unweighted format, and will include the following:
1. The unweighted RMS values (average, minimum, and maximum) for each recorded pile. The average values will be used for determining the extent of the airborne isopleths relative to species specific criteria.
2. Frequency spectra will be provided from 10 Hz to 20 kHz for representative pile-related activity.
3. All airborne source levels will be standardized to a reference distance of approximately 15 meters (50 feet).
• Acoustic monitoring will be performed using a standardized method that will facilitate comparisons with other studies. In the event that pile-related noise trends toward consistently surpassing calculated levels, NMFS will be contacted immediately to revise Shutdown Zones as needed.
A draft marine mammal monitoring report will be submitted to NMFS within 90 days after the completion of pile driving and removal activities, or 60 days prior to a requested date of issuance from any future IHAs for projects at the same location, whichever comes first. The report will include an overall description of work completed, a narrative regarding marine mammal sightings, and associated PSO data sheets. Specifically, the report must include:
• Dates and times (begin and end) of all marine mammal monitoring;
• Construction activities occurring during each daily observation period, including the number and type of piles driven or removed and by what method (
• PSO locations during marine mammal monitoring;
• Environmental conditions during monitoring periods (at beginning and end of PSO shift and whenever conditions change significantly), including Beaufort sea state and any other relevant weather conditions including cloud cover, fog, sun glare, and overall visibility to the horizon, and estimated observable distance;
• Upon observation of a marine mammal, the following information:
• Name of PSO who sighted the animal(s) and PSO location and activity at the time of sighting;
• Time of sighting;
• Identification of the animal(s) (
• Distance and bearing of each marine mammal observed relative to the pile being driven for each sightings (if pile driving was occurring at time of sighting);
• Estimated number of animals (min/max/best estimate);
• Estimated number of animals by cohort (adults, juveniles, neonates, group composition, sex class,
• Animal's closest point of approach and estimated time spent within the harassment zone;
• Description of any marine mammal behavioral observations (
• Number of marine mammals detected within the harassment zones and shutdown zones; by species;
• Detailed information about any implementation of any mitigation triggered (
• If visibility degrades to where PSO(s) cannot view the entire harassment zones, additional PSOs may be positioned so that the entire width is visible, or work will be halted until the entire width is visible to ensure that any humpback whales entering or within the harassment zone are detected by PSOs.
If no comments are received from NMFS within 30 days, the draft final report will constitute the final report. If comments are received, a final report addressing NMFS comments must be submitted within 30 days after receipt of comments.
The Acoustic Monitoring Report must include:
• Type and size of pile being driven, substrate type, method of driving during recordings (
• Whether a sound attenuation device is used and, if so, a detailed description of the device and the duration of its use per pile;
• A description of the sound monitoring equipment, including a detailed description of the depths and locations of the hydrophones relative to the pile being driven;
• For impact pile driving: Number of strikes and strike rate, depth of substrate to penetrate; pulse duration and mean, median, and maximum sound levels (dB re: 1 µPa); root mean square sound pressure level (SPL
• For vibratory driving/removal (per pile): Duration of driving per pile; mean, median, and maximum sound levels (dB re: 1 µPa): Root mean square sound pressure level (SPL
• One-third octave band spectrum and power spectral density plot for each pile monitored and average spectrum for each type of driving (
• Environmental data, including but not limited to, the following: wind speed and direction, air temperature, humidity, surface water temperature, water depth (at the pile and hydrophone locations), characteristics of the bottom substrate into which the pile was driven, wave height, weather conditions, and other factors that could contribute to influencing the airborne and underwater sound levels (
In the event that personnel involved in the construction activities discover an injured or dead marine mammal, the MOS must immediately cease the specified activities and report the incident to the Office of Protected Resources (OPR) (
• Time, date, and location (latitude/longitude) of the first discovery (and updated location information if known and applicable);
• Species identification (if known) or description of the animal(s) involved;
• Condition of the animal(s) (including carcass condition if the animal is dead);
• Observed behaviors of the animal(s), if alive;
• If available, photographs or video footage of the animal(s); and
• General circumstances under which the animal was discovered.
NMFS has defined negligible impact as an impact resulting from the specified activity that cannot be reasonably expected to, and is not reasonably likely to, adversely affect the species or stock through effects on annual rates of recruitment or survival (50 CFR 216.103). A negligible impact finding is based on the lack of likely adverse effects on annual rates of recruitment or survival (
To avoid repetition, our analysis applies to all species listed in Table 2 for which take could occur, given that NMFS expects the anticipated effects of the proposed pile driving/removal on different marine mammal stocks to be similar in nature. Where there are meaningful differences between species or stocks, or groups of species, in anticipated individual responses to activities, impact of expected take on the population due to differences in population status, or impacts on habitat, NMFS has identified species-specific factors to inform the analysis.
Pile driving activities associated with the project, as outlined previously, have the potential to disturb or displace marine mammals. Specifically, the specified activities may result in take, in the form of Level B harassment and Level A harassment from underwater sounds generated by pile driving. Potential takes could occur if individuals are present in the ensonified zone when these activities are underway.
No serious injury or mortality would be expected, even in the absence of required mitigation measures, given the nature of the activities. Further, limited take by Level A harassment is anticipated for humpback whales, minke whales, killer whales, harbor porpoise, and Steller sea lion due to the application of planned mitigation measures, such as shutdown zones that encompass the Level A harassment zones for these species and the rarity of these species near the action area. The potential for harassment would be minimized through the construction method and the implementation of the planned mitigation measures (see Proposed Mitigation section).
Take by Level A harassment is proposed for all species, as there is potential for these species to be in the area. There is the possibility that an animal could enter a Level A harassment zone without being detected, and remain within that zone for a duration long enough to incur PTS. However, Level A harassment of these species is proposed to be conservative. Any take by Level A harassment is expected to arise from, at most, a small degree of PTS (
Further, the amount of take proposed for authorization by Level A harassment is low for both marine mammal stocks and species except harbor seals as they are common in the area. If hearing impairment occurs, it is most likely that the affected animal would lose only a few decibels in its hearing sensitivity. Due to the small degree anticipated, any PTS potential incurred would not be expected to affect the reproductive success or survival of any individuals, much less result in adverse impacts on the species or stock.
Additionally, some subset of the individuals that are behaviorally harassed could also simultaneously incur some small degree of TTS for a short duration of time. However, since the hearing sensitivity of individuals that incur TTS is expected to recover completely within minutes to hours, it is unlikely that the brief hearing impairment would affect the individual's long-term ability to forage and communicate with conspecifics, and would therefore not likely impact reproduction or survival of any individual marine mammal, let alone adversely affect rates of recruitment or survival of the species or stock.
The Level A harassment zones identified in Table 6 are based upon an animal's exposure to pile driving of up to 5 steel piles or 18 timber piles removed per day. Given the short duration to impact drive or vibratory install or extract each pile and break between pile installations (to reset equipment and move piles into place), an animal would have to remain within the area estimated to be ensonified above the Level A harassment threshold for multiple hours. This is highly unlikely given marine mammal movement in the area. If an animal was exposed to accumulated sound energy, the resulting PTS would likely be small (
The nature of the pile driving project precludes the likelihood of serious injury or mortality. For all species and stocks, take would occur within a limited, confined area (adjacent to the project site) of the stock's range. Level A and Level B harassment will be reduced to the level of least practicable adverse impact through use of mitigation measures described herein. Further, the amount of take proposed to be authorized is small when compared to stock abundance.
Behavioral responses of marine mammals to pile driving and removal in Taiya Inlet are expected to be mild, short term, and temporary. Marine mammals within the Level B harassment zones may not show any visual cues they are disturbed by activities or they could become alert, avoid the area, leave the area, or display other mild responses that are not observable, such as changes in vocalization patterns. Given that pile driving and removal would occur for only a portion of the project's duration, any harassment occurring would be temporary. Additionally, many of the species present in region would only be
For all species, there are no known BIA near the project area that would be impacted by MOS's planned activities. While there is a Steller sea lion haulout at the end of Taiya inlet at Taiya point, this is approximately 13,300-m from the project site. Additionally, there is a rookery at Gran Point, which is Steller sea lion critical habitat, though this is outside the project area around 24 miles (38.6 km) from Skagway. Lastly, there is a summer feeding ground for humpback whales in Lynn Canal, however this is outside of Taiya Inlet, and approximately 50 miles (80.5 km) from Skagway.
In addition, it is unlikely that minor noise effects in a small, localized area of habitat would have any effect on each stock's ability to recover. In combination, we believe that these factors, as well as the available body of evidence from other similar activities, demonstrate that the potential effects of the specified activities will have only minor, short-term effects on individuals. The specified activities are not expected to impact rates of recruitment or survival and will therefore not result in population-level impacts.
In summary and as described above, the following factors primarily support our preliminary determination that the impacts resulting from this activity are not expected to adversely affect the species or stock through effects on annual rates of recruitment or survival:
• No serious injury or mortality is anticipated or authorized;
• Authorized Level A harassment would be very small amounts and of low degree;
• For all species, Taiya Inlet is a very small and peripheral part of their range;
• The intensity of anticipated takes by Level B harassment is relatively low for all stocks. Level B harassment would be primarily in the form of behavioral disturbance, resulting in avoidance of the project areas around where impact or vibratory pile driving is occurring, with some low-level TTS that may limit the detection of acoustic cues for relatively brief amounts of time in relatively confined footprints of the activities;
• Effects on species that serve as prey for marine mammals from the activities are expected to be short-term and, therefore, any associated impacts on marine mammal feeding are not expected to result in significant or long-term consequences for individuals, or to accrue to adverse impacts on their populations;
• The ensonified areas are very small relative to the overall habitat ranges of all species and stocks, and would not adversely affect ESA-designated critical habitat for any species or any areas of known biological importance;
• The lack of anticipated significant or long-term negative effects to marine mammal habitat; and
• MOS would implement mitigation measures including soft starts and shutdown zones to minimize the numbers of marine mammals exposed to injurious levels of sound, and to ensure that take by Level A harassment is, at most, a small degree of PTS.
Based on the analysis contained herein of the likely effects of the specified activity on marine mammals and their habitat, and taking into consideration the implementation of the proposed monitoring and mitigation measures, NMFS preliminarily finds that the total marine mammal take from the proposed activity will have a negligible impact on all affected marine mammal species or stocks.
As noted previously, only small numbers of incidental take may be authorized under sections 101(a)(5)(A) and (D) of the MMPA for specified activities other than military readiness activities. The MMPA does not define small numbers and so, in practice, where estimated numbers are available, NMFS compares the number of individuals taken to the most appropriate estimation of abundance of the relevant species or stock in our determination of whether an authorization is limited to small numbers of marine mammals. When the predicted number of individuals to be taken is fewer than one-third of the species or stock abundance, the take is considered to be of small numbers. Additionally, other qualitative factors may be considered in the analysis, such as the temporal or spatial scale of the activities.
The amount of take NMFS proposes to authorize is below one-third of the estimated stock abundance for all species. This is likely a conservative estimate because we assume all takes are of different individual animals, which is likely not the case. Some individuals may return multiple times in a day, but PSOs would count them as separate takes if they cannot be individually identified.
The most recent estimate for the Alaska stock of Dall's porpoise was 13,110 animals, however this number just accounts for a portion of the stock's range. Therefore, the 183 takes of this stock proposed for authorization is believed to be an even smaller portion of the overall stock abundance.
Based on the analysis contained herein of the proposed activity (including the proposed mitigation and monitoring measures) and the anticipated take of marine mammals, NMFS preliminarily finds that small numbers of marine mammals would be taken relative to the population size of the affected species or stocks.
In order to issue an IHA, NMFS must find that the specified activity will not have an “unmitigable adverse impact” on the subsistence uses of the affected marine mammal species or stocks by Alaskan Natives. NMFS has defined “unmitigable adverse impact” in 50 CFR 216.103 as an impact resulting from the specified activity: (1) That is likely to reduce the availability of the species to a level insufficient for a harvest to meet subsistence needs by: (i) Causing the marine mammals to abandon or avoid hunting areas; (ii) Directly displacing subsistence users; or (iii) Placing physical barriers between the marine mammals and the subsistence hunters; and (2) That cannot be sufficiently mitigated by other measures to increase the availability of marine mammals to allow subsistence needs to be met.
In the Skagway area, sea lions and harbor seals are available for subsistence harvest authorized under the MMPA. The subsistence areas used by the Hoonah and Angoon communities are in the vicinity of the project area, but will not directly overlap with the project areas. During subsistence harvest in Southeast Alaska in 2012, the most recent year of available data from the Alaska Department of Fish and Game, 595 harbor seals were taken, while only 9 sea lions were taken in the region (Wolfe
The proposed activity will take place in Taiya Inlet, and no activities overlap with subsistence hunting areas; therefore, there are no relevant subsistence uses of marine mammals adversely impacted by this action. The proposed project is not likely to adversely impact the availability of any marine mammal species or stocks that are commonly used for subsistence purposes or to impact subsistence harvest of marine mammals in the region because:
• Construction activities are localized and temporary;
• Mitigation measures will be implemented to minimize disturbance of marine mammals in the action area; and,
• The project will not result in significant changes to availability of subsistence resources.
Based on the description of the specified activity, the measures described to minimize adverse effects on the availability of marine mammals for subsistence purposes, and the proposed mitigation and monitoring measures, NMFS has preliminarily determined that there will not be an unmitigable adverse impact on subsistence uses from MOS's proposed activities.
Section 7(a)(2) of the Endangered Species Act of 1973 (ESA; 16 U.S.C. 1531
NMFS is proposing to authorize take of the Central North Pacific stock of humpback whale and the Western US stock of Steller sea lion, which are listed or include individuals that are listed under the ESA.
The Permits and Conservation Division has requested initiation of section 7 consultation with the Alaska Region for the issuance of this IHA. NMFS will conclude the ESA consultation prior to reaching a determination regarding the proposed issuance of the authorization.
As a result of these preliminary determinations, NMFS proposes to issue an IHA to MOS for conducting construction in Skagway, Alaska provided the previously mentioned mitigation, monitoring, and reporting requirements are incorporated. A draft of the proposed IHA can be found at:
We request comment on our analyses, the proposed authorization, and any other aspect of this notice of proposed IHA for the proposed terminal redevelopment project. We also request comment on the potential renewal of this proposed IHA as described in the paragraph below. Please include with your comments any supporting data or literature citations to help inform decisions on the request for this IHA or a subsequent renewal IHA.
On a case-by-case basis, NMFS may issue a one-time, 1-year renewal IHA following notice to the public providing an additional 15 days for public comments when (1) up to another year of identical or nearly identical activities as described in the Description of Proposed Activity section of this notice is planned or (2) the activities as described in the Description of Proposed Activity section of this notice would not be completed by the time the IHA expires and a renewal would allow for completion of the activities beyond that described in the
• A request for renewal is received no later than 60 days prior to the needed renewal IHA effective date (recognizing that the renewal IHA expiration date cannot extend beyond 1 year from expiration of the initial IHA).
• The request for renewal must include the following:
(1) An explanation that the activities to be conducted under the requested renewal IHA are identical to the activities analyzed under the initial IHA, are a subset of the activities, or include changes so minor (
(2) A preliminary monitoring report showing the results of the required monitoring to date and an explanation showing that the monitoring results do not indicate impacts of a scale or nature not previously analyzed or authorized.
Upon review of the request for renewal, the status of the affected species or stocks, and any other pertinent information, NMFS determines that there are no more than minor changes in the activities, the mitigation and monitoring measures will remain the same and appropriate, and the findings in the initial IHA remain valid.
National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.
Notice; receipt of application.
Notice is hereby given that Erin Ashe, Ph.D., Oceans Initiative, 117 E Louisa St. #135, Seattle, Washington 98102, has applied in due form for a permit to conduct research or marine mammals.
Written, telefaxed, or email comments must be received on or before May 18, 2023.
The application and related documents are available for review by selecting “Records Open for Public Comment” from the “Features” box on the Applications and Permits for Protected Species (APPS) home page,
Written comments on this application should be submitted via email to
Those individuals requesting a public hearing should submit a written request via email to
Courtney Smith, Ph.D. or Sara Young, (301) 427-8401.
The subject permit is requested under the authority of the Marine Mammal Protection Act of 1972, as amended (MMPA; 16 U.S.C. 1361
The applicant requests to take pinnipeds and cetaceans in the coastal and inland waters of Washington State during vessel and aerial (unmanned
In compliance with the National Environmental Policy Act of 1969 (42 U.S.C. 4321
Concurrent with the publication of this notice in the
Consumer Financial Protection Bureau.
Notice and request for comment.
In accordance with the Paperwork Reduction Act of 1995 (PRA), the Consumer Financial Protection Bureau (CFPB or Bureau) is publishing this notice seeking comment on a Generic Information Collection titled “Junk Fees Timing Study” prior to requesting the Office of Management and Budget's (OMB's) approval of this collection under the Generic Information Collection “Generic Information Collection Plan for Studies of Consumers Using Controlled Trials in Field and Economic Laboratory Settings” under OMB Control Number 3170-0048.
Written comments are encouraged and must be received on or before May 18, 2023 to be assured of consideration.
You may submit comments, identified by the title of the information collection, OMB Control Number (see below), and docket number (see above), by any of the following methods:
•
•
•
Please note that comments submitted after the comment period will not be accepted. In general, all comments received will become public records, including any personal information provided. Sensitive personal information, such as account numbers or Social Security numbers, should not be included.
Requests for additional information should be directed to Anthony May, PRA Officer, at (202-435-7278), or email:
Office of Postsecondary Education, Department of Education.
Notice.
The Department of Education (Department) is issuing a notice inviting applications for new awards for fiscal year (FY) 2023 for the Alaska Native and Native Hawaiian-Serving Institutions (ANNH) Program, Part A, Assistance Listing Numbers 84.031N (Alaska Native) and 84.031W (Native Hawaiian). This notice relates to the approved information collection under OMB control number 1840-0810.
For the addresses for obtaining and submitting an application, please refer to our Common Instructions for Applicants to Department of Education Discretionary Grant Programs, published in the
Robyn Wood, U.S. Department of Education, 400 Maryland Avenue SW, Room 2B203, Washington, DC 20202-4260. Telephone: (202) 987-1577. Email:
If you are deaf, hard of hearing, or have a speech disability and wish to access telecommunications relay services, please dial 7-1-1.
Students' sense of belonging impacts postsecondary retention.
Mental health concerns for college students have increased due to a growing number of student exposures to trauma and disruptions in learning and disengagement from school and peers.
Through this grant program, the Department encourages Alaska Native and Native Hawaiian-Serving Institutions to develop, create, or enhance programs that foster students' sense of belonging and to implement services that will help students complete their degree programs. Through the competitive preference priorities for this grant competition, the Department invites applicants to submit proposals to provide high-quality learning, improve student engagement, and meet the needs of Native students.
These priorities are:
Projects that are designed to improve students' social, emotional, academic, and career development, with a focus on underserved students (as defined in this notice), by creating a positive, inclusive, and identity-safe climate at IHEs through one or more of the following activities:
(a) Fostering a sense of belonging and inclusion for underserved students.
(b) Implementing evidence-based practices for advancing student success for underserved students.
Projects that are designed to increase postsecondary access, affordability, completion, and success for underserved students by addressing one or more of the following priority areas:
(a) Increasing the number and proportion of underserved students who enroll in and complete postsecondary education programs, which may include strategies related to college preparation, awareness, application, selection, advising, counseling, and enrollment.
(b) Supporting the development and implementation of student success programs that integrate multiple comprehensive and evidence-based services or initiatives, such as academic advising, structured/guided pathways, career services, credit-bearing academic undergraduate courses focused on career, and programs to meet basic needs, such as housing, childcare, transportation, student financial aid, and access to technological devices.
Under 34 CFR 607.10(c)(13), grantees may not use funds awarded under this program to pay directly for childcare and transportation expenses.
(c) Supporting the development and implementation of high-quality and accessible learning opportunities, including learning opportunities that are accelerated or hybrid online; credit-bearing; work-based; and flexible for working students.
(d) Providing secondary school students with access to career exploration and advising opportunities to help students make informed decisions about their postsecondary enrollment decisions and to place them on a career path.
This priority is:
Projects that support activities to strengthen and institutionalize Native language preservation and revitalization.
Applicants must include in the one-page abstract submitted with the application a statement indicating whether they are addressing competitive preference priority 1, competitive preference priority 2, the invitational priority, any combination of these priorities, or all of these priorities. If the applicant has addressed the priorities, this information also must be listed on the ANNH Program Profile form in the application booklet.
(A) is an eligible institution under section 1058(b) of title 20; and
(B) at the time of application, has an enrollment of undergraduate students that is at least 20 percent Alaska Native students.
In developing logic models, applicants may want to use resources such as the Regional Educational Laboratory Program's (REL Pacific) Education Logic Model Application User Guide, available at the ELM Application (
(A) a citizen of the United States; and
(B) a descendant of the aboriginal people who, prior to 1778, occupied and exercised sovereignty in the area that now comprises the State of Hawaii, as evidenced by—
(i) genealogical records;
(ii) Kupuna (elders) or Kamaaina (long-term community residents) verification; or
(iii) certified birth records.
(A) is an eligible institution under section 1058(b) of title 20; and
(B) at the time of application, has an enrollment of undergraduate students that is at least 10 percent Native Hawaiian students.
(a) A student who is living in poverty or is served by schools with high concentrations of students living in poverty.
(b) A student of color.
(c) A student who is a member of a federally recognized Indian Tribe.
(d) An English learner.
(e) A child or student with a disability.
(f) A lesbian, gay, bisexual, transgender, queer or questioning, or intersex (LGBTQI+) student.
(g) A pregnant, parenting, or caregiving student.
(h) A student impacted by the justice system, including a formerly incarcerated student.
(i) A student who is the first in their family to attend postsecondary education.
(j) A student enrolling in or seeking to enroll in postsecondary education for the first time at the age of 20 or older.
(k) A student who is working full-time while enrolled in postsecondary education.
(l) A student who is enrolled in or is seeking to enroll in postsecondary education who is eligible for a Pell Grant.
(m) An adult student in need of improving their basic skills or an adult student with limited English proficiency.
(n) A military- or veteran-connected student.
In 2008, the HEA was amended by the Higher Education Opportunity Act of 2008 (HEOA), Public Law 110-315. Please note that the regulations for ANNH in 34 CFR part 607 have not been updated to reflect
Projects will be awarded and must be operated in a manner consistent with the nondiscrimination requirements contained in the Federal civil rights laws.
A cooperative arrangement is an arrangement to carry out allowable grant activities between an institution eligible to receive a grant under this part and another eligible or ineligible IHE, under which the resources of the cooperating institutions are combined and shared to better achieve the purposes of this part and avoid costly duplication of effort.
Contingent upon the availability of funds and the quality of applications, we may make additional awards in subsequent years from the list of unfunded applications from this competition.
The Department is not bound by any estimates in this notice.
1. a.
To qualify as an eligible institution under the ANNH Program, an institution also must—
(i) Be accredited or preaccredited by a nationally recognized accrediting agency or association that the Secretary has determined to be a reliable authority as to the quality of education or training offered;
(ii) Be legally authorized by the State in which it is located to be a junior or community college or to provide an educational program for which it awards a bachelor's degree;
(iii) Demonstrate that it (1) has an enrollment of needy students as described in 34 CFR 607.3; and (2) has low average education and general expenditures per full-time equivalent (FTE) undergraduate student as described in 34 CFR 607.4.
The notice announcing the FY 2023 process for designation of eligible institutions, and inviting applications for waiver of eligibility requirements, was published in the
b.
An eligible IHE that is not a current grantee under the above-cited programs may apply for a FY 2023 grant under all title III, part A programs for which it is eligible, as well as receive consideration for a grant under the HSI program. However, a successful applicant may receive only one grant, as described in 34 CFR 607.2(g)(1).
c.
2. a.
b.
3.
1.
2.
3.
4.
• A “page” is 8.5″ x 11″, on one side only, with 1″ margins at the top, bottom, and both sides.
• Double-space (no more than three lines per vertical inch) all text in the application narrative, including titles, headings, footnotes, quotations, references, and captions, as well as all text in charts, tables, figures, and graphs.
• Use a font that is either 12 point or larger and no smaller than 10 pitch (characters per inch).
• Use one of the following fonts: Times New Roman, Courier, Courier New, or Arial.
The recommended page limit does not apply to the cover sheet; the budget section, including the narrative budget justification; the assurances and certifications; or the one-page abstract and the bibliography. However, the recommended page limit does apply to all of the application narrative.
The Budget Information Non-Construction Programs form (ED 524) sections A-C are not the same as the narrative response to the Budget section of the selection criteria.
1.
(a)
The extent to which—
(1) The strengths, weaknesses, and significant problems of the institution's academic programs, institutional management, and fiscal stability are clearly and comprehensively analyzed and result from a process that involved major constituencies of the institution. (5 points)
(2) The goals for the institution's academic programs, institutional management, and fiscal stability are realistic and based on comprehensive analysis. (5 points)
(3) The objectives stated in the plan are measurable, related to institutional goals, and, if achieved, will contribute to the growth and self-sufficiency of the institution. (5 points)
(4) The plan clearly and comprehensively describes the methods and resources the institution will use to institutionalize practice and improvements developed under the proposed project, including, in particular, how operational costs for personnel, maintenance, and upgrades of equipment will be paid with institutional resources. (5 points)
(b)
The extent to which the objectives for each activity are—
(1) Realistic and defined in terms of measurable results. (8 points)
(2) Directly related to the problems to be solved and to the goals of the comprehensive development plan. (7 points)
(c)
The Secretary considers the quality of the design of the proposed project. In determining the quality of the design of the proposed project, the Secretary considers the following factor:
(1) The extent to which the proposed project demonstrates a rationale.
(d)
The extent to which—
(1) The implementation strategy for each activity is comprehensive. (6 points)
(2) The rationale for the implementation strategy for each activity is clearly described and is supported by the results of relevant studies or projects. (6 points)
(3) The timetable for each activity is realistic and likely to be attained. (4 points)
(e)
The extent to which—
(1) The past experience and training of key professional personnel are directly related to the stated activity objectives. (4 points)
(2) The time commitment of key personnel is realistic. (4 points)
(f)
The extent to which—
(1) Procedures for managing the project are likely to ensure efficient and effective project implementation. (5 points)
(2) The project coordinator and activity directors have sufficient authority to conduct the project effectively, including access to the president or chief executive officer. (5 points)
(g)
The extent to which—
(1) The data elements and the data collection procedures are clearly described and appropriate to measure the attainment of activity objectives and to measure the success of the project in achieving the goals of the comprehensive development plan. (6 points)
(2) The data analysis procedures are clearly described and are likely to produce formative and summative results on attaining activity objectives and measuring the success of the project on achieving the goals of the comprehensive development plan. (6 points)
(h)
The extent to which the proposed costs are necessary and reasonable in relation to the project's objectives and scope.
2.
In addition, in making a competitive grant award, the Secretary requires various assurances, including those applicable to Federal civil rights laws that prohibit discrimination in programs or activities receiving Federal financial assistance from the Department (34 CFR 100.4, 104.5, 106.4, 108.8, and 110.23).
A panel of three non-Federal reviewers will review and score each application in accordance with the selection criteria and the competitive preference priorities. A rank order funding slate will be made from this review. Awards will be made in rank order according to the average score received from the peer review.
In tie-breaking situations for development grants, 34 CFR 607.23(b) requires that we award additional points in the following three areas. For purposes of this program, we award one additional point to an application from an IHE that has an endowment fund of which the current market value, per full-time equivalent enrolled student, is less than the average current market value of the endowment funds, per FTE enrolled student, at comparable type institutions that offer similar instruction. We award one additional point to an application from an IHE that has expenditures for library materials per FTE enrolled student that are less than the average expenditure for library materials per FTE enrolled student at similar type institutions. We also add one additional point to an application from an IHE that proposes to carry out one or more of the following activities—
(1) Faculty development;
(2) Funds and administrative management;
(3) Development and improvement of academic programs;
(4) Acquisition of equipment for use in strengthening management and academic programs;
(5) Joint use of facilities; and
(6) Student services.
For the purpose of these funding considerations, we use 2020-2021 data.
If a tie remains after applying the tie-breaker mechanism above, priority will be given to applicants that have the lowest endowment values per FTE enrolled student.
3.
4.
Please note that, if the total value of your currently active grants, cooperative agreements, and procurement contracts from the Federal Government exceeds $10,000,000, the reporting requirements in 2 CFR part 200, Appendix XII, require you to report certain integrity information to FAPIIS semiannually. Please review the requirements in 2 CFR part 200, Appendix XII, if this grant plus all the other Federal funds you receive exceed $10,000,000.
5.
(a) Selecting recipients most likely to be successful in delivering results based on the program objectives through an objective process of evaluating Federal award applications (2 CFR 200.205);
(b) Prohibiting the purchase of certain telecommunication and video surveillance services or equipment in alignment with section 889 of the National Defense Authorization Act of 2019 (Pub. L. 115-232) (2 CFR 200.216);
(c) Providing a preference, to the extent permitted by law, to maximize use of goods, products, and materials produced in the United States (2 CFR 200.322); and
(d) Terminating agreements in whole or in part to the greatest extent authorized by law if an award no longer effectuates the program goals or agency priorities (2 CFR 200.340).
1.
If your application is not evaluated or not selected for funding, we notify you.
2.
We reference the regulations outlining the terms and conditions of an award in the
3.
4.
(b) At the end of your project period, you must submit a final performance report, including financial information,
5.
(a) The percentage change, over the 5-year period, of the number of full-time degree-seeking undergraduates enrolled at Alaska Native and Native Hawaiian-Serving Institutions (
(b) The percentage of first-time, full-time degree-seeking undergraduate students at 4-year Alaska Native and Native Hawaiian-Serving Institutions who were in their first year of postsecondary enrollment in the previous year and are enrolled in the current year at the same Alaska Native and Native Hawaiian-Serving Institution;
(c) The percentage of first-time, full-time degree-seeking undergraduate students at 2-year Alaska Native and Native Hawaiian-Serving Institutions who were in their first year of postsecondary enrollment in the previous year and are enrolled in the current year at the same Alaska Native and Native Hawaiian-Serving Institution;
(d) The percentage of first-time, full-time degree-seeking undergraduate students enrolled at 4-year Alaska Native and Native Hawaiian-Serving Institutions who graduate within 6 years of enrollment; and
(e) The percentage of first-time, full-time degree-seeking undergraduate students enrolled at 2-year Alaska Native and Native Hawaiian-Serving Institutions who graduate within 3 years of enrollment.
6.
In making a continuation award, the Secretary also considers whether the grantee is operating in compliance with the assurances in its approved application, including those applicable to Federal civil rights laws that prohibit discrimination in programs or activities receiving Federal financial assistance from the Department (34 CFR 100.4, 104.5, 106.4, 108.8, and 110.23).
You may also access documents of the Department published in the
Federal Student Aid, Department of Education.
Notice.
The Secretary invites postsecondary educational institutions (institutions) that currently participate in the Second Chance Pell experiment to apply to participate in a revised Second Chance Pell institution-based experiment under the Experimental Sites Initiative (ESI).
Letters of application to participate in the revised experiment described in this notice must be received by the Department of Education (the Department) no later than May 18, 2023. Letters of interest received after May 18, 2023 may still, at the discretion of the Secretary, be considered for participation.
Letters of interest must be submitted by electronic mail to the following email address:
Carolyn Rose, U.S. Department of Education, Federal Student Aid, 400 Maryland Avenue SW, Washington, DC 20202. Telephone: (202) 803-1502. Email:
If you are deaf, hard of hearing, or have a speech disability and wish to access telecommunications relay services, please dial 7-1-1.
The Second Chance Pell experiment was established in 2015 and provides need-based Pell Grants to incarcerated individuals to allow them to participate in eligible postsecondary programs. The experiment has expanded to over 200 programs around the country. With the passage of the FAFSA Simplification Act in 2020, Congress further expanded the ability to serve confined or incarcerated individuals by reinstating Pell Grant eligibility for otherwise-eligible confined or incarcerated individuals enrolled in eligible prison education programs (PEPs) beginning July 1, 2023.
The revised Second Chance Pell experiment will provide new waivers to allow current Second Chance Pell institutions to continue serving their students after July 1, 2023 while also continuing to allow the Department to learn more about the challenges schools face when implementing the new regulations. This will give participating institutions time to seek Department approval of their PEPs (as defined under the new regulations in 34 CFR part 668 subpart P) and avoid interrupting the educational opportunities of students currently enrolled in approved programs under the experiment.
Specifically, the revised experiment will allow current participating institutions to continue offering their current programs to confined or incarcerated individuals for up to 3 award years while they work through the application and approval process for the PEP(s) they wish to offer under the new provisions. Through the revised experiment, the Department will also evaluate the impact and effectiveness of the new regulations as institutions transition to PEP.
Under the revised experiment, the education and training programs offered by the postsecondary institution must continue to meet all title IV, HEA program eligibility requirements. While the program must be credit-bearing and result in a certificate or degree, up to 1 full year of remedial coursework is allowed for students in need of academic support.
• Partner with their current Federal or State correctional facility(ies) to offer one or more title IV, HEA eligible academic program(s) to incarcerated students.
• Work with the partnering correctional facilities to encourage interested students to submit a FAFSA;
• Only enroll students in postsecondary education and training programs that prepare them for occupations from which they are not legally barred from entering due to restrictions on formerly incarcerated individuals obtaining any necessary licenses or certifications for those occupations in the State in which the partnering facility(ies) are located;
• Disclose to interested students and to the Department information about the options available for incarcerated students to complete any remaining program requirements post-release;
• As appropriate, offer students the opportunity to continue their enrollment in the academic program if the student is transferred to another correctional facility or released from prison prior to program completion;
• Inform students of the academic and financial options available if they are not able to complete the academic program while incarcerated. This includes explaining how the students can continue in the program after release, transfer credits earned in the program to another program offered by the institution, or transfer credits earned in the program to another postsecondary institution;
• In partnership with Federal or State correctional facilities, provide academic and career guidance, as well as transition services, to incarcerated students to support successful reentry.
• Use the Pell Grant funds made available to eligible students through this experiment to supplement, not supplant, existing investments in postsecondary prison-based education programs by either the postsecondary institution, the correctional facility, or outside sources;
• Report all correctional facilities where the institution offers 50 percent or more of an educational program as an additional location regardless of whether students enrolled receive instruction in-person or through distance education at that location
• Actively seek PEP approval under the new regulations for programs offered under the revised experiment or prepare a plan to wind down programs it does not plan to continue under the new provisions within three years.
An institution may continue to enroll students in existing programs as long as it continues to demonstrate progress toward compliance with the new requirements. However, an institution that participates in the revised experiment may not expand beyond the correctional facilities with which it currently partners or beyond the programs it offers already offer under the experiment.
In addition, programs under the experiment are subject to the following requirements:
•
•
•
In addition, participating institutions must reach specific milestones that demonstrate progress toward developing approved PEP(s).
• Determined the programs(s) to be offered under the new provisions. The institution must be able to provide a description of the proposed program(s), including the educational credential offered (degree level or certificate) and the field of study as required by 34 CFR 668.238(b)(1);
• Received approval from the oversight entity to offer the program(s) at the correctional facility;
• Received accreditor approval to offer at least one PEP; and
• Informed the Department of the date on which it plans to submit the PEP application to the Department (the date must be on or before January 1, 2026).
As part of this 2024-25 award year milestone, the institution must also provide the status of the following additional PEP requirements and the date they anticipate submitting this information to the Department:
• The methodology, including thresholds, benchmarks, standards, metrics, data, and other information the oversight entity will use in approving the prison education program and how all of the information was/will be collected;
• Information about the types of services (to be) offered to admitted students, including orientation, tutoring, academic and career advising, and reentry counseling;
• The status of all programs currently offered under the experiment and the date on which those programs will be reported to the Department. If the institution plans to offer programs beyond the first program at the first two additional locations, specific reporting requirements outlined in 34 CFR 600.21(a) will apply. The institution must prepare all programs offered under the experiment, that it plans to continue after the experiment ends, to be in compliance with the new PEP provisions as outlined in 34 CFR 668.238(c). Any program beyond the first program at the first two additional locations must be reported to the Department prior to June 30, 2026, or students attending those programs will not be eligible for Pell Grants after the conclusion of the experiment. The Department will perform ongoing monitoring during the experiment to ensure that participating institutions meet these requirements. The Department will monitor participating institutions to ensure they are making progress toward developing a PEP that will be submitted for consideration under subpart P of 34 CFR part 668. The Department will also monitor all other program(s) the institution is offering under the experiment to ensure the institution has a plan to report those programs pursuant to 34 CFR 668.238(c) so they may continue offering Pell Grants to students enrolled in those programs after the experiment ends.
By agreeing to the alternative procedures and requirements for this
• HEA section 484(t)(3)
• 34 CFR 668.32(c)(2)(ii)
• 34 CFR 668, subpart P
All other provisions and regulations of the title IV HEA student assistance programs will remain in effect.
• Identifying information (
• The name of the program and Classification of Instructional Programs (CIP) code in which the student enrolled;
• The number of postsecondary credits the student attempted, and the number earned;
• Indicators of academic progress, including program completion; and
• Other experiment-specific information as determined by the Department.
In addition to the annual reporting, participating institutions will be required to upload, on a monthly basis, the Excel spreadsheet in COD (or its successor system) to provide the Department with:
• Identifying information for students receiving Pell Grant funds under the experiment; and
• The status of the institution's development of all PEPs it plans to offer under the new provisions.
Participating institutions will also be required to complete annual surveys collecting information about:
• The name of each program offered under the experiment, the name and address of the facility(ies) at which the program is being offered, and the oversight entity responsible for the facility;
• The progress that the institution has made toward complying with the new statutory and regulatory requirements;
• The postsecondary instruction (if any) provided to incarcerated population(s) prior to participating in the experiment;
• The institution's arrangement(s) with correctional facilities and oversight entities and any unforeseen challenges;
• Terms of the postsecondary institution's arrangements with correctional facilities and oversight entities (
• Challenges encountered by the institution as it develops a PEP to comply with the new provisions, and the specific solutions the institution put in place to respond to those challenges;
• Benefits experienced by the institution or its students as a PEP complying with the new provisions is put in place; and
• Balanced and thoughtful reflection of what the institution and incarcerated students gain and lose with the adoption of the new PEP provisions that are put in place.
The experiment will be evaluated using information the institution provides to the Department, as well as any other information available to the Department. The Department seeks to evaluate specific challenges encountered by the institution while administering the experiment, including:
• Partnering with correctional facilities to offer postsecondary education to incarcerated students;
• Incarcerated students' ability to complete the FAFSA;
• The verification process for incarcerated students;
• The program approval process for PEPs under the new provisions;
• The process for an oversight entity to make the determination that program(s) being developed under the new provisions are operating in the best interest of students; and
• Challenges that the institution encountered while obtaining programmatic accreditation for PEPs and how they were resolved.
The Department also intends to evaluate how institutions successfully implemented the new provisions, including the PEP approval process and metrics used by the oversight entity to determine if the program is operating in the best interest of students.
The Department will finalize the specific evaluation and reporting requirements prior to the start of the experiment, in consultation with the Department's Institute of Education Sciences. An information collection will be made available for public comment regarding further information gathering connected with this notice.
1. Only institutions that are approved and actively participating in the Second Chance Pell experiment as of June 30, 2023, may participate in the revised experiment.
2. An institution interested in participating in the revised experiment must:
a. Notify the Department of its desire to participate in the revised experiment by submitting a letter of interest;
b. Agree to make efforts to reach the specific milestones that demonstrate progress toward developing approved PEP(s), as outlined in the
c. Be in compliance with the reporting requirements under the current experiment as outlined in the Program Participation Agreement (PPA) Amendment.
3. The institution must be in compliance with title IV HEA regulatory and statutory requirements, including administrative capability and financial responsibility; and
4. The institution must adequately describe in its letter of interest how it will comply with the requirements of the revised experiment outlined in this notice, including its plan and the date it expects to comply with the new PEP provisions in subpart P of 34 CFR part 668.
You may also access documents of the Department published in the
Office of Postsecondary Education, Department of Education.
Notice.
The Department of Education (Department) is issuing a notice inviting applications for fiscal year (FY) 2023 for the Rural Postsecondary and Economic Development (RPED) Grant Program, conducted under the Fund for the Improvement of Postsecondary Education (FIPSE), Assistance Listing Number 84.116W. This notice relates to the approved information collection under OMB control number 1894-0006.
For the addresses for obtaining and submitting an application, please refer to our Common Instructions for Applicants to Department of Education Discretionary Grant Programs, published in the
Kurrinn Abrams, U.S. Department of Education, 400 Maryland Avenue SW, Washington, DC 20202-4260. Telephone: (202) 987-1920. Email:
If you are deaf, hard of hearing, or have a speech disability and wish to access telecommunications relay services, please dial 7-1-1.
For rural students, and particularly low-income and underserved rural students, barriers to accessing postsecondary education include difficulties in accessing high speed internet, transportation, child care, and healthcare; as well as challenges of experiencing poverty, food insecurity, and housing insecurity. Furthermore, many rural students who do decide to attend college are first-generation students who lack sufficient college preparation in high school,
Many of these challenges result from geographic isolation, distance from services, and a lack of resources and institutions to support community members. Rural communities are often located in education deserts, which may limit students' exposure or convenient access to postsecondary institutions.
For rural students who do attend postsecondary education, research has shown that rural high school graduates were more likely to enroll in 2-year colleges (44 percent) compared to their urban counterparts (39 percent). However, even after controlling for differences in academic achievement, poverty, and distance between high schools and colleges, students who graduate from rural high schools are still more likely than students who graduate from nonrural schools to enroll in a 2-year rather than a 4-year college.
To overcome these barriers, many States are beginning to introduce early college programs that expose secondary students to postsecondary education
Furthermore, higher education attainment is correlated with increased career opportunities, higher individual lifetime earnings, better quality of life, and positive contributions to society.
Rural postsecondary institutions, specifically 2-year rural postsecondary institutions, are best positioned to enhance and develop programs that improve the preparation, support, and retention of rural students in higher education, and that help them to graduate from college and transition into in-demand and well-paying occupations. To this end, the RPED Grant Program is designed to support postsecondary enrollment and completion by addressing the challenges rural students face accessing postsecondary education that will prepare them for high-skill, high-wage, and in-demand occupations.
These priorities are:
Under this priority, an applicant must demonstrate one or more of the following:
(a) The applicant proposes to serve a community that is served by one or more LEAs with a locale code of 32, 33, 41, 42, or 43;
(b) The applicant proposes a project in which a majority of the schools served have a locale code of 32, 33, 41, 42, or 43;
(c) The applicant is an institution of higher education (IHE) with a rural campus setting, or the applicant proposes to serve a campus with a rural setting. Rural settings include any of the following: Town-Fringe, Town-Distant, Town-Remote, Rural Fringe, Rural-Distant, Rural-Remote, as defined by the NCES College Navigator search tool.
Applicants are encouraged to retrieve locale codes from the NCES School District search tool (
Projects that are designed to increase postsecondary access, affordability, completion, and success for underserved students by addressing one or more of the following priority areas:
(a) Increasing postsecondary education access and reducing the cost of college by creating clearer pathways for students between institutions and making transfer of course credits more seamless and transparent.
(b) Increasing the number and proportion of underserved students who enroll in and complete postsecondary education programs, which may include strategies related to college preparation, awareness, application, selection, advising, counseling, and enrollment.
(c) Supporting the development and implementation of student success programs that integrate multiple comprehensive and evidence-based services or initiatives, such as academic advising, structured/guided pathways, career services, credit-bearing academic undergraduate courses focused on career, and programs to meet basic needs, such as housing, child care and transportation, student financial aid, and access to technological devices.
(d) Supporting the development and implementation of high-quality and accessible learning opportunities, including learning opportunities that are accelerated or hybrid online; credit-bearing; work-based; and flexible for working students.
(e) Supporting the development and implementation of evidence-based strategies to promote students' development of knowledge and skills necessary for success in the workforce and civic life.
(f) Providing secondary school students with access to career exploration and advising opportunities to help students make informed decisions about their postsecondary
This priority is:
Projects that are designed to take a systemic evidence-based approach to improving outcomes for underserved students in coordinating efforts with Federal, State, or local agencies, or community-based organizations, that support students, to address college readiness (Up to 5 points), workforce development (Up to 5 points), or both.
These priorities are:
Projects that are designed to provide long-term academic and career advising relationships, and exposure to postsecondary opportunities to students as early as 8th grade to support them through their transition to postsecondary education, including potential transitions from 2- to 4-year programs.
Projects that include partnerships with regional economic development or workforce agencies, regional employers, or other relevant nonprofit organizations and support alignment of academic programs with, and development of, high-quality career pathways aligned to high-skill, high-wage, and in-demand industry sectors and occupations in the region.
Projects that are designed to provide strategies for developing and maintaining long-term academic and career advising relationships with community college students to support them through their transition to a 4-year IHE.
(a) In General. (i) An industry sector that has a substantial current or potential impact (including through jobs that lead to economic self-sufficiency and opportunities for advancement) on the State, regional, or local economy, as appropriate, and that contributes to the growth or stability of other supporting businesses, or the growth of other industry sectors; or
(ii) An occupation that currently has or is projected to have a number of positions (including positions that lead to economic self-sufficiency and opportunities for advancement) in an industry sector so as to have a significant impact on the State, regional, or local economy, as appropriate.
In developing logic models, applicants may want to use resources such as the Regional Educational Laboratory Program's (REL Pacific) Education Logic Model Application, available at
(a) A student who is living in poverty or is served by schools with high concentrations of students living in poverty.
(b) A student of color.
(c) A student who is a member of a federally recognized Indian Tribe.
(d) An English learner (as defined in this notice).
(e) A child or student with a disability (as defined in this notice).
(f) A disconnected youth (as defined in this notice).
(g) A technologically unconnected youth.
(h) A student experiencing homelessness or housing insecurity.
(i) A pregnant, parenting, or caregiving student.
(j) A student who is the first in their family to attend postsecondary education.
(k) A student enrolling in or seeking to enroll in postsecondary education for the first time at the age of 20 or older.
(l) A student who is working full-time while enrolled in postsecondary education.
(m) A student who is enrolled in or is seeking to enroll in postsecondary education who is eligible for a Pell Grant.
(n) A student performing significantly below grade level.
For the purpose of the definition of
Projects will be awarded and must be operated in a manner consistent with the nondiscrimination requirements contained in Federal civil rights laws.
Contingent upon the availability of funds and the quality of applications, we may make additional awards in subsequent years from the list of unfunded applications from this competition.
The maximum award is based on a 4-year budget period. Applicants will need to prepare a multiyear budget request for up to 4 years.
The Department is not bound by any estimates in this notice.
1.
2. a.
b.
c.
d.
3.
1.
2.
3.
4.
• A “page” is 8.5″ x 11″, on one side only, with 1″ margins at the top, bottom, and both sides.
• Double-space (no more than three lines per vertical inch) all text in the application narrative, except titles, headings, footnotes, quotations, references, and captions.
• Use a font that is either 12 point or larger or no smaller than 10 pitch (characters per inch).
• Use one of the following fonts: Times New Roman, Courier, Courier New, or Arial.
The recommended 50-page limit applies only to the application narrative and does not apply to Part I, the cover sheet; Part II, the budget section, including the narrative budget justification; Part IV, the assurances and certifications; or the one-page abstract, the resumes, the bibliography, or the letters of support. We recommend that any application addressing the priorities include no more than three additional pages for each priority addressed.
5.
1.
(a)
(1) The Secretary considers the quality of the design of the proposed project.
(2) In determining the quality of the design of the proposed project, the Secretary considers the following factors:
(i) The extent to which the goals, objectives, and outcomes to be achieved by the proposed project are clearly specified and measurable. (Up to 10 points)
(ii) The extent to which the design of the proposed project is appropriate to, and will successfully address, the needs of the target population or other identified needs. (Up to 10 points)
(iii) The extent to which the design of the proposed project includes a thorough, high-quality review of the relevant literature, a high-quality plan for project implementation, and the use of appropriate methodological tools to ensure successful achievement of project objectives. (Up to 5 points)
(iv) The extent to which the proposed project demonstrates a rationale (as defined in this notice). (Up to 5 points)
(v) The extent to which the proposed project is designed to build capacity and yield results that will extend beyond the period of Federal financial assistance. (Up to 3 points)
(vi) The extent to which the services to be provided by the proposed project involve the collaboration of appropriate partners for maximizing the effectiveness of project services. (Up to 2 points)
(b)
(1) The Secretary considers the quality of the management plan for the proposed project.
(2) In determining the quality of the management plan, the Secretary considers the following factors:
(i) The adequacy of the management plan to achieve the objectives of the proposed project on time and within budget, including clearly defined responsibilities, timelines, and milestones for accomplishing project tasks. (Up to 10 points)
(ii) The extent to which the costs are reasonable in relation to the number of persons to be served and to the anticipated results and benefits. (Up to 5 points)
(iii) The adequacy of mechanisms for ensuring high-quality products and services from the proposed project. (Up to 5 points)
(iv) The adequacy of procedures for ensuring feedback and continuous improvement in the operation of the proposed project. (Up to 5 points)
(v) The extent to which the time commitments of the project director and principal investigator and other key project personnel are appropriate and adequate to meet the objectives of the proposed project. (Up to 10 points)
(c)
(1) The Secretary considers the adequacy of resources for the proposed project.
(2) In determining the adequacy of resources for the proposed project, the Secretary considers the following factors:
(i) The adequacy of support, including facilities, equipment, supplies, and other resources, from the applicant organization or the lead applicant organization. (Up to 5 points)
(ii) The relevance and demonstrated commitment of each partner in the proposed project to the implementation and success of the project. (Up to 5 points)
(d)
(1) The Secretary considers the quality of the evaluation to be conducted of the proposed project.
(2) In determining the quality of the evaluation, the Secretary considers:
(i) The extent to which the methods of evaluation are thorough, feasible, and appropriate to the goals, objectives, and outcomes of the proposed project. (Up to 10 points)
(ii) The extent to which the methods of evaluation provide for examining the effectiveness of project implementation strategies. (Up to 10 points)
2.
In addition, in making a competitive grant award, the Secretary also requires various assurances, including those applicable to Federal civil rights laws that prohibit discrimination in programs or activities receiving Federal financial assistance from the Department (34 CFR 100.4, 104.5, 106.4, 108.8, and 110.23).
For this competition, a panel of external reviewers will read, prepare a written evaluation of, and score all eligible applications using the selection criteria and the competitive preference priority, if applicable, provided in this notice. The individual scores of the reviewers will be added and the sum divided by the number of reviewers to determine the peer review score. The Department may use more than one tier of reviews in evaluating grantees. The Department will prepare a rank order of applications based solely on the evaluation of their quality according to the selection criteria and competitive preference priority points.
3.
4.
Please note that, if the total value of your currently active grants, cooperative agreements, and procurement contracts from the Federal Government exceeds $10,000,000, the reporting requirements in 2 CFR part 200, Appendix XII, require you to report certain integrity information to FAPIIS semiannually. Please review the requirements in 2 CFR part 200, Appendix XII, if this grant plus all the other Federal funds you receive exceed $10,000,000.
5.
(a) Selecting recipients most likely to be successful in delivering results based on the program objectives through an objective process of evaluating Federal award applications (2 CFR 200.205);
(b) Prohibiting the purchase of certain telecommunication and video surveillance services or equipment in alignment with section 889 of the National Defense Authorization Act of 2019 (Pub. L. 115-232) (2 CFR 200.216);
(c) Providing a preference, to the extent permitted by law, to maximize use of goods, products, and materials produced in the United States (2 CFR 200.322); and
(d) Terminating agreements in whole or in part to the greatest extent authorized by law if an award no longer effectuates the program goals or agency priorities (2 CFR 200.340).
1.
If your application is not evaluated or not selected for funding, we notify you.
2.
We reference the regulations outlining the terms and conditions of an award in the
3.
4.
(b) At the end of your project period, you must submit a final performance report, including financial information, as directed by the Secretary. If you receive a multiyear award, you must submit an annual performance report that provides the most current performance and financial expenditure information as directed by the Secretary under 34 CFR 75.118. The Secretary may also require more frequent performance reports under 34 CFR 75.720(c). For specific requirements on reporting, please go to
5.
a. The number of rural students that received direct student services supported by the grant.
b. The change in the annual enrollment rate at grantee institutions of rural students that received direct student services supported by the grant from one year to the next.
c. The number of rural students that received direct student services supported by the grant that transfer to a 4-year institution or obtain a degree or certificate of completion.
d. The number of rural students that received direct student services supported by the grant who obtain an internship, apprenticeship, or employment.
6.
In making a continuation award, the Secretary also considers whether the grantee is operating in compliance with the assurances in its approved application, including those applicable to Federal civil rights laws that prohibit discrimination in programs or activities receiving Federal financial assistance from the Department (34 CFR 100.4, 104.5, 106.4, 108.8, and 110.23).
You may also access documents of the Department published in the
Federal Student Aid (FSA), Department of Education (ED).
Notice.
In accordance with the Paperwork Reduction Act (PRA) of 1995, the Department is proposing an extension without change of a currently approved information collection request (ICR).
Interested persons are invited to submit comments on or before June 20, 2023.
To access and review all the documents related to the information collection listed in this notice, please use
For specific questions related to collection activities, please contact Beth Grebeldinger, 202-377-4018.
The Department, in accordance with the Paperwork Reduction Act of 1995 (PRA) (44 U.S.C. 3506(c)(2)(A)), provides the general public and Federal agencies with an opportunity to comment on proposed, revised, and continuing collections of information. This helps the Department assess the impact of its information collection requirements and minimize the public's reporting burden. It also helps the public understand the Department's information collection requirements and provide the requested data in the desired format. The Department is soliciting comments on the proposed information collection request (ICR) that is described below. The Department is especially interested in public comment addressing the following issues: (1) is this collection necessary to the proper functions of the Department; (2) will this information be processed and used in a timely manner; (3) is the estimate of burden accurate; (4) how might the Department enhance the quality, utility, and clarity of the information to be collected; and (5) how might the Department minimize the burden of this collection on the respondents, including through the use of information technology. Please note that written comments received in response to this notice will be considered public records.
On March 29, 2023, the Commission issued an order directing Commission staff to convene a technical conference to discuss Florida Gas Transmission Company, LLC's justification and support for its proposed renewable natural gas (RNG) quality standards on its pipeline system.
Commission conferences are accessible under section 508 of the Rehabilitation Act of 1973. For accessibility accommodations, please send an email to
For more information about this technical conference including how to participate, virtual and in person meeting details, etc., please contact Deirdra Archie at
Take notice that the following hydroelectric application has been filed with the Commission and is available for public inspection.
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
The Commission strongly encourages electronic filing. Please file motions to intervene and protests using the Commission's eFiling system at
The Commission's Rules of Practice require all intervenors filing documents with the Commission to serve a copy of that document on each person on the official service list for the project. Further, if an intervenor files comments or documents with the Commission relating to the merits of an issue that may affect the responsibilities of a particular resource agency, they must also serve a copy of the document on that resource agency.
k. This application has been accepted but is not ready for environmental analysis.
l. The Franklin Falls Project consists of the following existing facilities: (1) a 148-foot-long, 45-foot-high concrete overflow-type dam at a crest elevation of 1,462.88 feet National Geodetic Vertical Datum of 1929 (NGVD 29) with 2-foot-high flashboards; (2) a reservoir with a surface area of 479 acres and a gross storage capacity of 5,580 acre-feet at pool elevation 1,464.88 feet NGVD 29; (3) an integrated 28-foot-long gated intake structure located on the dam's right (south) side; (4) a 10.5-foot-diameter, 300-foot-long steel pipeline; (5) a 43-foot-high surge tank with a 20-foot-diameter steel shaft; (6) two 10-foot-diameter, 38-foot-long steel penstocks; (7) a powerhouse containing two generating units having a total rated capacity of 2.12 megawatts; (8) 85-foot-long, 2.3-kilovolt (kV) generator leads; (9) a 2.3/46-kV step-up transformer bank; (10) a 300-foot-long, 46-kV transmission line; (11) a tailrace; and (12) appurtenant facilities.
The Franklin Falls Project operates in a modified run-of-river mode. If inflow exceeds the hydraulic capacity of the units, the project operates continuously at full load. When the inflow is less than the hydraulic capacity of the project, the project is operated in a run-of-river mode utilizing pondage as needed for daily flow regulation and to suit power requirements of the New York Independent System Operator. The project has an average annual generation of 10,349 megawatt-hours.
Erie does not propose changes to project facilities or operations. Erie proposes to continue to: (1) provide a minimum base flow of 245 cubic feet per second (cfs) or inflow, whichever is less, from March 1 through June 1 from the Franklin Falls powerhouse; and from June 2 to March 1 reservoir inflow is released from the powerhouse, as needed for the downstream Saranac Project to maintain a minimum base flow of 165 cfs, or inflow, whichever is less; (2) limit the maximum total drawdown of the Franklin Falls impoundment to 2 feet below the top of the flashboards, or 1 foot below the spillway crest when flashboards are not in use (Erie annually installs flashboards at Franklin Falls by the first week of June, unless flow conditions warrant otherwise); (3) provide a minimum flow to the bypassed reach of 125 cfs or inflow, whichever is less, from March 31 through May 31 for the protection of walleye spawning and incubation (the release schedule may be modified on a year-to-year basis based on water temperatures and presence/absence of walleye, upon mutual agreement between the licensee and the New York State Department of Environmental Conservation; and (4) operate and maintain the cartop boat launch and canoe portage.
Erie proposes to modify the project boundary by removing approximately 1.12 acres along the northern shoreline, which are not needed for project operations, and adding approximately 0.14 acre to include the project's existing hand-carry boat launch. In addition, Erie proposes to implement its proposed bald eagle management plan, invasive species management plan, and impoundment drawdown plan.
m. In addition to publishing the full text of this document in the
You may also register online at
n. Anyone may submit a protest or a motion to intervene in accordance with the requirements of Rules of Practice and Procedure, 18 CFR 385.210, 385.211, and 385.214. In determining the appropriate action to take, the Commission will consider all protests filed, but only those who file a motion to intervene in accordance with the Commission's Rules may become a party to the proceeding. Any protests or motions to intervene must be received on or before the specified deadline date for the particular application.
All filings must (1) bear in all capital letters the title “PROTEST” or “MOTION TO INTERVENE;” (2) set forth in the heading the name of the applicant and the project number of the application to which the filing responds; (3) furnish the name, address, and telephone number of the person protesting or intervening; and (4) otherwise comply with the requirements of 18 CFR 385.2001 through 385.2005. Agencies may obtain copies of the application directly from the applicant. A copy of any protest or motion to intervene must be served upon each representative of the applicant specified in the particular application.
o.
On April 5, 2023, Appalachian Power Company submitted to the Federal Energy Regulatory Commission (Commission) a copy of its application for a Clean Water Act section 401(a)(1) water quality certification filed with the Virginia Department of Environmental Quality (Virginia DEQ), in conjunction with the above captioned project. Pursuant to 40 CFR 121.6 and section 5.23(b) of the Commission's regulations,
If Virginia DEQ fails or refuses to act on the water quality certification request on or before the above date, then the agency certifying authority is deemed waived pursuant to section 401(a)(1) of the Clean Water Act, 33 U.S.C. 1341(a)(1).
On March 30, 2023, the Commission issued an order in Docket No. EL23-25-000, pursuant to section 206 of the Federal Power Act (FPA), 16 U.S.C. 824e, instituting an investigation into whether Bellflower Solar 1, LLC's proposed Rate Schedule
The refund effective date in Docket No. EL23-25-000, established pursuant to section 206(b) of the FPA, will be the date of publication of this notice in the
Any interested person desiring to be heard in Docket No. EL23-25-000 must file a notice of intervention or motion to intervene, as appropriate, with the Federal Energy Regulatory Commission, in accordance with Rule 214 of the Commission's Rules of Practice and Procedure, 18 CFR 385.214 (2022), within 21 days of the date of issuance of the order.
In addition to publishing the full text of this document in the
The Commission strongly encourages electronic filings of comments, protests and interventions in lieu of paper using the “eFile” link at
Take notice that the Commission received the following electric rate 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:
Take notice that the Commission has received the following Natural Gas & Oil 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.
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 following hydroelectric application has been filed with the Commission and is available for public inspection.
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
The Commission strongly encourages electronic filing. Please file motions to intervene and protests using the Commission's eFiling system at
The Commission's Rules of Practice require all intervenors filing documents with the Commission to serve a copy of that document on each person on the official service list for the project. Further, if an intervenor files comments or documents with the Commission relating to the merits of an issue that may affect the responsibilities of a particular resource agency, they must also serve a copy of the document on that resource agency.
k. This application has been accepted but is not ready for environmental analysis.
l. The Saranac Project consists of the following existing facilities: (1) a 151-foot-long, 24-foot-high dam with a 147-foot-long spillway section at crest elevation 1,408.49 feet National Geodetic Vertical Datum of 1929 (NGVD 29) with 1-foot-high flashboards; (2) a reservoir having a surface area of 1,630 acres and a gross storage capacity of 8,900 acre-feet at pool elevation 1,409.49 feet NGVD 29; (3) an integrated 36-foot-long gated intake structure at the dam's left (north) side; (4) an 11-foot-diameter, 1,433-foot-long steel penstock; (5) a surge vent; (6) a powerhouse containing two turbine generating units with a total rated capacity of 2.6 megawatts; (7) 4.16-kilovolt (kV) generator leads; (8) a 4.16/46-kV step-up transformer bank; (9) a 90-foot-long, 46-kV transmission line; (10) a tailrace; and (11) appurtenant facilities.
The Saranac Project operates in a modified run-of-river mode through the use of a float control for the purpose of generating electric power, with a minimum flow of 30 cubic feet per second (cfs) in the bypassed reach from April 1 through June 30, and a minimum flow of 10 cfs during the remainder of the year. The project has an average annual generation of 745 megawatt-hours.
Union Falls does not propose changes to project facilities. Union Falls proposes to: (1) limit the maximum daily drawdown of the project impoundment to no more than 3 inches in a 24-hour period, and limit the total drawdown to 6 inches below the top of the project's flashboards, or below the spillway crest when flashboards are not present; (2) provide a minimum base flow of 165 cfs or inflow, whichever is less, at the dam year-round; (3) increase the minimum flow in the bypassed reach to 30 cfs from December 1 through March 1 and 50 cfs from March 2 through November 30; and (4) install signage for the canoe portage trail and tailrace parking area. In addition, Union Falls proposes to develop the following plans: bald eagle management plan, invasive species management plan, impoundment drawdown plan, and operation compliance monitoring plan.
m. In addition to publishing the full text of this document in the
You may also register online at
n. Anyone may submit a protest or a motion to intervene in accordance with the requirements of Rules of Practice and Procedure, 18 CFR 385.210, 385.211, and 385.214. In determining the appropriate action to take, the Commission will consider all protests filed, but only those who file a motion to intervene in accordance with the Commission's Rules may become a party to the proceeding. Any protests or motions to intervene must be received on or before the specified deadline date for the particular application.
All filings must (1) bear in all capital letters the title “PROTEST” or “MOTION TO INTERVENE;” (2) set forth in the heading the name of the applicant and the project number of the application to which the filing responds; (3) furnish the name, address, and telephone number of the person protesting or intervening; and (4) otherwise comply with the requirements of 18 CFR 385.2001 through 385.2005. Agencies may obtain copies of the application directly from the applicant. A copy of any protest or motion to intervene must be served upon each representative of the applicant specified in the particular application.
o.
The Federal Energy Regulatory Commission hereby gives notice that members of the Commission and/or Commission staff may attend the following meetings:
Further information regarding these meetings may be found at:
The discussions at the meetings, which are open to the public, may address matters at issue in the following Commission proceeding:
For further information, please contact Chanel Chasanov, 202-502-8569, or
On March 31, 2023, the Commission issued an order in Docket No. EL23-47-000, pursuant to section 206 of the Federal Power Act (FPA), 16 U.S.C. 824e, instituting an investigation into whether CPV Three Rivers, LLC's proposed rate schedule (Rate Schedule)
The refund effective date in Docket No. EL23-47-000, established pursuant to section 206(b) of the FPA, will be the date of publication of this notice in the
Any interested person desiring to be heard in Docket No. EL23-47-000 must file a notice of intervention or motion to intervene, as appropriate, with the Federal Energy Regulatory Commission, in accordance with Rule 214 of the Commission's Rules of Practice and Procedure, 18 CFR 85.214 (2021), within 21 days of the date of issuance of the order.
In addition to publishing the full text of this document in the
The Commission strongly encourages electronic filings of comments, protests and interventions in lieu of paper using the “eFile” link at
The staff of the Federal Energy Regulatory Commission (FERC or Commission) has prepared a draft environmental impact statement (EIS) for the Virginia Reliability Project (VRP), proposed by Columbia Gas Transmission, LLC (Columbia) and the Commonwealth Energy Connector Project (CEC Project) proposed by Transcontinental Gas Pipe Line Company, LLC (Transco) in the above-referenced dockets.
Columbia requests authorization to construct and operate its VRP in Greensville, Prince George, Sussex, Surry, Southampton, and Isle of Wight Counties, Virginia, and in the cities of Suffolk and Chesapeake, Virginia. The VRP is designed to provide an additional 100,000 Dekatherms per day (Dth/d) of firm transportation service for Virginia Natural Gas, Inc. (VNG), from Emporia I/C to VNG's existing delivery point in Chesapeake County, Virginia.
Transco requests authorization to construct, operate, and maintain its CEC Project in Mecklenburg, Brunswick, and Greensville Counties, Virginia. The CEC Project is designed to provide an additional 105,000 Dth/d of firm transportation service for VNG from Transco's existing Station 165 Zone 5 Pooling Point in Pittsylvania County, Virginia, to the existing interconnection between Transco and Columbia in Greensville County, Virginia (Emporia I/C), where VNG has contracted with Columbia for further firm transportation service.
The draft EIS assesses the potential environmental effects of the construction and operation of the VRP and the CEC Project (the Projects) in accordance with the requirements of the
The U.S. Army Corps of Engineers (USACE), Norfolk District, and the U.S. Fish and Wildlife Service (USFWS) participated as cooperating agencies in the preparation of the EIS. Cooperating agencies have jurisdiction by law or special expertise with respect to resources potentially affected by the proposal and participate in the NEPA analysis. Although the cooperating agencies provided input to the conclusions and recommendations presented in the draft EIS, the agencies will present their own conclusions and recommendations in any applicable Records of Decision or other documentation for the Projects.
The draft EIS addresses the potential environmental effects of the construction and operation of the following VRP facilities, all in Virginia:
• replacement of about 49.2 miles of the existing 12-inch-diameter VM-107 and VM-108 pipelines with 24-inch-diameter pipeline mostly within Columbia's existing right-of-way, in Sussex, Surry, Southampton, and Isle of Wight Counties, as well as in the cities of Suffolk and Chesapeake;
• installation of one new 5,500-horsepower (HP) dual-drive compressor unit at the existing Emporia Compressor Station in Greensville County;
• modification of the existing compressor units and an increase in power by 2,700 HP at the existing Petersburg Compressor Station in Prince George County;
• modification of the Emporia Point of Receipt in Greensville County, Regulator Station 7423 in Prince George County, and MS-831010 Point of Delivery in Chesapeake; and
• replacement of eight mainline valves (MLV), installation of one new MLV and five new launchers/receivers, and replacement or installation of other minor appurtenant facilities.
The draft EIS addresses the potential environmental effects of the construction and operation of the following CEC Project facilities, all in Virginia:
• construction of a 6.35-mile-long, 24-inch-diameter pipeline loop
• addition of a 33,000-HP electric motor-driven compressor unit at the existing Compressor Station 168 in Mecklenburg County; and
• modification of the existing Emporia Metering and Regulation Station in Greensville County.
The Commission mailed a copy of the
The draft EIS is not a decision document. It presents Commission staff's independent analysis of the environmental issues for the Commission to consider when addressing the merits of all issues in this proceeding. Any person wishing to comment on the draft EIS may do so. Your comments should focus on draft EIS's disclosure and discussion of potential environmental effects, measures to avoid or lessen environmental impacts, and the completeness of the submitted alternatives, information and analyses. To ensure consideration of your comments on the proposal in the final EIS, it is important that the Commission receive your comments on or before 5:00 p.m. Eastern Daylight Time on June 5, 2023.
For your convenience, there are four methods you can use to submit your comments to the Commission. The Commission will provide equal consideration to all comments received, whether filed in written form or provided verbally. The Commission encourages electronic filing of comments and has staff available to assist you at (866) 208-3676 or
(1) You can file your comments electronically using the eComment feature on the Commission's website (
(2) You can file your comments electronically by using the eFiling feature on the Commission's website (
(3) You can file a paper copy of your comments by mailing them to the Commission. Be sure to reference the project docket number (CP22-503-000 or CP22-502-000) on your letter. Submissions sent via the U.S. Postal Service must be addressed to: Kimberly D. Bose, Secretary, Federal Energy Regulatory Commission, 888 First Street NE, Room 1A, Washington, DC 20426. Submissions sent via any other carrier must be addressed to: Kimberly D. Bose, Secretary, Federal Energy Regulatory Commission, 12225 Wilkins Avenue, Rockville, Maryland 20852.
(4) In lieu of sending written or electronic comments, the Commission invites you to attend one of the in-person or virtual public comment sessions its staff will conduct to receive comments on the draft EIS. The primary goal of these comment sessions is to have you identify the specific environmental issues and concerns with the draft EIS. Individual oral comments will be taken on a one-on-one basis with a court reporter. This format is designed to receive the maximum amount of oral
The in-person comment sessions are scheduled as follows:
Each in-person comment session is scheduled from 5:00 p.m. to 8:00 p.m. Eastern Daylight Time. You may arrive at any time after 5:00 p.m. There will not be a formal presentation by Commission staff when the session opens. If you wish to speak, the Commission staff will hand out numbers in the order of your arrival. Comments will be taken until 8:00 p.m. However, if no additional numbers have been handed out and all individuals who wish to provide comments have had an opportunity to do so, staff may conclude the session at 7:30 p.m. Please see appendix 1 for additional information on the session format and conduct.
Your oral comments will be recorded by the court reporter (with FERC staff or a representative present) and become part of the public record for this proceeding. If a significant number of people are interested in providing oral comments in the one-on-one settings, a time limit of 5 minutes may be implemented for each commentor. Although there will not be a formal presentation, Commission staff will be available throughout the comment session to answer your questions about the environmental review process.
FERC staff will also conduct a virtual comment session by telephone, scheduled as follows:
Individual oral comments will be taken on a one-on-one basis with a court reporter present on the line. You may call at any time after 5:00 p.m., at which time you will be placed on mute and hold. Calls will be answered in the order they are received. Once your call is answered, you will have the opportunity to provide your comment directly to a court reporter with FERC staff or a representative present on the line. A time limit of 3 minutes will be implemented for each commentor.
Transcripts of the virtual and in-person comment sessions will be publicly available on FERC's eLibrary system (see page 3 for instructions on using eLibrary).
It is important to note that the Commission provides equal consideration to all comments received, whether filed in written form or provided orally at a comment session.
Any person seeking to become a party to the proceeding must file a motion to intervene pursuant to Rule 214 of the Commission's Rules of Practice and Procedures (18 CFR part 385.214). Motions to intervene are more fully described at
Additional information about the Projects is available from the Commission's Office of External Affairs, at (866) 208-FERC, or on the FERC website (
In addition, the Commission offers a free service called eSubscription that allows you to keep track of all formal issuances and submittals in specific dockets. This can reduce the amount of time you spend researching proceedings by automatically providing you with notification of these filings, document summaries, and direct links to the documents. Go to
Western Area Power Administration, DOE.
Notice of proposed fiscal year 2024 Boulder Canyon Project base charge and rates for electric service.
The Desert Southwest Region (DSW) of the Western Area Power Administration (WAPA) proposes an adjustment to the base charge and rates for fiscal year (FY) 2024 Boulder Canyon Project (BCP) electric service under Rate Schedule BCP-F11. The proposal would increase the base charge 3.5 percent from $66.8 million in FY 2023 to $69.1 million in FY 2024. The change is primarily the result of a decrease in prior year carryover funds from FY 2023. The proposed base charge and rates would go into effect on October 1, 2023, and remain in effect through September 30, 2024. Publication of this
A consultation and comment period begins today and will end July 17, 2023. DSW will present a detailed explanation of the proposed FY 2024 base charge and rates at a public information forum that will be held on May 18, 2023, from 10 a.m. Mountain Standard Time to no later than 12 p.m. Mountain Standard Time, or until the last comment is received. DSW will also host a public comment forum that will be held on June 20, 2023, from 10 a.m. Mountain Standard Time to no later than 12 p.m. Mountain Standard Time, or until the last comment is received. DSW will conduct both the public information forum and the public comment forum via Webex. Instructions for participating in the forums will be posted on DSW's website at least 14 days prior to the public information and comment forums at:
Written comments and requests to be informed of Federal Energy Regulatory Commission (FERC) actions concerning the proposed base charge and rates should be sent to: Jack D. Murray, Regional Manager, Desert
Tina Ramsey, Rates Manager, Desert Southwest Region, Western Area Power Administration, (602) 605-2565, or
Hoover Dam,
The rate-setting methodology for BCP calculates an annual base charge rather than a unit rate for Hoover Dam hydropower. The base charge recovers an annual revenue requirement that includes projected costs of investment repayment, interest, operations, maintenance, replacements, payments to states, and Hoover Dam visitor services. Non-power revenue projections such as water sales, Hoover Dam visitor revenue, ancillary services, and late fees help offset these projected costs. Hoover power customers are billed a percentage of the base charge in proportion to their power allocation. Unit rates are calculated for comparative purposes but are not used to determine the charges for service.
On September 12, 2022, the Deputy Secretary of Energy confirmed, approved, and placed Rate Schedule BCP-F11 into effect on an interim basis (87 FR 57189). The rates remain in effect until: (1) FERC confirms and approves them on a final basis; (2) subsequent rates are confirmed and approved; or (3) such rates are superseded. On September 13, 2022, WAPA submitted Rate Schedule BCP-F11 to FERC, which, pending final confirmation and approval by FERC, will be in effect for a five-year period ending September 30, 2027.
The preliminary calculation of the FY 2024 base charge resulted in an 11 percent increase compared to FY 2023. In response to devolving hydrology and to mitigate this increase, Reclamation and WAPA coordinated to make budget reductions for both FY 2023 and FY 2024. This effort led to Reclamation reducing its FY 2022 carryover request in FY 2023 and both WAPA and Reclamation reducing their FY 2024 budgets. As a result, the proposed FY 2024 base charge for BCP electric service is projected to increase from $66.8 million in FY 2023 to $69.1 million in FY 2024, a 3.5 percent increase.
Reclamation's FY 2024 budget is decreasing $962,000 from $84.7 million to $83.7 million, a 1.1 percent decrease from FY 2023. Reflected in this budget, operations and maintenance (O&M) costs are decreasing $511,000 primarily due to the elimination of three positions and the associated travel and training costs. Several large projects are being delayed, decreasing replacements costs by $1.3 million. Post-retirement benefits costs are increasing $104,000 based on a higher 5-year average of recent actual expenses. Visitor services costs are increasing by $728,000 primarily due to costs for the National Park Services security agreement being realigned from security forces in O&M to visitor services.
WAPA's FY 2024 budget is decreasing $100,000 to $8.6 million, a 1.1 percent decrease from FY 2023. WAPA's O&M costs are increasing $680,000 from FY 2023 due to higher labor projections for salaries, overtime, overhead, and benefits and an updated charging methodology from overhead to direct charging for power billing. WAPA's replacement costs are decreasing $820,000 from FY 2023 due to delaying previously planned circuit breaker and relay replacements until at least FY 2026. WAPA's post-retirement benefit costs are increasing $39,000 from FY 2023 due to a higher 5-year average of recent actual expenses.
Costs for Reclamation and WAPA are offset by a slight increase of $18,000 in non-power revenue projections, due to a higher estimate for ancillary services revenues. Prior year carryover is projected to be $2.2 million, a $3.4 million decrease from FY 2023.
The composite and energy rates are both increasing 6.7 percent from FY 2023, and the capacity rate is increasing 11.5 percent from FY 2023. These unit rate calculations use forecasted energy and capacity values, which have been decreasing due to the ongoing drought in the Lower Colorado River Basin. Forecasted energy and capacity values may be updated when determining the final base charge and rates if hydrological conditions change. With the uncertainty of hydrological conditions, Reclamation and WAPA will continue to work collaboratively to lessen the impact of the drought in future years.
WAPA's proposed base charge and rates for FY 2024, which would be effective October 1, 2023, are preliminary and subject to change based on modifications to forecasts before publication of the final base charge and rates.
WAPA's proposal to calculate the base charge and rates for FY 2024
WAPA is establishing rates for BCP electric service in accordance with section 302 of the DOE Organization Act (42 U.S.C. 7152). This provision transferred to, and vested in, the Secretary of Energy certain functions of the Secretary of the Interior, along with the power marketing functions of Reclamation. Those functions include actions that specifically apply to the BCP.
Pursuant to the BCP Electric Service Contracts, the calculated base charge and rates for FY 2024 shall become effective, provisionally, upon approval by the Deputy Secretary of Energy subject to final approval by FERC. Under the DOE Organization Act, the Secretary of Energy holds plenary authority over DOE affairs with respect to the Power Marketing Administrations, and the Secretary of Energy may therefore exercise the Deputy Secretary's contractual authority in this context. By Delegation Order No. S1-DEL-RATES-2016, effective November 19, 2016, the Secretary of Energy delegated: (1) the authority to develop power and transmission rates to the WAPA Administrator; (2) the authority to confirm, approve, and place such rates into effect on an interim basis to the Deputy Secretary of Energy; and (3) the authority to confirm, approve, and place into effect on a final basis, or to remand or disapprove such rates, to FERC. Based upon the governing terms of the BCP Electric Service Contracts and Delegation Order No. S1-DEL-RATES-2016, the Deputy Secretary will provisionally approve the FY 2024 base charge and rates for BCP electric service, subject to final approval by FERC. This rate action is issued under the Delegation Order and DOE's procedures for public participation in rate adjustments set forth at 10 CFR parts 903 and 904.
All brochures, studies, comments, letters, memorandums, or other documents that DSW initiates or uses to develop the proposed formula rates for electric service and the base charge and rates are available for inspection and copying at the Desert Southwest Customer Service Regional Office, located at 615 South 43rd Avenue, Phoenix, Arizona. Many of these documents and supporting information are also available on WAPA's website at:
WAPA is in the process of determining whether an environmental assessment or an environmental impact statement should be prepared or if this action can be categorically excluded from those requirements.
WAPA has an exemption from centralized regulatory review under Executive Order 12866; accordingly, no clearance of this notice by the Office of Management and Budget is required.
This document of the Department of Energy was signed on March 31, 2023, by Tracey A. LeBeau, Administrator, Western Area Power Administration, pursuant to delegated authority from the Secretary of Energy. That document with the original signature and date is maintained by DOE. For administrative purposes only, and in compliance with requirements of the Office of the Federal Register, the undersigned DOE Federal Register Liaison Officer has been authorized to sign and submit the document in electronic format for publication, as an official document of the Department of Energy. This administrative process in no way alters the legal effect of this document upon publication in the
Environmental Protection Agency (EPA).
Notice.
The Environmental Protection Agency (EPA) is planning to submit an information collection request (ICR), “EPA's ENERGY STAR Program in the Residential Sector” (EPA ICR No. 2193.05, OMB Control No. 2060-0586) to the Office of Management and Budget (OMB) for review and approval in accordance with the Paperwork Reduction Act (44 U.S.C. 3501
Comments must be submitted on or before June 20, 2023.
Submit your comments, referencing Docket ID No. EPA-HQ-OAR-2004-0500, online using
EPA's policy is that all comments received will be included in the public docket without change including any personal information provided, unless the comment includes profanity, threats, information claimed to be Confidential Business Information (CBI) or other information whose disclosure is restricted by statute.
Zachary Shadid, Energy Star Residential Branch, Mail code 6202A, Environmental Protection Agency, 1200 Pennsylvania Ave. NW, Washington, DC 20460; telephone number: (202) 343-9058; fax number: (202) 343-2204; email address:
Supporting documents which explain in detail the information that the EPA will
Pursuant to section 3506(c)(2)(A) of the PRA, EPA is soliciting comments and information to enable it to: (i) 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; (ii) 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; (iii) enhance the quality, utility, and clarity of the information to be collected; and (iv) 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,
Since participation in the ENERGY STAR program is voluntary, organizations are not required to submit information to EPA. Information received is not of a confidential nature. EPA has developed this ICR to obtain authorization to collect information for the following activities:
Federal Communications Commission.
Notice of a new system of records; Correction.
The Federal Communications Commission (FCC) published a System of Records Notice in the
Brendan McTaggart, (202) 418-1738, or
In the
The Federal Communications Commission (FCC or Commission or Agency) proposes to add a new system of records, FCC/WCB-6, USAC Customer Relationship Management (CRM), subject to the Privacy Act of 1974, as amended.
In the
FCC/WCB-6, USAC Customer Relationship Management.
Federal Communications Commission.
Notice and request for comments.
As part of its continuing effort to reduce paperwork burdens, as required by the Paperwork Reduction Act (PRA) of 1995, the Federal Communications Commission (FCC or the Commission) invites the general public and other Federal Agencies to take this opportunity to comment on the following information collection. Pursuant to the Small Business Paperwork Relief Act of 2002, the FCC seeks specific comment on how it can further reduce the information collection burden for small business concerns with fewer than 25 employees.
Written comments and recommendations for the proposed information collection should be submitted on or before May 18, 2023.
Comments should be sent to
For additional information or copies of the information collection, contact Cathy Williams at (202) 418-2918. To view a copy of this information collection request (ICR) submitted to OMB: (1) go to the web page
The Commission may not conduct or sponsor a collection of information unless it displays a currently valid Office of Management and Budget (OMB) control number. No person shall be subject to any penalty for failing to comply with a collection of information subject to the PRA that does not display a valid OMB control number.
As part of its continuing effort to reduce paperwork burdens, as required by the Paperwork Reduction Act (PRA) of 1995 (44 U.S.C. 3501-3520), the FCC invited the general public and other Federal Agencies to take this opportunity to comment on the following information collection. Comments are requested concerning: (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 burden estimates; (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 the respondents, including the use of automated collection techniques or other forms of information technology. Pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 107-198, see 44 U.S.C. 3506(c)(4), the FCC seeks specific comment on how it might “further reduce the information collection burden for small business concerns with fewer than 25 employees.”
Federal Communications Commission.
Notice and request for comments.
As part of its continuing effort to reduce paperwork burdens, and as required by the Paperwork Reduction Act of 1995 (PRA), the Federal Communications Commission (FCC or Commission) invites the general public and other Federal agencies to take this opportunity to comment on the following information collections. Comments are requested concerning: 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; the accuracy of the Commission's burden estimate; ways to enhance the quality, utility, and clarity of the information collected; ways to minimize the burden of the collection of information on the respondents, including the use of automated collection techniques or other forms of information technology; and ways to further reduce the information collection burden on small business concerns with fewer than 25 employees. The FCC may not conduct or sponsor a collection of information unless it displays a currently valid Office of Management and Budget (OMB) control number. No person shall be subject to any penalty for failing to comply with a collection of information subject to the PRA that does not display a valid OMB control number.
Written PRA comments should be submitted on or before June 20, 2023. If you anticipate that you will be submitting comments but find it difficult to do so within the period of time allowed by this notice, you should advise the contact listed below as soon as possible.
Direct all PRA comments to Cathy Williams, FCC, via email to
For additional information about the information collection, contact Cathy Williams at (202) 418-2918.
Upon Adoption of the 2020 Public Notice Second Report and Order, this submission was sent to OMB for approval of the modified third-party disclosure requirements for this Information Collection. The changes pertaining to this Information Collection and to 47 CFR 73.3580 adopted in the 2020 Public Notice Second Report and Order, did not necessitate changes to Schedules 314 or 315, nor did they affect the substance, burden hours, or costs of completing the forms. The rule changes did, however, reduce burdens and costs associated with filing the application.
First, to improve the NCE comparative process, the NCE LPFM Report and Order: (1) Eliminated the governing document requirements for established local applicants and applicants claiming diversity points; (2) established a uniform divestiture pledge policy; (3) expanded the tie-breaker criteria and revises the procedures for allocating time in mandatory time-sharing situations; and (4) clarified and modified the “holding period” rule.
Second, the NCE LPFM Report and Order adopted the following changes to the LPFM comparative process: (1) Prohibited amendments that attempt to cure past unauthorized station violations; (2) authorized time-sharing discussions prior to tentative selectee designations; and (3) established procedures for remaining tentative selectees following dismissal of point aggregation time-share agreements.
Third, the NCE LPFM Report and Order adopted the following general changes: (1) Defined which applicant board changes are major changes; (2) clarified the reasonable site assurance requirements; (3) streamlined construction deadline tolling procedures and notification requirements; (4) lengthened the LPFM construction period; and (5) eliminated restrictions on the assignment and transfer of LPFM authorizations.
Specifically, pertaining to this Information Collection and NCE and LPFM stations, the Commission removed the restrictive LPFM station three-year “holding period” certification from CDBS Forms 314 and 315, and revised the relevant rules, 47 CFR 73.865 and 73.7005, the forms, and corresponding instructions, as follows:
(1) Changed all references to “holding period” to “maintenance of comparative qualifications,” and requiring NCE stations awarded by the point system to certify satisfying the four-year “maintenance of comparative qualifications” period;
(2) required LPFM applicants to certify that it has been at least 18 months since the station's initial construction permit was granted in accordance with 47 CFR 73.865(c);
(3) required LPFM applicants to certify that the assignment/transfer of the LPFM authorization satisfies the consideration restrictions of 47 CFR 73.865(a)(1);
(4) required LPFM authorizations awarded by the LPFM comparative point system, to indicate whether the LPFM station has operated on-air for at least four years since grant;
(5) required NCE applicants to certify that the proposed acquisition comports with 47 CFR 73.7005(c) diversity requirements, based on any “diversity of ownership” points awarded in an NCE points system analysis.
Moreover, the NCE LPFM Report and Order will increase the number of applicants eligible to file Schedules 314 and 315 by eliminating both the absolute prohibition on the assignment/transfer of LPFM construction permits and the three-year holding period restriction on assigning LPFM licenses. The elimination of these restrictions will benefit the LPFM service by increasing the likelihood that LPFM permits will be constructed, provide new service to communities, and help make the LPFM stations more viable.
Upon adoption, the Commission, submitted to OMB for the approval of information collection requirements contained in the Amendment of Section 73.3580 of the Commission's Rules Regarding Public Notice of the Filing of Applications; Modernization of Media Regulation Initiative; Revision of the Public Notice Requirements of Section 73.3580, Second Report and Order, MB Docket Nos. 17-254, 17-105, & 05-6, FCC 20-65 (adopted May 12, 2020, rel. May 13, 2020) (2020 Public Notice Second Report and Order). The Commission adopted new, streamlined procedures for stations to provide public notice of the filing of certain applications. Stations, including commercial stations filing assignment and transfer applications, that were previously required to post public notice in a local newspaper, must now post notice online either on the station website or a website affiliated with the station, its licensee, or its parent entity, or else must post notice on a publicly accessible, locally targeted website, for 30 continuous days following acceptance of the application for filing. Stations, including those filing assignment and transfer applications, that are required to make on-air announcements of the filing of certain applications, must continue to do so, but the announcements are shorter and direct viewers and listeners to the application as filed and displayed in either the station's Online Public Inspection File or another Commission database. A total of six on-air announcements are required, at least one per week and no more than one per day or two per week, to be broadcast between 7:00 a.m. and 11:00 p.m. local time, Monday through Friday, beginning after the application is accepted for filing.
The changes pertaining to this Information Collection and to 47 CFR 73.3580 adopted in the 2020 Public Notice Second Report and Order, did not necessitate changes to Schedules 314 or 315, nor did they affect the substance, burden hours, or costs of completing the forms. The rule changes did, however, reduce burdens and costs associated with filing the application.
Federal Communications Commission.
Notice of a new matching program.
In accordance with the Privacy Act of 1974, as amended (“Privacy Act”), this document announces a new computer matching program the Federal Communications Commission (“FCC” or “Commission” or “Agency”) and the Universal Service Administrative Company (USAC) will conduct with the Department of Education. The purpose of this matching program is to verify the eligibility of applicants to and subscribers of the Affordable Connectivity Program (ACP), which is administered by USAC under the direction of the FCC. More information about this program is provided in the
Written comments are due on or before May 18, 2023. This computer matching program will commence on
Send comments to Elliot S. Tarloff, FCC, 45 L Street NE, Washington, DC 20554, or to
Elliot S. Tarloff at 202-418-0886 or
In the Consolidated Appropriations Act, 2021, Public Law 116-260, 134 Stat. 1182, 2129-36 (2020), Congress created the Emergency Broadband Benefit Program, and directed use of the National Verifier to determine eligibility based on various criteria, including the qualifications for Lifeline (Medicaid, SNAP, etc.). EBBP provided $3.2 billion in monthly consumer discounts for broadband service and one-time provider reimbursement for a connected device (laptop, desktop computer or tablet). In the Infrastructure Investment and Jobs Act, Public Law 117-58, 135 Stat. 429, 1238-44 (2021) (codified at 47 U.S.C. 1751-52), Congress modified and extended EBBP, provided an additional $14.2 billion, and renamed it the Affordable Connectivity Program (ACP). A household may qualify for the ACP benefit under various criteria, including an individual qualifying for the FCC's Lifeline program.
In a Report and Order adopted on March 31, 2016, (81 FR 33026, May 24, 2016) (
The Consolidated Appropriations Act of 2021 directs the FCC to leverage the National Verifier to verify applicants' eligibility for ACP. The purpose of this matching program is to verify the eligibility of ACP applicants and subscribers by determining whether they receive Federal Pell Grant benefits administered by the Department of Education.
Department of Education (source agency), Federal Communications Commission (recipient agency) and Universal Service Administrative Company
The authority for the FCC's ACP is Infrastructure Investment and Jobs Act, Public Law 117-58, 135 Stat. 429, 1238-44 (2021) (codified at 47 U.S.C. 1751-52); 47 CFR part 54.
The Department of Education's legal authority for this matching program and the associated disclosures is provided by Section 904 of division N of the Consolidated Appropriations Act, 2021 (Pub. L. 116-260) as amended by Division F, Title V of the Infrastructure and Investment Jobs Act, Public Law 117-58, and the Privacy Act, 5 U.S.C. 552a. Prior to sending any records under this matching program to the Department of Education, USAC will obtain the prior written consent of all applicants for and subscribers to the ACP benefits whose eligibility is based on being a recipient of a Federal Pell Grant so as to permit the Department of Education to disclose their receipt of a Federal Pell Grant disbursement in an active award year to USAC and the FCC under the Family Educational Rights and Privacy Act (FERPA), 20 U.S.C. 1232g(b) and 34 CFR 99.30, and the Privacy Act.
The purpose of this modified matching agreement is to verify the eligibility of applicants and subscribers to Lifeline, as well as to ACP and other Federal programs that use qualification for Lifeline as an eligibility criterion. This new agreement will permit eligibility verification for ACP by checking an applicant's/subscriber's participation in the Federal Pell Grant Program. Under FCC rules, consumers receiving these benefits qualify for ACP benefits.
The categories of individuals whose information is involved in the matching program include, but are not limited to, those individuals who have applied for ACP benefits; are currently receiving ACP benefits; or who have received ACP benefits.
The categories of records involved in the matching program include the last four digits of the applicant's Social Security Number, date of birth, and first and last name. The National Verifier will transfer these data elements to the Department of Education, which will respond either “yes” or “no” that the individual is enrolled in a qualifying assistance program: Federal Pell Grant administered by the Department of Education.
The records shared as part of this matching program reside in the ACP system of records, FCC/WCB-3, Affordable Connectivity Program, which was published in the
Federal Communications Commission.
Notice and request for comments.
As part of its continuing effort to reduce paperwork burdens, and as required by the Paperwork Reduction Act of 1995 (PRA), the Federal Communications Commission (FCC or Commission) invites the general public and other Federal agencies to take this opportunity to comment on the following information collections. Comments are requested concerning: 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; the accuracy of the Commission's burden estimate; ways to enhance the quality, utility, and clarity of the information collected; ways to minimize the burden of the collection of information on the respondents, including the use of automated collection techniques or other forms of information technology; and ways to further reduce the information collection burden on small business concerns with fewer than 25 employees. The FCC may not conduct or sponsor a collection of information unless it displays a currently valid Office of Management and Budget (OMB) control number. No person shall be subject to any penalty for failing to comply with a collection of information subject to the PRA that does not display a valid OMB control number.
Written PRA comments should be submitted on or before June 20, 2023. If you anticipate that you will be submitting comments but find it
Direct all PRA comments to Cathy Williams, FCC, via email to
For additional information about the information collection, contact Cathy Williams at (202) 418-2918.
This collection also includes the third-party disclosure requirement of 47 CFR 73.3580 (OMB approval was received for Section 73.3580 under OMB Control Number 3060-0031). Section 73.3580, as amended in the Commission's 2020 Public Notice Second Report and Order, discussed below, requires local public notice of the filing of all applications to assign or transfer control of a broadcast station authorization, including those of an FM or TV translator or booster station or LPTV station. Notice is given by an applicant posting notice of the application filing on its station website, its licensee website, its parent entity website, or on a publicly accessible, locally targeted website, for 30 consecutive days beginning within five business days of acceptance of the application for filing. The online notice must link to a copy of the application *36405 as filed in the Commission's LMS licensing database. Applicants for assignment or transfer of control of a low-power television (LPTV) station that locally originates programming must also make a total of six on-air announcements giving notice that their applications have been accepted for filing.
On May 12, 2020, the Commission adopted Amendment of Section 73.3580 of the Commission's Rules Regarding Public Notice of the Filing of Applications; Modernization of Media Regulation Initiative; Revision of the Public Notice Requirements of Section 73.3580, Second Report and Order, MB Docket Nos. 17-254, 17-105, & 05-6, FCC 20-65 (rel. May 13, 2020). The Commission adopted new, streamlined procedures for stations to provide public notice of the filing of certain applications. Applicants, including applicants for assignment or transfer of control of authorizations for FM or TV translators or LPTV stations, that were previously required to post public notice in a local newspaper, must now post notice online, either on the station website or a website affiliated with the station, its licensee, or its parent entity, or else must post notice on a publicly accessible, locally targeted website, for 30 continuous days following acceptance of the application for filing. Stations that are required to make on-air announcements of the filing of certain applications, including an applicant for assignment or transfer of control of an LPTV station that locally originates programming, must continue to do so, but the announcements are shorter and direct viewers and listeners to the application as filed and displayed in either the station's Online Public Inspection File or another Commission database. A total of six on-air announcements are required, at least one per week and no more than one per day or two per week, to be broadcast between 7:00 a.m. and 11:00 p.m. local time, Monday through Friday, beginning after the application is accepted for filing.
Upon adoption of the 2020 Public Notice Second Report and Order, this submission was sent to OMB for approval of the modified third-party disclosure requirements for this Information Collection. The changes pertaining to this Information Collection and to 47 CFR 73.3580 adopted in the 2020 Public Notice Second Report and Order did not necessitate changes to the Schedule 345, nor did they affect the substance, burden hours, or costs of completing the forms. The rule changes did, however, reduce burdens and costs associated with filing the application.
April 25, 2023 at 10 a.m.
Telephonic. Dial-in (listen only) information: Number: 1-202-599-1426, Code: 298 441 996#; or via web:
Kimberly Weaver, Director, Office of External Affairs, (202) 942-1640.
Centers for Disease Control and Prevention (CDC), Department of Health and Human Services (HHS).
Notice and request for comment.
In accordance with regulatory provisions, the Centers for Disease Control and Prevention (CDC) announces the following meeting of the Advisory Committee on Immunization Practices (ACIP). This meeting is open to the public. Time will be available for public comment.
The meeting will be held on April 19, 2023, 11 a.m. to 3 p.m., EDT (date and times subject to change; see the ACIP website for updates:
Written comments must be received on or before April 19, 2023.
You may submit comments, identified by Docket No. CDC-2023-0028, by either of the methods listed below. CDC does not accept comments by email.
•
•
The meeting will be webcast live via the World Wide Web. The webcast link can be found on the ACIP website at
Stephanie Thomas, Committee Management Specialist, Advisory Committee on Immunization Practices, National Center for Immunization and Respiratory Diseases, Centers for Disease Control and Prevention, 1600 Clifton Road NE, Mailstop H24-8, Atlanta, Georgia 30329-4027. Telephone: (404) 639-8836; Email:
Fewer than 15 calendar days' notice is being given for this meeting in accordance with 41 CFR 102-3.150(b). Following a discussion between CDC and the Food and Drug Administration regarding anticipated regulatory changes to the COVID-19 vaccination program, a decision was made late Monday, April 10, 2023, that it is essential for ACIP to have a public committee meeting to discuss and get input from the Committee members. This meeting is critical in order for the rationale for these changes to be conveyed to the public in a timely and efficient manner. Further, given the continuing COVID-19 pandemic, it is essential that all decision-making regarding vaccines be done as urgently as possible. A notice of the meeting has also been posted on the ACIP website at
Interested persons or organizations are invited to participate by submitting written views, recommendations, and data. Please note that comments received, including attachments and other supporting materials, are part of the public record and are subject to public disclosure. Comments will be posted on
If the number of persons requesting to speak is greater than can be reasonably accommodated during the scheduled time, CDC will conduct a lottery to determine the speakers for the scheduled public comment session. CDC staff will notify individuals regarding their request to speak by email on April 18, 2023. To accommodate the significant interest in participation in the oral public comment session of ACIP meetings, each speaker will be limited to three minutes, and each speaker may only speak once per meeting.
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), Department of Health and Human Services (HHS).
General notice.
Section C-C, Order of Succession, is hereby amended as follows:
Delete in its entirety Section C-C, Order of Succession, and insert the following:
During the absence or disability of the Director, CDC, or in the event of a vacancy in that office, the first official listed below who is available shall act as Director, except that during a planned period of absence, the Director may specify a different order of succession:
Centers for Medicare & Medicaid Services, Health and Human Services (HHS).
Notice.
The Centers for Medicare & Medicaid Services (CMS) is announcing an opportunity for the public to comment on CMS' intention to collect information from the public. Under the Paperwork Reduction Act of 1995 (PRA), federal agencies are required to publish notice in the
Comments on the collection(s) of information must be received by the OMB desk officer by May 18, 2023.
Written comments and recommendations for the proposed information collection should be sent within 30 days of publication of this notice to
To obtain copies of a supporting statement and any related forms for the proposed collection(s) summarized in this notice, please access the CMS PRA website by copying and pasting the following web address into your web browser:
William Parham at (410) 786-4669.
Under the Paperwork Reduction Act of 1995 (PRA) (44 U.S.C. 3501-3520), federal agencies must obtain approval from the Office of Management and Budget (OMB) for each collection of information they conduct or sponsor. The term “collection of information” is defined in 44 U.S.C. 3502(3) and 5 CFR 1320.3(c) and includes agency requests or requirements that members of the public submit reports, keep records, or provide information to a third party. Section 3506(c)(2)(A) of the PRA (44 U.S.C. 3506(c)(2)(A)) requires federal agencies to publish a 30-day notice in the
1.
We use the MDS 3.0 PPS Item Set to collect the data used to reimburse skilled nursing facilities for SNF-level care furnished to Medicare beneficiaries and to collect information for quality measures and standardized patient assessment data under the SNF QRP. There have been some revisions to the assessment tool since the approval of MDS 3.0 vl.17.2.
Centers for Medicare & Medicaid Services, Health and Human Services (HHS).
Notice.
The Centers for Medicare & Medicaid Services (CMS) is announcing an opportunity for the public to comment on CMS' intention to collect information from the public. Under the Paperwork Reduction Act of 1995 (the PRA), federal agencies are required to publish notice in the
Comments must be received by June 20, 2023.
When commenting, please reference the document identifier or OMB control number. To be assured consideration, comments and recommendations must be submitted in any one of the following ways:
1.
2.
To obtain copies of a supporting statement and any related forms for the proposed collection(s) summarized in this notice, please access the CMS PRA website by copying and pasting the following web address into your web browser:
William N. Parham at (410) 786-4669.
This notice sets out a summary of the use and burden associated with the following information collections. More detailed information can be found in each collection's supporting statement and associated materials (see
Under the PRA (44 U.S.C. 3501-3520), federal agencies must obtain approval from the Office of Management and Budget (OMB) for each collection of information they conduct or sponsor. The term “collection of information” is defined in 44 U.S.C. 3502(3) and 5 CFR 1320.3(c) and includes agency requests or requirements that members of the public submit reports, keep records, or provide information to a third party. Section 3506(c)(2)(A) of the PRA requires federal agencies to publish a 60-day notice in the
1.
The statute provides that, after receiving CMS' written initial offer, the Primary Manufacturer may, in accordance with section 1194(b)(2)(C) of the Act, submit an optional written counteroffer (if CMS' written initial offer is not accepted by the Primary Manufacturer) that must be submitted no later than 30 days after the date of receipt of the written initial offer. If the Primary Manufacturer chooses to develop and submit a written counteroffer to CMS' written initial offer during the drug price negotiation process for initial price applicability year 2026, the Primary Manufacturer must submit the Counteroffer Form.
Pursuant to section 10(d) of the Federal Advisory Committee Act, as amended, notice is hereby given of the following meeting.
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., as amended. The grant applications and the discussions could disclose confidential trade secrets or commercial property such as patentable material, and personal information concerning individuals associated with the grant applications, the disclosure of which would constitute a clearly unwarranted invasion of personal privacy.
Pursuant to section 10(d) of the Federal Advisory Committee Act, as amended, notice is hereby given of the following meeting.
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., as amended. The grant applications and the discussions could disclose confidential trade secrets or commercial property such as patentable material, and personal information concerning individuals associated with the grant applications, the disclosure of which would constitute a clearly unwarranted invasion of personal privacy.
Transportation Security Administration, DHS.
30-Day notice.
This notice announces that the Transportation Security Administration (TSA) has forwarded the Information Collection Request (ICR), Office of Management and Budget (OMB) control number 1652-0066, abstracted below, that we will submit to OMB for an extension in compliance with the Paperwork Reduction Act (PRA). The ICR describes the nature of the information collection and its expected burden. The collection involves information to validate compliance with the regulatory requirements, including Security Training Programs, Security Training Records, Security Coordinator Information, and Reporting Significant Security Concerns Information.
Send your comments by May 18, 2023. A comment to OMB is most effective if OMB receives it within 30 days of publication.
Written comments and recommendations for the proposed information collection should be sent within 30 days of publication of this notice to
Christina A. Walsh, TSA PRA Officer, Information Technology, TSA-11, Transportation Security Administration, 6595 Springfield Center Drive, Springfield, VA 20598-6011; telephone (571) 227-2062; email
TSA published a
In accordance with the Paperwork Reduction Act of 1995 (44 U.S.C. 3501
(1) Evaluate whether the proposed information requirement is necessary for the proper performance of the functions of the agency, including whether the information will have practical utility;
(2) Evaluate the accuracy of the agency's estimate of the burden;
(3) Enhance the quality, utility, and clarity of the information to be collected; and
(4) Minimize the burden of the collection of information on those who are to respond, including using appropriate automated, electronic, mechanical, or other technological collection techniques or other forms of information technology.
As part of the Implementing Recommendations of the 9/11 Commission Act of 2007 (9/11 Act),
In accordance with these authorities and mandates, TSA published the Security Training for Surface Transportation Employees Final Rule (Rule).
The information collection mandated by the Rule includes requiring a security training program, maintaining security training records, designating security coordinator and reporting significant security concerns information.
U.S. Citizenship and Immigration Services, Department of Homeland Security.
60-Day notice.
The Department of Homeland Security (DHS), U.S. Citizenship and Immigration Services (USCIS) invites the general public and other Federal agencies to comment upon this proposed revision of a currently approved collection of information. In accordance with the Paperwork Reduction Act (PRA) of 1995, the information collection notice is published in the
Comments are encouraged and will be accepted for 60 days until June 20, 2023.
All submissions received must include the OMB Control Number 1615-0018 in the body of the letter, the agency name and Docket ID USCIS-2005-0034. Submit comments via the Federal eRulemaking Portal website at
USCIS, Office of Policy and Strategy, Regulatory Coordination Division, Samantha Deshommes, Chief, telephone number (240) 721-3000 (This is not a toll-free number. Comments are not accepted via telephone message). Please note contact information provided here is solely for questions regarding this notice. It is not for individual case status inquiries. Applicants seeking information about the status of their individual cases can check Case Status Online, available at the USCIS website at
You may access the information collection instrument with instructions or additional information by visiting the Federal eRulemaking Portal site at:
Written comments and suggestions from the public and affected agencies should address one or more of the following four points:
(1) Evaluate whether the proposed collection of information is necessary for the proper performance of the
(2) 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;
(3) Enhance the quality, utility, and clarity of the information to be collected; and
(4) 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,
(1)
(2)
(3)
(4)
(5)
(6)
(7)
Office of the Assistant Secretary for Community Planning and Development, HUD.
Notice.
On August 20, 2020, HUD issued a notice providing for the program rules, statutory and regulatory waivers, and alternative requirements applicable to supplemental Community Development Block Grant (CDBG) funds made available to prevent, prepare for, and respond to coronavirus (CDBG-CV funds) and to annual formula CDBG grants awarded in fiscal years 2019 and 2020. This notice describes a change to one of the regulatory waivers and alternative requirements applicable to the CDBG-CV funds. The change removes the requirement that eighty percent of a grant must be expended within three years of grant agreement execution. Except as otherwise described in this notice, the August 2020 Notice, the CARES Act, and the statutory and regulatory provisions governing the CDBG program continue to apply to CDBG-CV funds.
April 18, 2023.
Savin Ven Johnson, Deputy Director, Office of Block Grant Assistance, Office of Community Planning and Development, Department of Housing and Urban Development, 451 7th Street SW, Room 7282, Washington, DC 20410, telephone number 202-708-3587. HUD welcomes and is prepared to receive calls from individuals who are deaf or hard of hearing, as well as individuals with speech or communication disabilities. To learn more about how to make an accessible telephone call, please visit
The Coronavirus Aid, Relief, and Economic Security Act (Pub. L. 116-136) (CARES Act) was signed March 27, 2020. The CARES Act made $5 billion in Community Development Block Grant (CDBG) coronavirus response (CDBG-CV) funds available to prevent, prepare for, and respond to coronavirus. CDBG-CV and CDBG grants are a flexible source of funding that can be used to pay costs that are not covered by other sources of assistance, particularly to benefit persons of low and moderate income. The CARES Act also provided the Secretary the authority to grant waivers and alternative requirements to quickly administer the funds.
On August 20, 2020, HUD published in the
Since January 21, 2020, when the Centers for Disease Control and Prevention (CDC) confirmed the first case in the United States of a coronavirus known by several names, including novel coronavirus, and SARS-CoV-2, and which causes the disease commonly referred to as COVID-19, the course of the ensuing pandemic caused unforeseen obstacles for grantees implementing their CDBG and CDBG-CV assisted activities. The Three-Year Requirement, set in August 2020, did not take into account the expenditure delays that would be caused by the pandemic, such as major supply chain issues for construction materials, prolonged shutdowns, and the other economic effects of quarantines, social distancing, and workers dropping out of the workforce to care for family members.
In hindsight, these forces delayed construction launch and completion, stalled inspections, and—despite strenuous grantee efforts—delayed at least some activities for virtually every CDBG-CV grantee. Delays were compounded for CDBG-CV grantees as State and local staff struggled to adjust to remote or hybrid work while implementing a spate of other fast-moving and often overlapping CARES, FEMA, and American Rescue Plan (enacted March 3, 2021) funding from multiple agencies while considering the best uses for each funding source and preventing duplications of benefit.
Due to COVID-19, more than a third of the 1,200 plus CDBG-CV grantees need more time to achieve the 80 percent expenditure target (based on data from the IDIS online information system from March 2023). In response to the delay experienced by grantees and given HUD's experience with slow distribution of funds, this notice removes the August 2020 Notice's paragraph III.B.7.(a) Three-Year Requirement to expend 80 percent of funds for CDBG-CV funds. This Notice maintains the paragraph III.B.7.(a) Period of Performance requirement that provides grantees of CDBG-CV funds a six-year period of performance and 100 percent expenditure requirement.
The information collection requirements in this notice have been approved by the Office of Management and Budget (OMB) under the Paperwork Reduction Act of 1995 (44 U.S.C. 3501-3520) and assigned OMB Control Number 2506-0085. In accordance with the Paperwork Reduction Act, HUD may not conduct or sponsor, and a person is not required to respond to, a collection of information unless the collection displays a currently valid OMB control number.
The Catalog of Federal Domestic Assistance numbers for the CDBG-CV grants under the CARES Act are: 14.218 (Community Development Block Grants/Entitlement Grants); 14.225 (Community Development Block Grants/Special Purpose Grants/Insular Areas); and 14.228 (Community Development Block Grants/State's Program and Non-Entitlement Grants in Hawaii) (formerly CDBG Grant/Small Cities Program).
A Finding of No Significant Impact (FONSI) with respect to the environment has been made in accordance with HUD regulations at 24 CFR part 50, which implement section 102(2)(C) of the National Environmental Policy Act of 1969 (42 U.S.C. 4332(2)(C)). The FONSI is available for inspection at HUD's Funding Opportunities web page at:
Bureau of Indian Affairs, Interior.
Notice.
The Assistant Secretary—Indian Affairs has made a final determination to acquire 0.52 acres, more or less, into trust for the Samish Indian Nation, Washington.
This final determination was made on April 11, 2023.
Carla H. Clark, Bureau of Indian Affairs, Division of Real Estate Services, 1001 Indian School Road NW, Albuquerque, NM 87104,
On the date listed in the
The east
This notice is published in the exercise of authority delegated by the Secretary of the Interior to the Assistant Secretary—Indian Affairs by 209 Departmental Manual 8.1 and is published to comply with the requirements of 25 CFR 151.12(c)(2)(ii) that notice of the decision to acquire
National Park Service, Interior.
Notice.
The National Park Service is soliciting electronic comments on the significance of properties nominated before April 8, 2023, for listing or related actions in the National Register of Historic Places.
Comments should be submitted electronically by May 3, 2023.
Comments are encouraged to be submitted electronically to
Sherry A. Frear, Chief, National Register of Historic Places/National Historic Landmarks Program, 1849 C Street NW, MS 7228, Washington, DC 20240,
The properties listed in this notice are being considered for listing or related actions in the National Register of Historic Places. Nominations for their consideration were received by the National Park Service before April 8, 2023. Pursuant to Section 60.13 of 36 CFR part 60, comments are being accepted concerning the significance of the nominated properties under the National Register criteria for evaluation.
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.
Nominations submitted by State or Tribal Historic Preservation Officers:
A request for removal has been made for the following resource:
Additional documentation has been received for the following resources:
Nomination submitted by Federal Preservation Officer:
The State Historic Preservation Officer reviewed the following nomination and responded to the Federal Preservation Officer within 45 days of receipt of the nomination and supports listing the property in the National Register of Historic Places.
U.S. International Trade Commission.
Notice.
Notice is hereby given that a complaint was filed with the U.S. International Trade Commission on February 13, 2023, under section 337 of the Tariff Act of 1930, as amended, on behalf of The NOCO Company of Glenwillow, Ohio. An amended complaint was filed March 13, 2023. The amended 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 portable battery jump starters and components thereof by reason of the infringement of certain claims of U.S. Patent No. 9,770,992 (“the '992 patent”); U.S. Patent No. 10,328,808 (“the '808 patent”); U.S. Patent No. 10,981,452 (“the '452 patent”); U.S. Patent No. 11,254,213 (“the '213 patent”); and U.S. Patent No. 11,447,023 (“the '023 patent”). The amended complaint further alleges that an industry in the United States exists as required by the applicable Federal Statute. The amended complaint also alleges violations of section 337 based upon the importation into the United States, or in the sale of certain portable battery jump starters and components thereof by reason of common law trade dress infringement and false designation of origin, and false advertising and unfair competition, the threat or effect of which is to destroy or substantially injure an industry in the United States. The complainant requests that the Commission institute an investigation and, after the investigation, issue a limited exclusion order and cease and desist orders.
The amended complaint, except for any confidential information contained therein, may be viewed on the Commission's electronic docket (EDIS) at
Pathenia M. Proctor, The Office of Unfair Import Investigations, U.S. International Trade Commission, telephone (202) 205-2560.
(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) in the importation into the United States, the sale for importation, or the sale within the United States after importation certain portable battery jump starters and components thereof identified in paragraph (2) by reason of infringement of one or more of claims 1-21 of the '992 patent; claims 1-17 of the '808 patent; claims 1-16 of the '452 patent; claims 1-16 of the '213 patent; and claims 1-54 of the '023 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 “portable battery-powered devices that are used to jump-start batteries in automobiles, trucks, and other vehicles, and related accessories and components, namely cases, battery cables, and clamps”;
(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 complainant is: The NOCO Company, 30339 Diamond Parkway #102, Glenwillow, Ohio 44139.
(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:
(c) The Office of Unfair Import Investigations, U.S. International Trade Commission, 500 E Street SW, Suite 401, Washington, DC 20436; and
(4) For the investigation so instituted, the Chief Administrative Law Judge, U.S. International Trade Commission, shall designate the presiding Administrative Law Judge.
Responses to the amended 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 complainant of the amended complaint and the notice of investigation. Extensions of time for submitting responses to the amended 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 amended complaint and in this notice may be deemed to constitute a waiver of the right to appear and contest the allegations of the amended 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 amended 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.
United States International Trade Commission.
Notice.
The Commission hereby gives notice that it will proceed with full reviews pursuant to the Tariff Act of 1930 to determine whether revocation of the countervailing duty order on circular welded pipe and tube from Turkey and revocation of the antidumping duty orders on circular welded pipe and tube from Brazil, India, Mexico, South Korea, Taiwan, Thailand, and Turkey would be likely to lead to continuation or recurrence of material injury within a reasonably foreseeable time. A schedule for the reviews will be established and announced at a later date.
April 10, 2023.
Andres Andrade (202-205-2078), Office of Investigations, U.S. International Trade Commission, 500 E Street SW, Washington, DC 20436. Hearing-impaired persons can obtain information on this matter by contacting the Commission's TDD terminal on 202-205-1810. Persons with mobility impairments who will need special assistance in gaining access to the Commission should contact the Office of the Secretary at 202-205-2000. General information concerning the Commission may also be obtained by accessing its internet server (
For further information concerning the conduct of these reviews and rules of general application, consult the Commission's Rules of Practice and Procedure, part 201, subparts A through E (19 CFR part 201), and part 207, subparts A, D, E, and F (19 CFR part 207).
On April 10, 2023, the Commission determined that it should proceed to full reviews in the subject five-year reviews pursuant to section 751(c) of the Tariff Act of 1930 (19 U.S.C. 1675(c)).
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 February 13, 2023, under section 337 of the Tariff Act of 1930, as amended, on behalf of The NOCO Company of Glenwillow, Ohio. An amended complaint was filed March 13, 2023. The amended 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 portable battery jump starters and components thereof by reason of the infringement of certain claims of U.S. Patent No. 9,770,992 (“the '992 patent”); U.S. Patent No. 10,328,808 (“the '808 patent”); U.S. Patent No. 10,981,452 (“the '452 patent”); U.S. Patent No. 11,254,213 (“the '213 patent”); and U.S. Patent No. 11,447,023 (“the '023 patent”). The amended complaint further alleges that an industry in the United States exists as required by the applicable Federal Statute. The amended complaint also alleges violations of section 337 based upon the importation into the United States, or in the sale of certain portable battery jump starters and components thereof by reason of common law trade dress infringement and false designation of origin, and false advertising and unfair competition, the threat or effect of which is to destroy or substantially injure an industry in the United States. The complainant requests that the Commission institute an investigation and, after the investigation, issue a limited exclusion order and cease and desist orders.
The amended complaint, except for any confidential information contained therein, may be viewed on the Commission's electronic docket (EDIS) at
Pathenia M. Proctor, The Office of Unfair Import Investigations, U.S. International Trade Commission, telephone (202) 205-2560.
(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)(A) in the importation into the United States or sale of certain portable battery jump starters and components thereof by reason of trade dress infringement, false designation of origin, false advertising, and unfair competition, the threat or effect of which is to destroy or substantially injure an industry in the United States;
(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 “portable battery-powered devices that are used to jump-start batteries in automobiles, trucks, and other vehicles, and related accessories and components, namely cases, battery cables, and clamps”;
(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 complainant is: The NOCO Company, 30339 Diamond Parkway #102, Glenwillow, Ohio 44139.
(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:
(c) The Office of Unfair Import Investigations, U.S. International Trade Commission, 500 E Street SW, Suite 401, Washington, DC 20436; and
(4) For the investigation so instituted, the Chief Administrative Law Judge, U.S. International Trade Commission, shall designate the presiding Administrative Law Judge.
Responses to the amended 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 complainant of the amended complaint and the notice of investigation. Extensions of time for submitting responses to the amended 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 amended complaint and in this notice may be deemed to constitute a waiver of the right to appear and contest the allegations of the amended 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 amended 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.
U.S. International Trade Commission.
Notice.
Notice is hereby given that on March 31, 2023, the presiding chief administrative law judge (“CALJ”) issued an Initial Determination on Violation of Section 337. The CALJ also issued a Recommended Determination on remedy and bond should a violation be found in the above-captioned investigation. The Commission is soliciting submissions on public interest issues raised by the recommended relief should the Commission find a violation. This notice is soliciting comments from the public only.
Richard P. Hadorn, Esq., Office of the General Counsel, U.S. International Trade Commission, 500 E Street SW, Washington, DC 20436, telephone (202) 205-3179. Copies of non-confidential documents filed in connection with this investigation may be viewed on the Commission's electronic docket (EDIS) at
Section 337 of the Tariff Act of 1930 provides that, if the Commission finds a violation, it shall exclude the articles concerned from the United States unless, after considering the effect of such exclusion upon the public health and welfare, competitive conditions in the United States economy, the production of like or directly competitive articles in the United States, and United States consumers, it finds that such articles should not be excluded from entry. (19 U.S.C. 1337(d)(1)). A similar provision applies to cease and desist orders. (19 U.S.C. 1337(f)(1)).
The Commission is soliciting submissions on public interest issues raised by the recommended relief should the Commission find a violation, specifically: a limited exclusion order directed to certain automated put walls and automated storage and retrieval systems, associated vehicles, associated control software, and component parts thereof imported, sold for importation, and/or sold after importation by respondents HC Robotics (a.k.a. Huicang Informant Technology Co., Ltd.) of Hangzhou City, Zheijang Province, China, and Invata, LLC (d/b/a Invata Intralogistics) of Conshohocken, Pennsylvania; and cease and desist orders directed to the same. Parties are to file public interest submissions pursuant to 19 CFR 210.50(a)(4).
The Commission is interested in further development of the record on the public interest in this investigation. Accordingly, members of the public are invited to file submissions of no more than five (5) pages, inclusive of attachments, concerning the public interest in light of the CALJ's Recommended Determination on Remedy and Bond issued in this investigation on March 31, 2023. Comments should address whether issuance of the recommended remedial orders in this investigation, should the Commission find a violation, would affect the public health and welfare in the United States, competitive conditions in the United States economy, the production of like or directly competitive articles in the United States, or United States consumers.
In particular, the Commission is interested in comments that:
(i) explain how the articles potentially subject to the recommended remedial orders are used in the United States;
(ii) identify any public health, safety, or welfare concerns in the United States relating to the recommended orders;
(iii) identify like or directly competitive articles that complainant, its licensees, or third parties make in the United States which could replace the subject articles if they were to be excluded;
(iv) indicate whether complainant, complainant's licensees, and/or third-party suppliers have the capacity to replace the volume of articles potentially subject to the recommended orders within a commercially reasonable time; and
(v) explain how the recommended orders would impact consumers in the United States.
Written submissions must be filed no later than by close of business on May 12, 2023.
Persons filing written submissions must file the original document electronically on or before the deadlines stated above. The Commission's paper filing requirements in 19 CFR 210.4(f) are currently waived. 85 FR 15798 (Mar. 19, 2020). Submissions should refer to the investigation number (“Inv. No. 337-TA-1293”) in a prominent place on the cover page and/or the first page. (
Any person desiring to submit a document to the Commission in confidence must request confidential treatment by marking each document with a header indicating that the document contains confidential information. This marking will be deemed to satisfy the request procedure set forth in Rules 201.6(b) and 210.5(e)(2) (19 CFR 201.6(b) & 210.5(e)(2)). Documents for which confidential treatment by the Commission is properly sought will be treated accordingly. Any non-party wishing to submit comments containing confidential information must serve those comments on the parties to the investigation pursuant to the applicable Administrative Protective Order. A redacted non-confidential version of the document must also be filed simultaneously with any confidential filing and must be served in accordance with Commission Rule 210.4(f)(7)(ii)(A) (19 CFR 210.4(f)(7)(ii)(A)). All information, including confidential business information and documents for which confidential treatment is properly sought, submitted to the Commission for purposes of this investigation may be disclosed to and used: (i) by the Commission, its employees and Offices, and contract personnel (a) for developing or maintaining the records of this or a related proceeding, or (b) in internal investigations, audits, reviews, and evaluations relating to the programs, personnel, and operations of the Commission including under 5 U.S.C. Appendix 3; or (ii) by U.S. government employees and contract personnel, solely for cybersecurity purposes. All contract personnel will sign appropriate nondisclosure agreements. All nonconfidential written submissions will be available for public inspection on EDIS.
This action is taken under the authority of 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.
United States International Trade Commission.
Notice.
The Commission hereby gives notice of the scheduling of full reviews pursuant to the Tariff Act of 1930 (“the Act”) to determine whether revocation of the antidumping duty and countervailing duty orders on softwood lumber products from Canada would be likely to lead to continuation or recurrence of material injury within a reasonably foreseeable time. The Commission has determined to exercise its authority to extend the review period by up to 90 days.
April 13, 2023.
Charles Cummings (202-708-1666), Office of Investigations, U.S. International Trade Commission, 500 E Street SW, Washington, DC 20436. Hearing-impaired persons can obtain information on this matter by contacting the Commission's TDD terminal on 202-205-1810. Persons with mobility impairments who will need special assistance in gaining access to the Commission should contact the Office of the Secretary at 202-205-2000. General information concerning the Commission may also be obtained by accessing its internet server (
For further information concerning the conduct of these reviews and rules of general application, consult the Commission's Rules of Practice and Procedure, part 201, subparts A and B (19 CFR part 201), and part 207, subparts A, D, E, and F (19 CFR part 207).
Please note the Secretary's Office will accept only electronic filings during this time. Filings must be made through the Commission's Electronic Document Information System (EDIS,
A nonparty who has testimony that may aid the Commission's deliberations may request permission to present a short statement at the hearing. All parties and nonparties desiring to appear at the hearing and make oral presentations should attend a prehearing conference, if deemed necessary, to be held at 9:30 a.m. on Thursday, October 5, 2023. Parties shall file and serve written testimony and presentation slides in connection with their presentation at the hearing by no later than 4:00 p.m. on October 11, 2023. Oral testimony and written materials to be submitted at the public hearing are governed by sections 201.6(b)(2), 201.13(f), and 207.24 of the Commission's rules. Parties must submit any request to present a portion of their hearing testimony
Additional written submissions to the Commission, including requests pursuant to section 201.12 of the Commission's rules, shall not be accepted unless good cause is shown for accepting such submissions, or unless the submission is pursuant to a specific request by a Commissioner or Commission staff.
In accordance with sections 201.16(c) and 207.3 of the Commission's rules, each document filed by a party to the reviews must be served on all other parties to the reviews (as identified by either the public or BPI service list), and a certificate of service must be timely filed. The Secretary will not accept a document for filing without a certificate of service.
The Commission has determined that these reviews are extraordinarily complicated and therefore has determined to exercise its authority to extend the review period by up to 90 days pursuant to 19 U.S.C.1675(c)(5)(B).
By order of the Commission.
National Aeronautics and Space Administration (NASA).
Notice of information collection.
The National Aeronautics and Space Administration, as part of its continuing effort to reduce paperwork and respondent burden, invites the public and other Federal agencies to take this opportunity to comment on proposed and/or continuing information collections.
Comments are due by June 20, 2023.
Written comments and recommendations for this information collection should be sent within 60 days of publication of this notice to
Requests for additional information or copies of the information collection instrument(s) and instructions should be directed to Bill Edwards-Bodmer, NASA Clearance Officer, NASA Headquarters, 300 E Street SW, JF0000, Washington, DC 20546, 757-864-3292, or
The ESODIS customer satisfaction survey is performed each year (2023 is the 20th collection) under the auspices of NASA HQ as one of their metrics reported to OMB as a part of the Reduction of Paperwork Act. In this survey, the public users of the EOSDIS system (through the 12 Distributed Active Archive Centers—DAACs) are encouraged to answer specific questions that aid NASA discern the overall user satisfaction of its Earth data system. NASA through DOI/FCG contracts the management of this survey to a private survey entity (CFI) so that the respondents are assured the survey and its results are collected in an unbiased manner. The survey has two portions, a general section of questions to understand aspects of the data system the user has engaged with, and a second section that is created by each of the 12 DAACs so that these centers can address specific types of questions for that science domain community.
The collection of data from our respondents to wholly performed using an on-line, internet-based system that is developed and hosted by CFI.
Comments are invited on: (1) Whether the proposed collection of information is necessary for the proper performance of the functions of NASA, including whether the information collected has practical utility; (2) the accuracy of NASA's estimate of the burden (including hours and cost) of the proposed collection of information; (3) ways to enhance the quality, utility, and clarity of the information to be collected; and (4) ways to minimize the burden of the collection of information on respondents, including automated collection techniques or the use of other forms of information technology.
Comments submitted in response to this notice will be summarized and included in the request for OMB approval of this information collection. They will also become a matter of public record.
National Credit Union Administration (NCUA).
Notice and request for comments.
The National Credit Union Administration (NCUA) will submit the
Written comments should be received on or before June 20, 2023 to be assured consideration.
Interested persons are invited to submit written comments on the information collection to Mahala Vixamar, National Credit Union Administration, 1775 Duke Street, Alexandria, Virginia 22314, Suite 5067; Fax No. 703-519-8579; or Email at
Requests for additional information should be directed to the address above.
By the National Credit Union Administration Board.
10:00 a.m., Thursday, April 20, 2023.
Board Room, 7th Floor, Room 7B, 1775 Duke Street (All visitors must use Diagonal Road Entrance), Alexandria, VA 22314-3428.
Open.
1. Board Briefing, Cybersecurity Update.
2. Request for Information and Comment, Climate-Related Financial Risk.
3. Board Briefing, Federal Credit Union Loan Interest Rate Ceiling.
12:15 p.m.
12:30 p.m., Thursday, April 20, 2023.
Board Room, 7th Floor, Room 7B, 1775 Duke Street, Alexandria, VA 22314-3428.
Closed.
1. Administrative Enforcement Action. Closed pursuant to Exemptions (4), (5), (6), (7), (8), and (9).
Melane Conyers-Ausbrooks, Secretary of the Board, Telephone: 703-518-6304.
National Science Foundation.
Submission for OMB review; comment request.
The National Science Foundation (NSF) has submitted the following request for revision of the approved collection of research and development data in accordance with the Paperwork Reduction Act of 1995. This is the second notice for public comment; the first was published in the
Written comments and recommendations for the proposed information collection should be sent within 30 days of publication of this notice to
Suzanne H. Plimpton, Reports Clearance Officer, National Science Foundation, 2415 Eisenhower Avenue, Alexandria, VA 22314; or send email to
PREEVENTS is intended to encourage new scientific directions in the domains of natural hazards and extreme events. PREEVENTS will consider proposals for conferences that will foster development of interdisciplinary or multidisciplinary communities required to address complex questions surrounding natural hazards and extreme events. Such proposals are called PREEVENTS Track 1 proposals.
In addition to standard NSF annual and final report requirements, PIs for all PREEVENTS Track 1 awards will be required to submit to NSF a public report that summarizes the conference activities, attendance, and outcomes; describes scientific and/or technical challenges that remain to be overcome in the areas discussed during the conference; and identifies specific next steps to advance knowledge in the areas of natural hazards and extreme events that were considered during the conference. These reports will be made publicly available via the NSF website, and are intended to foster nascent interdisciplinary or multidisciplinary communities and to enable growth of new scientific directions.
National Science Foundation.
Notice.
The National Science Foundation (NSF) is announcing plans to renew this collection. In accordance with the requirements of the Paperwork Reduction Act of 1995, we are providing opportunity for public comment on this action. After obtaining and considering public comment, NSF will prepare the submission requesting Office of Management and Budget (OMB) clearance of this collection for no longer than 3 years.
Written comments on this notice must be received by June 20, 2023 to be assured consideration. Comments received after that date will be considered to the extent practicable. Send comments to address below.
Suzanne H. Plimpton, Reports Clearance Officer, National Science Foundation, 2415 Eisenhower Avenue, Suite W18200, Alexandria, Virginia 22314; telephone (703) 292-7556; or send email to
The NSF Division of Materials Research (DMR) supports a number of National User Facilities that provide specialized capabilities and instrumentation to the scientific community on a competitive proposal basis. In addition to the user program, these facilities support in-house research, development of new instrumentation or techniques, education, and knowledge transfer.
The facilities integrate research and education for students and post-docs involved in experiments, and support extensive K-12 outreach to foster an interest in Science Technology Engineering and Mathematics (STEM) and STEM careers. Facilities capitalize on diversity through participation in center activities and demonstrate leadership in the involvement of groups underrepresented in science and engineering.
National User Facilities will be required to submit annual reports on progress and plans, which will be used as a basis for performance review and determining the level of continued funding. User facilities will be required to develop a set of management and performance indicators for submission annually to NSF via the Research Performance Project Reporting (RPPR) module in
Each facility's annual report will address the following categories of activities: (1) research, (2) education and training, (3) knowledge transfer, (4) partnerships, (5) diversity, (6) management, and (7) budget issues.
For each of the categories the report will describe overall objectives and metrics for the reporting period, challenges or problems the facility has encountered in making progress towards goals, anticipated problems in the following year, and specific outputs and outcomes.
Facilities are required to file a final report through the RPPR. Final reports contain similar information and metrics as annual reports, but are retrospective and focus on the period that was not addressed in previous annual reports.
In accordance with the purposes of sections 29 and 182b of the Atomic Energy Act (42 U.S.C. 2039, 2232(b)), the Advisory Committee on Reactor Safeguards (ACRS) will hold meetings on May 3-5, 2023. The Committee will be conducting meetings that will include some Members being physically present at the NRC while other Members participate remotely. Interested members of the public are encouraged to participate remotely in any open sessions via MS Teams or via phone at 301-576-2978, passcode 856662254#. A more detailed agenda including the MSTeams link may be found at the ACRS public website at
[Note: Pursuant to 5 U.S.C 552b(c)(4), a portion of this session may be closed in order to discuss and protect information designated as proprietary.]
[Note: Pursuant to 5 U.S.C 552b(c)(4), a portion of this session may be closed to discuss and protect information designated as proprietary.]
Procedures for the conduct of and participation in ACRS meetings were published in the
An electronic copy of each presentation should be emailed to the cognizant ACRS staff at least one day before the meeting.
In accordance with subsection 10(d) of Public Law 92-463 and 5 U.S.C. 552b(c), certain portions of this meeting may be closed, as specifically noted above. Use of still, motion picture, and television cameras during the meeting may be limited to selected portions of the meeting as determined by the Chairman. Electronic recordings will be permitted only during the open portions of the meeting.
ACRS meeting agendas, meeting transcripts, and letter reports are available through the NRC Public Document Room (PDR) at
Nuclear Regulatory Commission.
Monthly notice.
Pursuant to section 189.a.(2) of the Atomic Energy Act of 1954, as amended (the Act), the U.S. Nuclear Regulatory Commission (NRC) is publishing this regular monthly notice. The Act requires the Commission to publish notice of any amendments issued, or proposed to be issued, and grants the Commission the authority to issue and make immediately effective any amendment to an operating license or combined license, as applicable, upon a determination by the Commission that such amendment involves no significant hazards consideration (NSHC), notwithstanding the pendency before the Commission of a request for a hearing from any person.
Comments must be filed by May 18, 2023. A request for a hearing or petitions for leave to intervene must be filed by June 20, 2023. This monthly notice includes all amendments issued, or proposed to be issued, from March 3, 2023, to March 30, 2023. The last monthly notice was published on March 21, 2023.
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
Rhonda Butler, Office of Nuclear Reactor Regulation, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001, telephone: 301-415-8025; email:
Please refer to Docket ID NRC-2023-0084, facility name, unit number(s), docket number(s), application date, and subject when contacting the NRC about the availability of information for this action. You may obtain publicly available information related to this action 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 into ADAMS.
For the facility-specific amendment requests shown in this notice, the Commission finds that the licensees' analyses provided, consistent with section 50.91 of title 10 of
The Commission is seeking public comments on these proposed determinations. Any comments received within 30 days after the date of publication of this notice will be considered in making any final determinations.
Normally, the Commission will not issue the amendments until the expiration of 60 days after the date of publication of this notice. The Commission may issue any of these license amendments before expiration of the 60-day period provided that its final determination is that the amendment involves NSHC. In addition, the Commission may issue any of these amendments prior to the expiration of the 30-day comment period if circumstances change during the 30-day comment period such that failure to act in a timely way would result, for example in derating or shutdown of the facility. If the Commission takes action on any of these amendments prior to the expiration of either the comment period or the notice period, it will publish in the
Within 60 days after the date of publication of this notice, any person (petitioner) whose interest may be affected by any of these actions may file a request for a hearing and petition for leave to intervene (petition) with respect to that action. Petitions shall be filed in accordance with the Commission's “Agency Rules of Practice and Procedure” in 10 CFR part 2. Interested persons should consult a current copy of 10 CFR 2.309. If a petition is filed, the Commission or a presiding officer will rule on the petition and, if appropriate, a notice of a hearing will be issued.
Petitions must be filed no later than 60 days from the date of publication of this notice in accordance with the filing instructions in the “Electronic Submissions (E-Filing)” section of this document. Petitions and motions for leave to file new or amended contentions that are filed after the deadline will not be entertained absent a determination by the presiding officer that the filing demonstrates good cause by satisfying the three factors in 10 CFR 2.309(c)(1)(i) through (iii).
If a hearing is requested, and the Commission has not made a final determination on the issue of no significant hazards consideration, the Commission will make a final determination on the issue of no significant hazards consideration, which will serve to establish when the hearing is held. If the final determination is that the amendment request involves no significant hazards consideration, the Commission may issue the amendment and make it immediately effective, notwithstanding the request for a hearing. Any hearing would take place after issuance of the amendment. If the final determination is that the amendment request involves a significant hazards consideration, then any hearing held would take place before the issuance of the amendment unless the Commission finds an imminent danger to the health or safety of the public, in which case it will issue an appropriate order or rule under 10 CFR part 2.
A State, local governmental body, Federally recognized Indian Tribe, or designated agency thereof, may submit a petition to the Commission to participate as a party under 10 CFR 2.309(h) no later than 60 days from the date of publication of this notice. Alternatively, a State, local governmental body, Federally recognized Indian Tribe, or agency thereof may participate as a non-party under 10 CFR 2.315(c).
For information about filing a petition and about participation by a person not a party under 10 CFR 2.315, see ADAMS Accession No. ML20340A053 (
All documents filed in NRC adjudicatory proceedings, including documents filed by an interested State, local governmental body, federally recognized Indian Tribe, or designated agency thereof that requests to participate under 10 CFR 2.315(c), must be filed in accordance with 10 CFR 2.302. The E-Filing process requires participants to submit and serve all adjudicatory documents over the internet, or in some cases, to mail copies on electronic storage media, unless an exemption permitting an alternative filing method, as further discussed, is granted. Detailed guidance on electronic submissions is located in the “Guidance for Electronic Submissions to the NRC” (ADAMS Accession No. ML13031A056) and on the NRC's public website at
To comply with the procedural requirements of E-Filing, at least 10 days prior to the filing deadline, the participant should contact the Office of the Secretary by email at
Information about applying for a digital ID certificate is available on the NRC's public website at
A person filing electronically using the NRC's adjudicatory E-Filing system may seek assistance by contacting the NRC's Electronic Filing Help Desk through the “Contact Us” link located on the NRC's public website at
Participants who believe that they have good cause for not submitting documents electronically must file an exemption request, in accordance with 10 CFR 2.302(g), with their initial paper filing stating why there is good cause for not filing electronically and requesting authorization to continue to submit documents in paper format. Such filings must be submitted in accordance with 10 CFR 2.302(b) through (d). Participants filing adjudicatory documents in this manner are responsible for serving their documents on all other participants. Participants granted an exemption under 10 CFR 2.302(g)(2) must still meet the electronic formatting requirement in 10 CFR 2.302(g)(1), unless the participant also seeks and is granted an exemption from 10 CFR 2.302(g)(1).
Documents submitted in adjudicatory proceedings will appear in the NRC's electronic hearing docket, which is publicly available at
The following table provides the plant name, docket number, date of application, ADAMS accession number, and location in the application of the licensees' proposed NSHC determinations. For further details with respect to these license amendment applications, see the applications for amendment, which are available for public inspection in ADAMS. For additional direction on accessing information related to this document, see the “Obtaining Information and Submitting Comments” section of this document.
During the period since publication of the last monthly notice, the Commission has issued the following amendments. The Commission has determined for each of these amendments that the application complies with the standards and requirements of the Atomic Energy Act of 1954, as amended (the Act), and the Commission's rules and regulations. The Commission has made appropriate findings as required by the Act and the Commission's rules and regulations in 10 CFR chapter I, which are set forth in the license amendment.
A notice of consideration of issuance of amendment to facility operating license or combined license, as applicable, proposed NSHC determination, and opportunity for a hearing in connection with these actions, was published in the
Unless otherwise indicated, the Commission has determined that these amendments satisfy the criteria for categorical exclusion in accordance with 10 CFR 51.22. Therefore, pursuant to 10 CFR 51.22(b), no environmental impact statement or environmental assessment need be prepared for these amendments. If the Commission has prepared an environmental assessment under the special circumstances provision in 10 CFR 51.22(b) and has made a determination based on that assessment, it is so indicated in the safety evaluation for the amendment.
For further details with respect to each action, see the amendment and associated documents such as the Commission's letter and safety evaluation, which may be obtained using the ADAMS accession numbers indicated in the following table. The safety evaluation will provide the ADAMS accession numbers for the application for amendment and the
Since publication of the last monthly notice, the Commission has issued the following amendments. The Commission has determined for each amendment that the application for the amendment complies with the standards and requirements of the Atomic Energy Act of 1954, as amended (the Act), and the Commission's rules and regulations. The Commission has made appropriate findings as required by the Act and the Commission's rules and regulations in 10 CFR chapter I, which are set forth in the license amendments.
Because of exigent circumstances or emergency situation associated with the date the amendment was needed, there was not time for the Commission to publish, for public comment before issuance, its usual notice of consideration of issuance of amendment, proposed NSHC determination, and opportunity for a hearing.
For exigent circumstances, the Commission has either issued a
In circumstances where failure to act in a timely way would have resulted, for example, in derating or shutdown of a nuclear power plant or in prevention of either resumption of operation or of increase in power output up to the plant's licensed power level, the Commission may not have had an opportunity to provide for public comment on its NSHC determination. In such case, the license amendment has been issued without opportunity for comment prior to issuance. If there has been some time for public comment but less than 30 days, the Commission may provide an opportunity for public comment. If comments have been requested, it is so stated. In either event, the State has been consulted by telephone whenever possible.
Under its regulations, the Commission may issue and make an amendment immediately effective, notwithstanding the pendency before it of a request for a hearing from any person, in advance of the holding and completion of any required hearing, where it has determined that NSHC is involved.
The Commission has applied the standards of 10 CFR 50.92 and has made a final determination that the amendments involve NSHC. The basis for this determination is contained in the documents related to each action. Accordingly, the amendments have been issued and made effective as indicated. For those amendments that have not been previously noticed in the
Unless otherwise indicated, the Commission has determined that each amendment satisfies the criteria for categorical exclusion in accordance with 10 CFR 51.22. Therefore, pursuant to 10 CFR 51.22(b), no environmental impact statement or environmental assessment need be prepared for these amendments. If the Commission has prepared an environmental assessment under the special circumstances provision in 10 CFR 51.12(b) and has made a determination based on that assessment, it is so indicated in the safety evaluation for each amendment.
For further details with respect to these actions, see the amendments and associated documents such as the Commission's letter and safety evaluation, which may be obtained using the ADAMS accession numbers indicated in the following table. The safety evaluation will provide the ADAMS accession number(s) for the application for amendment and the
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.
2.
This Notice will be published in the
Pursuant to Section 19(b)(1) of the Securities Exchange Act of 1934 (the “Act”),
Cboe EDGX Exchange, Inc. (the “Exchange” or “EDGX”) proposes to amend its Fee Schedule. The text of the proposed rule change is provided in Exhibit 5.
The text of the proposed rule change is also available on the Exchange's website (
In its filing with the Commission, the Exchange 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 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 aspects of such statements.
The Exchange proposes to amend its Fee Schedule.
The Exchange's Fee Schedule sets forth standard rebates and rates applied per contract. For example, the Exchange assesses a fee of $0.20 per contract for SAM
The Fee Codes and Associated Fees section of the Fee Schedule also provides for certain fee codes associated with certain order types and market participants that provide for various other fees or rebates. Additionally, the Fee Schedule offers tiered pricing which provides Members
For example, pursuant to Footnote 7 of the Fee Schedule, the Exchange currently offers four QCC
The Exchange proposes to amend the QCC Initiator/Solicitation Rebate Tier program by (1) amending the volume threshold for Tier 3, (2) eliminating Tier 4, and (3) amending current rebates for Tiers 2 and 3.
The Exchange proposes to amend the volume thresholds for Tier 3. Currently, the volume threshold (per month) for Tier 1 is 0 to 999,999 contracts, for Tier 2 is 1,000,000 to 1,999,999 contracts, for Tier 3 is 2,000,000 to 2,999,999 contracts, and for Tier 4 is 3,000,000+ contracts. As proposed, the volume threshold (per month) for Tier 1 remains at 0 to 999,999 contracts, for Tier 2 remains at 1,000,000 to 1,999,999, and for Tier 3 is 2,000,000+ contracts. The Exchange proposes to eliminate Tier 4, as the volume thresholds and rebates for these tiers are now contained within the volume threshold for Tier 3, as amended.
Further, the Exchange proposes to change the rebates for Tiers 2 and 3. Specifically, the Exchange proposes to increase Tier 2 Rebate 1 from $0.15 to $0.16, Tier 2 Rebate 2 from $0.23 to $0.25, Tier 3 Rebate 1 from $0.16 to $0.18, and Tier 3 Rebate 2 from $0.24 to $0.28. The rebates for Tier 1 remain unchanged. The proposed rebate changes account for the elimination of Tier 4, and maintain an established rebate structure based on volume.
The Exchange believes the proposed rebate structure is competitive with rebates offered at another exchange for similar transactions.
In connection with the proposed changes to Footnote 7 of the Fee Schedule, the Exchange proposes to amend the Fee Codes and Associated Fees table of the Fee Schedule to adopt new fee codes for SAM Contra
The Exchange also proposes to amend the description of current fee code SF to provide it applies to SAM Contra Non-Customer, Non-Professional orders, and to amend the current description of current fee code SA to provide it applies to SAM Agency Non-Customer, Non-Professional orders. The Exchange proposes to decrease the standard fee for SAM Contra Non-Customer, Non-Professional orders and SAM Agency Non-Customer, Non-Professional orders (
The proposed rule change also amends Footnote 6 of the Fee Schedule to include new fee codes SG and SH, and to reflect the proposed change in fees for orders yielding fee codes SF and SA.
The Exchange also proposes to amend Footnote 1 (Customer Volume Tiers), applicable to orders yielding fee codes
The Exchange proposes to change the rebates for Tier 3. Specifically, the Exchange proposes to amend the Tier 3 rebate from $0.21 to $0.17.
The Exchange also proposes to amend the required criteria for Tier 4. Currently, to qualify for Tier 4, a Member must have (1) an ADV in Customer orders greater than or equal to 0.75% of average OCV; and (2) an ADV in Customer or Market Maker orders greater than or equal to 1.00% of average OCV; and (3) an ADV in Customer Non-Crossing orders greater than or equal to 0.40% of average OCV. The Exchange proposes to amend Tier 4 required criteria to state that a Member must have (1) an ADV in Customer orders greater than or equal to 0.75% of average OCV; and (2) an ADV in Customer or Market Maker orders greater than or equal to 1.50% of average OCV; and (3) an ADV in Customer Non-Crossing orders greater than or equal to 0.50% of average OCV; and (4) an ADAV in Customer Non-Crossing orders greater than or equal to 0.40% of average OCV.
The Exchange believes that the proposed changes to the Customer Volume Rebate Tier program are designed overall to incentivize more Customer order flow and to direct an increase of order flow to the EDGX Options Order Book. The Exchange believes that an increase in Customer order flow and overall order flow to the Exchange's Book creates more trading opportunities, which, in turn attracts Market-Makers. A resulting increase in Market-Maker activity may facilitate tighter spreads, which may lead to an additional increase of order flow from other market participants, further contributing to a deeper, more liquid market to the benefit of all market participants by creating a more robust and well-balanced market ecosystem.
The Exchange believes the proposed rule change is consistent with the Securities Exchange Act of 1934 (the “Act”) and the rules and regulations thereunder applicable to the Exchange and, in particular, the requirements of Section 6(b) of the Act.
As described above, the Exchange operates in a highly competitive market in which market participants can readily direct order flow to competing venues if they deem fee levels at a particular venue to be excessive or incentives to be insufficient. The proposed rule change reflects a competitive pricing structure designed to incentivize market participants to direct their order flow to the Exchange, which the Exchange believes would enhance market quality to the benefit of all market participants. The Exchange is only one of several options venues to which market participants may direct their order flow, and it represents a small percentage of the overall market. The proposed fee changes reflect a competitive pricing structure designed to incentivize market participants to direct their order flow, which the Exchange believes would enhance market quality to the benefit of all Members.
The Exchange believes the proposed changes to the QCC Initiator/Solicitation Rebate Tiers are reasonable, equitable, and not unfairly discriminatory. The Exchange believes the changes to the QCC Initiator/Solicitation Rebate Tiers are reasonable overall because, as stated above, in order to operate in the highly competitive markets, the Exchange and its competing exchanges seek to offer similar pricing structures, including assessing comparable rates and offering multiple enhanced pricing opportunities for various types of orders. Thus, the Exchange believes the proposed changes are reasonable as they are generally aligned with and competitive with the amounts assessed for similar orders on other options exchanges.
Overall, the Exchange believes that its proposed adoption of new fee codes for SAM Contra Professional and SAM Agency Professional orders (and related fee changes for SAM Contra Non-Customer, Non-Professional and SAM Agency Non-Customer, Non-Professional orders) is consistent with Section 6(b)(4) of the Act in that the proposed fees are reasonable, equitable and not unfairly discriminatory. The Exchange believes that the proposed fees are reasonable, equitable, and not unfairly discriminatory in that competing options exchanges offer a similar distinction between market participant types in connection with similar price improvement auctions,
The proposed fees in relation to SAM orders are designed to promote order flow through SAM and, in particular, to attract liquidity, which benefits all market participants by providing additional trading opportunities at improved prices. This, in turn, attracts increased large-order flow from liquidity providers which facilitates tighter spreads and potentially triggers a corresponding increase in order flow originating from other market participants.
Also, the Exchange believes that the proposed fee for SAM Non-Customer, Non-Professional Agency and Contra orders ($0.18 per contract) is reasonable because it encourages participation in SAM by offering a rate that is equivalent to or better than most other price improvement auctions offered by other options exchanges as well as the Exchange itself.
The Exchange believes the proposed changes to the Customer Volume Rebate Tier program are reasonable because they continue to provide opportunities for Members to receive higher rebates by providing for incrementally increasing volume-based criteria they can reach for. The Exchange believes the tiers, as modified, continue to serve as a reasonable means to encourage Members to increase their liquidity on the Exchange, particularly in connection with additional Customer Order flow to the Exchange in order to benefit from the proposed enhanced rebates. The Exchange also notes that any overall increased liquidity that may result from the proposed tier incentives benefits all investors by offering additional flexibility for all investors to enjoy cost savings, supporting the quality of price discovery, promoting market transparency and improving investor protection.
The Exchange believes that the proposed changes to the Customer Volume Rebate Tier program represent an equitable allocation of fees and is not unfairly discriminatory because Members will be eligible for these tiers and the corresponding enhanced rebates will apply uniformly to all Members that reach the proposed tier criteria. The Exchange believes that a number of market participants have a reasonable opportunity to satisfy the tiers' criteria as modified. While the Exchange has no way of knowing whether this proposed rule change would definitively result in any particular Member qualifying for Tier 4 as amended, the Exchange anticipates at least two Members meeting, or being reasonably able to meet, the revised Tier 4 criteria; however, the proposed tier is open to any Member that satisfies the tier's criteria. The Exchange also notes that the proposed changes will not adversely impact any Member's pricing or their ability to qualify for other rebate tiers. Rather, should a Member not meet the proposed criteria, the Member will merely not receive the corresponding enhanced rebates.
The Exchange does not believe that the proposed rule change will impose any burden on competition that is not necessary or appropriate in furtherance of the purposes of the Act. Rather, as discussed above, the Exchange believes that the proposed change would encourage the submission of additional order flow to a public exchange, thereby promoting market depth, execution incentives and enhanced execution opportunities for all Members. As a result, the Exchange believes that the proposed change furthers the Commission's goal in adopting Regulation NMS of fostering competition among orders, which promotes “more efficient pricing of individual stocks for all types of orders, large and small.”
The Exchange believes that the proposed rule change does not impose any burden on intramarket competition that is not necessary or appropriate in furtherance of the purposes of the Act. First, the Exchange notes that the proposed changes apply uniformly to similarly situated Members. The Exchange believes that the proposed changes related to QCC and SAM transactions would not impose any burden on intramarket competition, but rather, serves to increase intramarket competition by incentivizing members, including Professionals, to direct their QCC and SAM orders to the Exchange, in turn providing for more opportunities to compete at improved prices. Similarly, the changes to the Customer Volume Rebate Tier program provides an incentive to bring additional liquidity to the Exchange, thereby promoting price discovery and enhancing order execution opportunities for Members.
Additionally, the proposed rule change benefits all market participants as any overall increased liquidity that may result from the proposed fee and tier incentives benefits all investors by offering additional flexibility for all investors to enjoy cost savings, supporting the quality of price discovery, promoting market transparency and improving investor protection.
The Exchange also believes the proposed rule change does not impose any burden on intermarket competition that is not necessary or appropriate in furtherance of the purposes of the Act. As previously discussed, the Exchange operates in a highly competitive market. Members have numerous alternative venues they may participate on and direct their order flow, including 15 other options exchanges. Additionally, the Exchange represents a small percentage of the overall market. Based on publicly available information, no single options exchange has more than 17% of the market share. Therefore, no exchange possesses significant pricing power in the execution of order flow. Indeed, participants can readily choose to send their orders to other exchanges if they deem fee levels at those other venues to be more favorable. Moreover, 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 fact that this market is competitive has also long been recognized by the courts. In
The Exchange neither solicited nor received comments on the proposed rule change.
The foregoing rule change has become effective pursuant to Section 19(b)(3)(A) of the Act
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.
Pursuant to Section 19(b)(1)
The Exchange proposes to modify the NYSE Arca Options Fee Schedule (“Fee Schedule”) regarding the Limit of Fees on Options Strategy Executions (the “Strategy Cap”). The Exchange proposes to implement the fee change effective April 3, 2023. 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 purpose of this filing is to amend the Fee Schedule to include certain strategy executions which are the result of a QCC order
The Fee Schedule currently provides that the Strategy Cap is a $1,000 cap on transaction fees for orders that are executed to achieve certain investment strategies (“Strategy Executions”).
The Exchange now proposes to modify the Strategy Cap to provide that fees associated with a reversal and conversion strategy
The Exchange also proposes to modify Endnote 17, which currently provides that Submitting Broker QCC credits and Floor Broker rebates earned through the Manual Billable Rebate Program shall not combine to exceed $2,000,000 per month per firm. The Exchange proposes to amend Endnote 17 to add a sentence providing that Submitting Broker QCC credits will not apply to any QCC trades that are included in the Strategy Cap. The Exchange believes this proposed change is reasonable because it is intended to clarify which incentives are applicable to Reversal/Conversion QCCs once such transactions are eligible for the Strategy Cap, as proposed.
The Exchange believes that the proposed rule change is consistent with Section 6(b) of the Act,
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 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.”
There are currently 16 registered options exchanges competing for order flow. Based on publicly-available information, and excluding index-based options, no single exchange has more than 16% of the market share of executed volume of multiply-listed equity and ETF options trades.
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. Accordingly, competitive forces constrain options exchange transaction fees. Stated otherwise, modifications 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 modification of the Strategy Cap to add Reversal/Conversion QCCs to the transactions included in the Strategy Cap is reasonable because the proposed change is designed to incent OTP Holders to increase the number of QCC transactions sent to the Exchange. Specifically, the proposed change is intended to encourage OTP Holders to direct additional QCC transactions to the Exchange by limiting fees associated with Reversal/Conversion QCCs. The Exchange believes that it is reasonable to include Reversal/Conversion QCCs, but not other strategies executed as QCCs, in the Strategy Cap because of the specific fee sensitivity related to arbitrage of components of a reversal and conversion strategy. Accordingly, the proposed change is intended to encourage additional Reversal/Conversion QCCs by making fees for such transactions eligible for the Strategy Cap. As noted above, NYSE American Options already includes Reversal/Conversion QCCs in its cap on fees for Strategy Executions, and the proposed change would thus also provide consistency between the Exchange's fees and those of its affiliated options market. The Exchange also believes that the proposed change to Endnote 17 of the Fee Schedule is reasonable considering the proposed
Finally, to the extent the proposed change continues to attract greater volume and liquidity, the Exchange believes the proposed change would improve the Exchange's overall competitiveness and strengthen its market quality for all market participants. In the backdrop of the competitive environment in which the Exchange operates, the proposed rule change is a reasonable attempt by the Exchange to increase the depth of its market and improve its market share relative to its competitors. The Exchange's fees are constrained by intermarket competition, as OTP Holders may direct their order flow to any of the 16 options exchanges, including at least one other exchange that limits fees for QCC Strategy Executions.
The Exchange believes the proposed rule change is an equitable allocation of its fees and credits. The proposed inclusion of Reversal/Conversion QCCs under the Strategy Cap and an OTP Holder's ability to qualify for the Strategy Cap are based on the type and amount of business transacted on the Exchange, and OTP Holders can attempt to submit such transactions or not to achieve the Strategy Cap. The Exchange also believes that the proposed change to Endnote 17 is equitable because it would promote clarity in the Fee Schedule as to which fees and credits are applicable to QCC transactions, in light of the proposed change to include Reversal/Conversion QCCs in the transactions eligible for limited fees pursuant to the Strategy Cap. In addition, the proposed changes to make Reversal/Conversion QCCs eligible for the Strategy Cap and to clarify Endnote 17 are equally applicable to all OTP Holders. To the extent the proposed changes continue to incent OTP Holders to direct increased liquidity to the Exchange, all market participants would benefit from enhanced opportunities for price improvement and order execution. Moreover, the proposed fee limitations are designed to encourage OTP Holders to aggregate their executions—including Reversal/Conversion QCC transactions—at the Exchange as a primary execution venue. To the extent that the proposed change achieves its purpose in attracting more volume to the Exchange, this increased order flow would continue to make the Exchange a more competitive venue for, among other things, order execution. Thus, the Exchange believes the proposed rule change would improve market quality for all market participants on the Exchange and, as a consequence, attract more order flow to the Exchange, thereby improving market-wide quality and price discovery.
The Exchange believes the proposed change is not unfairly discriminatory because the proposed change to the Strategy Cap to include Reversal/Conversion QCC transactions and the proposed modification of Endnote 17 would apply to all qualifying OTP Holders on an equal and non-discriminatory basis. The proposed change is based on the amount and type of business transacted on the Exchange, and OTP Holders are not obligated to execute QCC transactions or Strategy Executions. Rather, the proposal is designed to expand the benefits offered by the Strategy Cap and to encourage OTP Holders to increase Reversal/Conversion QCC volume sent to the Exchange and to utilize the Exchange as a primary trading venue for all transactions (if they have not done so previously). To the extent that the proposed change attracts more Reversal/Conversion QCC transactions to the Exchange, this increased order flow would continue to make the Exchange a more competitive venue for order execution. Thus, the Exchange believes the proposed rule change would improve market quality for all market participants on the Exchange and, as a consequence, attract more order flow to the Exchange, thereby improving market-wide quality and price discovery. The resulting increased volume and liquidity would provide more trading opportunities and tighter spreads to all market participants and thus would promote just and equitable principles of trade, remove impediments to and perfect the mechanism of a free and open market and a national market system and, in general, protect investors and the public interest.
Thus, the Exchange believes that, to the extent the proposed rule change would continue to improve market quality for all market participants on the Exchange and attract more order flow to the Exchange, the resulting increased volume and liquidity would provide more trading opportunities and tighter spreads to all market participants and thus would promote just and equitable principles of trade, remove impediments to and perfect the mechanism of a free and open market and a national market system and, in general, protect investors and the public interest.
Finally, the Exchange believes that it is subject to significant competitive forces, as described below in the Exchange's statement regarding the burden on competition.
In accordance with Section 6(b)(8) of the Act, the Exchange does not believe that the proposed rule change would impose any burden on competition that is not necessary or appropriate in furtherance of the purposes of the Act. Instead, as discussed above, the Exchange believes that the proposed change would encourage the submission of additional liquidity to a public exchange, thereby promoting market
The Exchange believes that the proposed rule change reflects this competitive environment because it modifies the Exchange's fees in a manner designed to continue to incent OTP Holders to direct trading interest (particularly Reversal/Conversion QCC transactions) to the Exchange, to provide liquidity and to attract order flow. To the extent that OTP Holders are incentivized to utilize the Exchange as a primary trading venue for all transactions, all of the Exchange's market participants should benefit from the improved market quality and increased opportunities for price improvement.
The Exchange notes that it operates in a highly competitive market in which market participants can readily favor competing venues. In such an environment, the Exchange must continually review, and consider adjusting, its fees and credits to remain competitive with other exchanges. For the reasons described above, the Exchange believes that the proposed rule change reflects this competitive environment. The Exchange further believes that the proposed change could promote competition between the Exchange and other execution venues, including another options exchange that currently limits fees for QCC Strategy Executions, by encouraging additional orders to be sent to the Exchange for execution.
No written comments were solicited or received with respect to the proposed rule change.
The foregoing rule change is effective upon filing pursuant to Section 19(b)(3)(A)
At any time within 60 days of the filing of such 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.
For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
Pursuant to Section 19(b)(1) of the Securities Exchange Act of 1934,
The principal purpose of the proposed rule change is to revise the ICC Rulebook (the “Rules”) to provide for the clearance of an additional Standard Emerging Market Sovereign CDS contract (the “EM Contract”).
In its filing with the Commission, ICC 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 statements may be examined at the places specified in Item IV below. ICC has prepared summaries, set forth in sections (A), (B), and (C) below, of the most significant aspects of these statements.
The purpose of the proposed rule change is to adopt rules that will provide the basis for ICC to clear an additional credit default swap contract. ICC proposes to make such change effective following Commission approval of the proposed rule change. ICC believes the addition of this contract will benefit the market for credit default swaps by providing market participants the benefits of clearing, including reduction in counterparty risk and safeguarding of margin assets pursuant to clearing house rules. Clearing of the additional EM Contract will not require any changes to ICC's Risk Management Framework or other policies and procedures constituting rules within the meaning of the Securities Exchange Act of 1934 (“Act”).
ICC proposes amending Subchapter 26D of its Rules to provide for the clearance of the additional EM Contract, specifically the Dominican Republic. This additional EM Contract has terms consistent with the other SES EM Contracts (Standard Emerging Market Sovereign (“SES”) Single Name) approved for clearing at ICC and governed by Subchapter 26D of the Rules. Minor revisions to Subchapter 26D are made to provide for clearing the additional EM Contract. Specifically, in Rule 26D-102 (Definitions), “Eligible SES Reference Entities” is modified to include the Dominican Republic in the list of specific Eligible SES Reference Entities to be cleared by ICC.
Section 17A(b)(3)(F) of the Act
Clearing of the additional EM Contract will also satisfy the relevant requirements of Rule 17Ad-22,
Rule 17Ad-22(e)(6)(i)
Rule 17Ad-22(e)(4)(ii)
Rule 17Ad-22(e)(17)
Rule 17Ad-22(e)(8), (9) and (10)
Rule 17Ad-22(e)(2)(i) and (v)
Rule 17Ad-22(e)(13)
ICC does not believe the proposed amendments will have any impact, or impose any burden, on competition not necessary or appropriate in furtherance of the purposes of the Act. As discussed above, the purpose of the proposed rule change is to adopt rules that will provide the basis for ICC to clear additional credit default swap contract. The additional EM Contract will be available to all ICC participants for clearing. The clearing of the additional EM Contract by ICC does not preclude the offering of the additional EM Contract for clearing by other market participants. Accordingly, ICC does not believe that clearance of the additional EM Contract will impose any burden on competition not necessary or appropriate in furtherance of the purposes of the Act.
Written comments relating to the proposed rule change have not been solicited or received. ICC will notify the Commission of any written comments received by ICC.
Within 45 days of the date of publication of this notice in the
(A) by order approve or disapprove such proposed rule change, or
(B) institute proceedings to determine whether the proposed rule change should be disapproved.
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.
All comments received will be posted without change. Persons submitting comments are cautioned that we do not redact or edit personal identifying information from comment submissions. You should submit only information that you wish to make available publicly.
All submissions should refer to File Number SR-ICC-2023-005 and should be submitted on or before May 9, 2023.
For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
Pursuant to Section 19(b)(1) of the Securities Exchange Act of 1934 (the “Act”),
Cboe Exchange, Inc. (the “Exchange” or “Cboe Options”) proposes to amend its Fees Schedule. The text of the proposed rule change is provided in Exhibit 5.
The text of the proposed rule change is also available on the Exchange's website (
In its filing with the Commission, the Exchange 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 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 aspects of such statements.
The Exchange proposes to amend its Fees Schedule in connection with certain Lead Market-Maker (“LMM”) Incentive Programs, effective April 3, 2023. Specifically, the Exchange proposes to amend its NANOS LLM Incentive Program and Global Trading Hours (“GTH”) XSP LMM Incentive Programs.
All three LMM Incentive Programs provide a rebate to Trading Permit Holders (“TPHs”) with LMM appointments to the respective incentive program that meet certain quoting standards in the applicable series in a month. The Exchange notes that meeting or exceeding the quoting standards (both current and as proposed; described in further detail below) in each of the LMM Incentive Program products to receive the applicable rebate (both currently offered and as proposed; described in further detail below) is optional for an LMM appointed to a program. Particularly, an LMM appointed to an incentive program is eligible to receive the corresponding rebate if it satisfies the applicable quoting standards, which the Exchange believes encourages appointed LMMs to provide liquidity in the applicable class and trading session (
The Exchange first proposes to amend the current NANOS LMM Incentive Program. Currently, the NANOS LLM Incentive Program provides that, for NANOS, if the appointed LMM provides continuous electronic quotes during RTH that meet or exceed the heightened quoting standards in at least 99% of the NANOS series 90% of the time in a given month, the LMM will receive a rebate for that month in the amount of $17,500 (or pro-rated amount if an appointment begins after the first trading day of the month or ends prior to the last trading day of the month). The Exchange now proposes to amend the series qualification requirement for the NANOS LMM Incentive Program. Specifically, the Exchange proposes to update the series qualification requirement to require the appointed LMM to provide continuous electronic quotes during RTH that meet or exceed the heightened quoting standards in at least 98% the NANOS series 90% of the time in a given month in order to receive the rebate, thereby decreasing the series qualification requirement by 1%. In changing this requirement, the Exchange wishes to encourage LMMs appointed to the NANOS LMM Incentive Program to provide significant liquidity in NANOS options by meeting the series qualification requirements (and relevant quoting standards) under the Program in order to receive the rebate.
The Exchange proposes to amend the GTH XSP LMM Incentive Programs. The GTH1 XSP LMM Incentive Program
The GTH2 XSP LMM Incentive Program provides that if an LMM appointed to the Program provides continuous electronic quotes during GTH from 2:00AM CST to 9:15AM CST (“GTH2”) that meet or exceed the proposed heightened quoting standards set forth above (the same as GTH1, above) in at least 85% of the series 90% of the time in a given month, the LMM will receive a payment for that month in the amount of $20,000 (or pro-rated amount if an appointment begins after the first trading day of the month or ends prior to the last trading day of the month).
The Exchange proposes to adopt a new set of heightened quoting standards (below) under the GTH1 and GTH2 XSP LMM Incentive Programs (proposed width and sizes are denoted with an asterisk).
The proposed heightened quoting standards for XSP options under the GTH1 and GTH2 XSP LMM Incentive Programs are designed to continue to encourage LMMs appointed to the program to provide significant liquidity in XSP options during GTH. Specifically, the proposed rule change eases the heightened quoting standards in a manner that makes it easier for appointed LMMs to achieve such requirements. By increasing certain quote widths and decreasing certain quote sizes, the changes are designed to incentivize LMMs appointed to the GTH1 and GTH2 LMM Incentive Programs to quote aggressively in XSP options during GTH to receive the rebate offered under the program, resulting in tighter spreads and increased liquidity during GTH to the benefit of investors.
The Exchange also proposes to increase the rebates offered by the GTH1 and GTH2 XSP LMM Incentive Programs to an LMM appointed to the program for meeting the heightened quoting standards in a given month. The Exchange proposes to increase such rebates from $10,000 to $20,000 for the GTH1 XSP LLM Incentive Program, and from $20,000 to $25,000 for the GTH2 XSP LLM Incentive Program. For the GTH1 XSP LMM Incentive Program, an LMM appointed to the program that meets the heightened quoting standard in a month will still receive the additional credit of $0.03 per contract applied to all XSP contracts executed in a Market-Maker capacity which provide liquidity in the Simple Book during RTH (or pro-rated amounts if an appointment begins after the first trading day of the month or ends prior to the last trading day of the month). The Exchange wishes to further incentivize the LMMs appointed to the GTH1 and GTH2 LMM Incentive Programs to provide significant liquidity in XSP options during GTH by meeting the applicable quoting standards under each program to receive the proposed increased rebates.
The Exchange believes the proposed rule change is consistent with the Securities Exchange Act of 1934 (the “Act”) and the rules and regulations thereunder applicable to the Exchange and, in particular, the requirements of Section 6(b) of the Act.
The Exchange believes it is reasonable to decrease the series requirement for the NANOS LLM Incentive Program to 98% (from 99%), and to update the heightened quoting standards for the GTH1 and GTH2 XSP LLM Incentive Programs by decreasing certain quote size requirements and increasing certain quote width requirements, as such changes are reasonably designed to slightly ease the difficulty in meeting the heightened quoting standards offered under these programs (for which an appointed LMM receives the respective rebates), which, in turn, provides increased incentive for LMMs appointed to these programs to provide significant liquidity in NANOS options and XSP options. Such liquidity benefits all market participants by providing more trading opportunities, tighter spreads, and added market transparency and price discovery, and signals to other market participants to direct their order flow to those markets, thereby contributing to robust levels of liquidity.
Further, the Exchange believes that it is reasonable to update certain quote size and width requirements under the GTH XSP LMM Incentive Programs, as the proposed rule change is generally designed to further align the lesser premium quote widths and size standards for XSP options with the more expensive premium quote width and size standards, in order to incentivize an increase in quoting activity and the provision of tighter markets.
The Exchange also believes the proposed increase to the rebates under the GTH1 and GTH2 XSP LLM Incentive Programs are reasonably designed to further incentivize an appointed LMM to meet the applicable quoting standards for XSP options, thereby providing liquid and active markets, which facilitates tighter spreads, increased trading opportunities, and overall enhanced market quality to the benefit of all market participants. The Exchange further believes that the proposed rule change is reasonable because it is comparable to and within the range of the rebates offered by other LMM Incentive Programs. For example, the GTH2 VIX LMM Programs currently offers a rebate of $20,000 if the quoting standards are met in a given month.
The Exchange believes that the proposed changes to the LMM Incentive Programs are equitable and not unfairly discriminatory. The Exchange believes that it is equitable and not unfairly discriminatory to amend the series qualification requirement for the NANOS LLM Incentive Program, amend certain quote widths and quote sizes in the heightened quoting standards for GTH1 and GTH2 XSP LLM Incentive Programs, and amend the monthly rebates offered under the GTH1 and GTH2 XSP LLM Incentive Programs because such series qualification requirement, heightened quoting standards, and rebates will equally apply to any and all TPHs with LMM appointments to the NANOS, GTH1 XSP, and GTH2 XSP LLM Incentive Programs, as applicable, that seek to meet the programs' heightened quoting standards in order to receive the rebates (as proposed) offered under each respective program. The Exchange additionally notes that, if an LMM appointed to any of the LMM Incentive Programs does not satisfy the corresponding heightened quoting standard for any given month, then it simply will not receive the rebate offered by the respective program for that month.
Regarding the NANOS, GTH1 XSP and GTH2 XSP LMM Incentive Programs generally, the Exchange believes it is reasonable, equitable and not unfairly discriminatory to continue
The Exchange does not believe that the proposed rule change will impose any burden on competition that is not necessary or appropriate in furtherance of the purposes of the Act. The Exchange does not believe that the proposed rule change will impose any burden on intramarket competition that is not necessary or appropriate in furtherance of the purposes of the Act because the amendments to the series qualification requirement for the NANOS LLM Incentive Program, certain quote widths and quote sizes in the heightened quoting standards for the GTH1 and GTH2 XSP LLM Incentive Programs, and the monthly rebates offered under the GTH1 and GTH2 XSP LLM Incentive Programs will apply uniformly to any LMM appointment to the programs. To the extent LMMs appointed to these LMM Incentive Programs receive a benefit that other market participants do not, as stated, these LMMs in their role as Market-Makers on the Exchange have different obligations and are held to different standards. An LMM appointed to an incentive program may also undertake added costs each month to satisfy that heightened quoting standards (
The Exchange also notes that the proposed changes are designed to attract additional order flow to the Exchange, wherein greater liquidity benefits all market participants by providing more trading opportunities, tighter spreads, and added market transparency and price discovery, and signals to other market participants to direct their order flow to those markets, thereby contributing to robust levels of liquidity. As a result, the Exchange believes that the proposed change furthers the Commission's goal in adopting Regulation NMS of fostering competition among orders, which promotes “more efficient pricing of individual stocks for all types of orders, large and small.”
The Exchange does not believe that the proposed rule change will impose any burden on intermarket competition that is not necessary or appropriate in furtherance of the purposes of the Act because the proposed programs are applicable to transactions in a product exclusively listed on the Exchange. Additionally, the Exchange notes that it operates in a highly competitive market. TPHs have numerous alternative venues that they may participate on and direct their order flow, including 15 other options exchanges, as well as off-exchange venues, where competitive products are available for trading. Based on publicly available information, no single options exchange has more than 16% of the market share.
The Exchange neither solicited nor received comments on the proposed rule change.
The foregoing rule change has become effective pursuant to Section 19(b)(3)(A) of the Act
Interested persons are invited to submit written data, views and arguments concerning the foregoing, including whether the proposed rule
• 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.
Persons submitting comments are cautioned that we do not redact or edit personal identifying information from comment submissions. You should submit only information that you wish to make available publicly. All submissions should refer to File Number SR-CBOE-2023-017 and should be submitted on or before May 9, 2023.
For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
Pursuant to Section 19(b)(1) of the Securities Exchange Act of 1934 (“Act”),
The Exchange proposes to (i) adjust or eliminate several of the Exchange's transaction credits, at Equity 7, Section 118(a); and (ii) eliminate several of the Exchange's transaction fees, at Equity 7, Section 118(a), as described further below. The text of the proposed rule change is available on the Exchange's website at
In its filing with the Commission, the Exchange 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 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 aspects of such statements.
The Exchange operates on the “taker-maker” model, whereby it generally pays credits to members that take liquidity and charges fees to members that provide liquidity. Currently, the Exchange has a schedule, at Equity 7, Section 118(a), which consists of several different credits that it provides for orders in securities priced at $1 or more per share that access liquidity on the Exchange and several different charges that it assesses for orders in such securities that add liquidity on the Exchange. The purpose of the proposed rule change is to amend this schedule of fees and credits, at Equity 7, Section 118(a) to: (i) adjust or eliminate several of the Exchange's transaction credits; and (ii) eliminate several of the Exchange's transaction fees.
The Exchange proposes to eliminate two of the Exchange's transaction credits and adjust three of the Exchange's transaction credits.
Currently, the Exchange provides $0.0015, $0.0015, and $0.0014 per share executed credits for securities in Tape A, Tape B, and Tape C, respectively, to a member accessing liquidity (excluding orders with Midpoint pegging and excluding orders that receive price improvement and execute against an order with a non-displayed price): (i) whose combined liquidity removing and adding activities equal or exceed 0.075% of total Consolidated Volume during a month; and (ii) that adds liquidity equal to or exceeding an average daily volume of 50,000 shares in a month. The Exchange proposes to eliminate this credit because it has not been successful in accomplishing its objectives. That is, it has not induced members to materially grow liquidity removing and adding activity on the Exchange. The Exchange also seeks to simplify its schedule of credits. The Exchange has limited resources to allocate to incentive programs and it must, from time to time, reallocate resources to maximize their net impact on the Exchange, market quality, and participants.
Currently, the Exchange provides a $0.0018 per share executed credit for securities in Tape B to a member accessing liquidity that (excluding orders with Midpoint pegging and excluding orders that receive price improvement and execute against an
Presently, the Exchange provides a $0.0015 per share executed credit for securities in Tape C to a member accessing liquidity (excluding orders with Midpoint pegging and excluding orders that receive price improvement and execute against an order with a non-displayed price): (i) whose combined liquidity removing and adding activities equal or exceed 0.10% of total Consolidated Volume during a month; (ii) that accesses liquidity equal to or exceeding 0.05% of total Consolidated Volume during a month; and (iii) that adds liquidity equal to or exceeding an average daily volume of 50,000 shares in a month. The Exchange proposes to increase the amount of this credit for securities in Tape C to $0.0016 per share executed.
Currently, the Exchange provides a $0.0009 per share executed credit for securities in Tape C to a member accessing liquidity (excluding orders with Midpoint pegging and excluding orders that receive price improvement and execute against an order with a non-displayed price): (i) whose combined liquidity removing and adding activities equal or exceed 0.05% of total Consolidated Volume during a month; and (ii) that adds liquidity equal to or exceeding an average daily volume of 50,000 shares in a month. The Exchange proposes to increase the amount of this credit for securities in Tape C to $0.0010 per share executed.
Finally, the Exchange currently provides a $0.0004 per share executed credit for securities in Tape C to a member accessing liquidity (excluding orders with Midpoint pegging and excluding orders that receive price improvement and execute against an order with a non-displayed price) that adds liquidity equal to or exceeding an average daily volume of 50,000 shares in a month. The Exchange proposes to increase the amount of this credit for securities in Tape C to $0.0005 per share executed.
The Exchange proposes to increase the three credits described above for securities in Tape C to make these credit amounts consistent with the credits offered for securities in Tapes A and B. These adjustments will align existing incentives for members to add liquidity or executions on the Exchange.
In addition, the Exchange proposes to eliminate six of the Exchange's transaction fees.
Currently, the Exchange charges members providing liquidity $0.0012 per share executed for securities in Tapes A, B, and C for displayed orders entered by a member that adds liquidity equal to or exceeding 0.25% of total Consolidated Volume during a month. The Exchange charges members providing liquidity $0.0014 per share executed for securities in Tapes A, B, and C for displayed orders entered by a member that adds liquidity equal to or exceeding 0.15% of total Consolidated Volume during a month. The Exchange charges members providing liquidity $0.0017 per share executed for securities in Tapes A, B, and C for displayed orders entered by a member that adds liquidity equal to or exceeding 0.10% of total Consolidated Volume during a month. The Exchange proposes to eliminate these fees because they have not been successful in accomplishing their objectives. That is, they have not induced members to materially add liquidity on the Exchange. The Exchange also seeks to simplify its schedule of fees. The Exchange has limited resources to allocate to incentive programs and it must, from time to time, reallocate resources to maximize their net impact on the Exchange, market quality, and participants.
Presently, the Exchange charges members providing liquidity $0.0017 per share executed for securities in Tapes A, B, and C for displayed orders entered by a member that: (i) adds liquidity equal to or exceeding an average daily volume of 9,500,000 shares in a month; and (ii) adds at least 15% more liquidity relative to the member's March 2021 average daily volume of liquidity provided. The Exchange charges members providing liquidity $0.0020 per share executed for securities in Tapes A, B, and C for displayed orders that adds liquidity entered by a member that: (i) adds liquidity equal to or exceeding an average daily volume of 2,500,000 shares in a month; and (ii) adds at least 25% more liquidity relative to the member's March 2021 average daily volume of liquidity provided. The Exchange proposes to eliminate these fees because the baseline month for the growth element of the fees—March 2021—is no longer a relevant benchmark. As such, this fee no longer provides a growth incentive that is aligned with the Exchange's needs. As noted, the Exchange has limited resources to devote to incentive programs, and it is appropriate for the Exchange to reallocate these incentives periodically in a manner that best achieves the Exchange's overall mix of objectives.
Finally, the Exchange also currently charges members providing liquidity $0.0024 per share executed for securities in Tapes A, B, and C for non-displayed orders (other than orders with Midpoint pegging) entered by a member that (i) adds and removes liquidity equal to or exceeding 0.15% total Consolidated Volume during a month; and (ii) achieves at least a 35% ratio of its displayed liquidity adding activity to its total liquidity adding activity during a month. The Exchange proposes to eliminate this fee because the fee has not been successful in accomplishing its objective and the Exchange seeks to streamline its fee schedule.
The Exchange believes that its proposal is consistent with Section 6(b) of the Act,
The Exchange's proposed changes to its schedule of credits are reasonable in several respects. As a threshold matter, the Exchange is subject to significant competitive forces in the market for equity securities transaction services that constrain its pricing determinations in that market. The fact that this market is competitive has long been recognized by the courts. In
The Commission and the courts have repeatedly expressed their preference for competition over regulatory intervention in determining prices, products, and services in the securities markets. In Regulation NMS, while adopting a series of steps to improve the current market model, 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.”
Numerous indicia demonstrate the competitive nature of this market. For example, clear substitutes to the Exchange exist in the market for equity security transaction services. The Exchange is only one of several equity venues to which market participants may direct their order flow. Competing equity exchanges offer similar tiered pricing structures to that of the Exchange, including schedules of rebates and fees that apply based upon members achieving certain volume thresholds.
Within this environment, market participants can freely and often do shift their order flow among the Exchange and competing venues in response to changes in their respective pricing schedules. As such, the proposal represents a reasonable attempt by the Exchange to increase its liquidity and market share relative to its competitors.
The Exchange believes it is reasonable, equitable, and not unfairly discriminatory to eliminate two of the Exchange's transaction credits, adjust three of the Exchange's transaction credits, and eliminate six of the Exchange's transaction fees. The Exchange seeks to simplify and streamline its schedule of credits and fees by: (i) eliminating credits and fees that have not been successful in inducing members to grow their liquidity adding or removing activity or that are no longer based on relevant benchmarks; and (ii) adjusting several credits to securities in Tape C to streamline such credits to those provided in Tapes A and B. The proposed changes are designed to better align with the Exchange's needs. The Exchange has limited resources to devote to incentive programs, and it is appropriate for the Exchange to reallocate these incentives periodically in a manner that best achieves the Exchange's overall mix of objectives.
Those participants that are dissatisfied with the eliminations and adjustments to the Exchange's schedule of credits and fees are free to shift their order flow to competing venues that provide more generous incentives or less stringent qualifying criteria.
The Exchange does not believe that the proposed rule change will impose any burden on competition not necessary or appropriate in furtherance of the purposes of the Act.
The Exchange does not believe that its proposals will place any category of Exchange participant at a competitive disadvantage.
The Exchange intends for its proposed changes to its credits and fees to reallocate its limited resources more efficiently and for optimized effect, to recalibrate them to reflect changing market behavior, and to align them with the Exchange's overall mix of objectives. The Exchange notes that its members are free to trade on other venues to the extent they believe that these proposals are not attractive. As one can observe by looking at any market share chart, price competition between exchanges is fierce, with liquidity and market share moving freely between exchanges in reaction to fee and credit changes.
In terms of inter-market competition, the Exchange notes that it operates in a highly competitive market in which market participants can readily favor competing venues if they deem fee levels at a particular venue to be excessive, or rebate opportunities available at other venues to be more favorable. In such an environment, the Exchange must continually adjust its credits and fees to remain competitive with other exchanges and with alternative trading systems that have been exempted from compliance with the statutory standards applicable to exchanges. Because competitors are free to modify their own credits and fees in response, and because market participants may readily adjust their order routing practices, the Exchange believes that the degree to which credit or fee changes in this market may impose any burden on competition is extremely limited. The proposals are reflective of this competition.
Even as one of the largest U.S. equities exchanges by volume, the Exchange has less than 20% market share, which in most markets could hardly be categorized as having enough market power to burden competition. Moreover, as noted above, price competition between exchanges is fierce, with liquidity and market share moving freely between exchanges in reaction to fee and credit changes. This is in addition to free flow of order flow to and among off-exchange venues, which comprises upwards of 50% of industry volume.
In sum, if the change proposed herein is unattractive to market participants, it is likely that the Exchange will lose market share as a result. Accordingly, the Exchange does not believe that the proposed change will impair the ability of members or competing order execution venues to maintain their competitive standing in the financial markets.
No written comments were either solicited or received.
The foregoing rule change has become effective pursuant to Section 19(b)(3)(A) of the Act
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: (i) necessary or appropriate in the public interest; (ii) for the protection of investors; or (iii) otherwise in furtherance of the purposes of the Act. If the Commission takes such action, the Commission shall institute proceedings to determine whether the proposed rule should be approved or disapproved.
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.
On December 23, 2022, the Financial Industry Regulatory Authority, Inc. (“FINRA”) filed with the Securities and Exchange Commission (“Commission”) proposed rule change SR-FINRA-2022-033 pursuant to Section 19(b)(1) of the Securities Exchange Act of 1934 (“Exchange Act”)
The Commission is publishing this order pursuant to Section 19(b)(2)(B) of the Exchange Act
FINRA's Dispute Resolution Services (“DRS”) provides an arbitration forum for disputes between customers, member firms, and associated persons of member firms.
Whatever the size of the claim or nature of the dispute, the arbitrator-selection process typically follows the same steps for each case: (1) the Neutral List Selection System (“NLSS”), a computerized list-selection algorithm, randomly generates a list (or lists) of arbitrators from FINRA's rosters of eligible arbitrators for the selected hearing location for each proceeding;
FINRA has proposed to amend the Codes to address the arbitrator list-selection process. Specifically, the proposed rule change would:
(1) Codify current practice
(2) Codify current practice
(3) Expressly authorize the Director to remove an arbitrator for a conflict of interest or bias, either upon request of a party or on the Director's own initiative, “[a]fter the Director sends the lists generated by the list selection algorithm to the parties, but before the first hearing session begins.”
The proposed rule change would also amend certain procedural rules governing FINRA arbitration cases. Specifically, the proposed rule change would:
(1) Provide that “prehearing conferences” will generally be held by video and “hearings” on the merits will generally be held in person, unless “the parties agree to, or the panel grants a motion for, another type of hearing session,”
(2) Provide that any abbreviated hearing (
(3) Require parties in simplified arbitrations to redact personal confidential information from documents filed with the Director,
(4) Amend the definition of “hearing session” to indicate that, during a single day, “the next hearing session begins after four hours of hearing time has elapsed,”
(5) Require a respondent filing an answer containing a third-party claim to: (a) execute a Submission Agreement
(6) Amend various aspects of the rules governing the filing of amended pleadings to, among other things, extend those rules to the filing of third-party claims,
(7) Amend rules governing when an arbitration panel may decide a motion to combine separate but related claims or reconsider the Director's previous decision upon a party's motion,
(8) Amend rules governing motions practice to, among other things, address the timing of the Director's delivery of pleadings to the arbitrator panel,
(9) Expressly provide that any party generating a list of documents and other materials prior to the first scheduled hearing may provide that list to other parties, but must not combine it with a witness list in a single document filed with the Director,
(10) Amend rules governing hearing records to: (a) identify which party must distribute transcripts of the official record;
(11) Codify current practice
(12) Require a panel to issue an “award” (
Amendment No. 1 would modify proposed Rules 12314 and 13314 (“Combining Claims”). Under the Codes, a party may move to join multiple claims (
Before ranked arbitrator lists are due to the Director, the Codes permit the Director to combine separate but related claims into a single arbitration.
Amendment No. 1 would modify the proposed rule change by amending proposed Rules 12314(b) and 13314(b) to provide that “[i]f a panel has been appointed to one or more cases, the panel appointed to the lowest numbered case
The Commission is instituting proceedings pursuant to Section 19(b)(2)(B) of the Exchange Act to determine whether the proposed rule change, as modified by Amendment No. 1, should be approved or disapproved.
Pursuant to Section 19(b)(2)(B) of the Exchange Act, the Commission is providing notice of the grounds for disapproval under consideration.
The Commission requests that interested persons provide written submissions of their views, data, and arguments with respect to the issues identified above, as well as any other concerns they may have with the proposed rule change, as modified by Amendment No. 1. In particular, the Commission invites the written views of interested persons concerning whether the proposed rule change, as modified by Amendment No. 1, is consistent with the Exchange Act and the rules thereunder.
Although there do not appear to be any issues relevant to approval or disapproval that would be facilitated by an oral presentation of views, data, and arguments, the Commission will consider, pursuant to Rule 19b-4, any request for an opportunity to make an oral presentation.
Interested persons are invited to submit written data, views, and arguments regarding whether the proposed rule change, as modified by Amendment No. 1, should be approved or disapproved by May 9, 2023. Any person who wishes to file a rebuttal to any other person's submission must file that rebuttal by May 23, 2023.
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.
U.S. Small Business Administration.
Notice.
This is a notice of an Economic Injury Disaster Loan (EIDL) declaration for the State of Washington dated 04/12/2023.
Issued on 04/12/2023.
Submit completed loan applications to: U.S. Small Business Administration, Processing and Disbursement Center, 14925 Kingsport Road, Fort Worth, TX 76155.
A. Escobar, Office of Disaster Recovery & Resilience, U.S. Small Business Administration, 409 3rd Street SW, Suite 6050, Washington, DC 20416, (202) 205-6734.
Notice is hereby given that as a result of the Administrator's EIDL declaration, applications for economic injury disaster loans may be filed at the address listed above or other locally announced locations.
The following areas have been determined to be adversely affected by the disaster:
The Interest Rates are:
The number assigned to this disaster for economic injury is 178700.
The State which received an EIDL Declaration #17870 is Washington.
U.S. Small Business Administration.
Notice.
This is a Notice of the Presidential declaration of a major disaster for Public Assistance Only for the Navajo Nation (FEMA-4703-DR), dated 04/11/2023.
Issued on 04/11/2023.
Submit completed loan applications to: U.S. Small Business Administration, Processing and Disbursement Center, 14925 Kingsport Road, Fort Worth, TX 76155.
A. Escobar, Office of Disaster Assistance, U.S. Small Business Administration, 409 3rd Street SW, Suite 6050, Washington, DC 20416, (202) 205-6734.
Notice is hereby given that as a result of the President's major disaster declaration on 04/11/2023, Private Non-Profit organizations that provide essential services of a governmental nature may file disaster loan applications at the address listed above or other locally announced locations.
The following areas have been determined to be adversely affected by the disaster:
The number assigned to this disaster for physical damage is 17871 6 and for economic injury is 17872 0.
The Department of State will conduct a public meeting at 11 a.m. on Wednesday, May 3, 2023, both in-person at Coast Guard Headquarters in Washington, DC, and via teleconference. The primary purpose of the meeting is to prepare for the 10th session of the International Maritime Organization's (IMO) Sub-Committee on Navigation, Communication, and Search and Rescue (NCSR 10) to be held in London, United Kingdom from Wednesday, May 10, 2023, to Friday, May 19, 2023.
Members of the public may participate up to the capacity of the teleconference phone line, which can handle 500 participants or up to the seating capacity of the room if attending in-person. The meeting location will be the United States Coast Guard Headquarters, Room 5L18-00/01, and to access the teleconference line, participants should call 202-475-4200, use meeting Code 2135101#, and when prompted enter participant PIN 32291450#. To RSVP, participants should contact the meeting coordinator, Mr. George Detweiler, by email at
The agenda items to be considered at this meeting mirror those to be considered at NCSR 10, and include:
Those who plan to participate should contact the meeting coordinator, George Detweiler, by email at
Additional information regarding this and other IMO public meetings may be found at:
Federal Motor Carrier Safety Administration (FMCSA), Department of Transportation (DOT).
Notice of applications for exemption; request for comments.
FMCSA announces receipt of applications from 15 individuals for an exemption from the hearing requirement in the Federal Motor Carrier Safety Regulations (FMCSRs) to operate a commercial motor vehicle (CMV) in interstate commerce. If granted, the exemptions would enable these hard of hearing and deaf individuals to operate CMVs in interstate commerce.
Comments must be received on or before May 18, 2023.
You may submit comments identified by the Federal Docket Management System Docket No. FMCSA-2023-0019 using any of the following methods:
•
•
•
•
To avoid duplication, please use only one of these four methods. See the “Public Participation” portion of the
Ms. Christine A. Hydock, Chief, Medical Programs Division, FMCSA, DOT, 1200 New Jersey Avenue SE, Room W64-224, Washington, DC 20590-0001, (202) 366-4001,
If you submit a comment, please include the docket number for this notice (Docket No. FMCSA-2023-0019), indicate the specific section of this document to which each comment applies, and provide a reason for each suggestion or recommendation. You may submit your comments and material online or by fax, mail, or hand delivery, but please use only one of these means. FMCSA recommends that you include your name and a mailing address, an email address, or a phone number in the body of your document so that FMCSA can contact you if there are questions regarding your submission.
To submit your comment online, go to
If you submit your comments by mail or hand delivery, submit them in an unbound format, no larger than 8
FMCSA will consider all comments and material received during the comment period.
To view comments go to
In accordance with 49 U.S.C. 31315(b)(6), DOT solicits comments from the public on the exemption requests. DOT posts these comments, without edit, including any personal information the commenter provides, to
Under 49 U.S.C. 31136(e) and 31315(b), FMCSA may grant an exemption from the FMCSRs for no longer than a 5-year period if it finds such exemption would likely achieve a level of safety that is equivalent to, or greater than, the level that would be achieved absent such exemption. The statutes also allow the Agency to renew exemptions at the end of the 5-year period. FMCSA grants medical exemptions from the FMCSRs for a 2-year period to align with the maximum duration of a driver's medical certification.
The 15 individuals listed in this notice have requested an exemption from the hearing requirement in 49 CFR 391.41(b)(11). Accordingly, the Agency will evaluate the qualifications of each applicant to determine whether granting the exemption will achieve the required level of safety mandated by statute.
The physical qualification standard for drivers regarding hearing found in § 391.41(b)(11) states that a person is physically qualified to drive a CMV if that person first perceives a forced whispered voice in the better ear at not less than 5 feet with or without the use of a hearing aid or, if tested by use of an audiometric device, does not have an average hearing loss in the better ear greater than 40 decibels at 500 Hz, 1,000 Hz, and 2,000 Hz with or without a hearing aid when the audiometric device is calibrated to American National Standard (formerly ASA Standard) Z24.5—1951.
This standard was adopted in 1970 and was revised in 1971 to allow drivers to be qualified under this standard while wearing a hearing aid, (35 FR 6458, 6463 (Apr. 22, 1970) and 36 FR 12857 (July 8, 1971), respectively).
On February 1, 2013, FMCSA announced in a Notice of Final Disposition titled, “Qualification of Drivers; Application for Exemptions; National Association of the Deaf,” (78 FR 7479), its decision to grant requests from 40 individuals for exemptions from the Agency's physical qualification standard concerning hearing for interstate CMV drivers. Since that time the Agency has published additional notices granting requests from hard of hearing and deaf individuals for exemptions from the Agency's physical qualification standard concerning hearing for interstate CMV drivers.
In accordance with 49 U.S.C. 31136(e) and 31315(b), FMCSA requests public comment from all interested persons on the exemption petitions described in this notice. We will consider all comments received before the close of business on the closing date indicated under the
Federal Motor Carrier Safety Administration (FMCSA), Department of Transportation (DOT).
Notice of final disposition; correction.
In a notice of final disposition published in the
This correction is effective March 21, 2023.
Ms. Christine A. Hydock, Chief, Medical Programs Division, FMCSA, DOT, 1200 New Jersey Avenue SE, Room W64-224, Washington, DC 20590-0001, (202) 366-4001,
On March 21, 2023, FMCSA published a notice of final disposition (88 FR 17080) with an effective date of March 21, 2023, which FMCSA announced its decision to exempt 15 individuals from the requirement in the FMCSRs that interstate CMV drivers have “no established medical history or clinical diagnosis of epilepsy or any other condition which is likely to cause loss of consciousness or any loss of ability to control a CMV.” The exemptions enable these individuals who have had one or more seizures and are taking anti-seizure medication to operate CMVs in interstate commerce. That notice was inadvertently published indicating the incorrect expiration date of the exemptions granted. Through this notice, FMCSA corrects the March 21, 2023, notice of final disposition by indicating the correct expiration date of the exemptions granted.
In FR Doc. 2023-05754 appearing on page 17080 in the
1. On page 17080, in the third column, “The exemptions expire on February 28, 2023.” is corrected to read “The exemptions expire on February 28, 2025.”
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0070 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel ANGLERS CHOICE is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0070 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
30-Day
The Maritime Administration (MARAD) invites public comments on our intention to request the Office of Management and Budget (OMB) approval to renew an information collection in accordance with the Paperwork Reduction Act of 1995. The information collected in the proposed collection OMB 2133-0027 (Capital Construction Fund and Exhibits) is necessary for MARAD to determine an applicant's eligibility to enter a Capital Construction Fund (CCF) Agreement, and their compliance with the requirements of this program. This collection is being revised to include additional respondents, responses, and burden hours, due to the recent approval of the Defense Authorization Act of 2023 expanding the current pool of eligible CCF program participants. We are required to publish this notice in the
Written comments and recommendations for the proposed information collections should be sent within 30 days of publication of this notice to
Daniel Ladd, (202) 366-1859, Office of Financial Approvals, Maritime Administration, 1200 New Jersey Avenue SE, Washington, DC 20590, Email:
A 60-day
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0076 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel ESPIRIT DE LIBERTE is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0076 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0078 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel ALBERG 30 is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0078 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0067 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel NOMADA is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0067 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0073 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel BREATHING ROOM is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0073 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0080 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel LIL MUTHA is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0080 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0082 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel KNOT ON CALL is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0082 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0079 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel CHI is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0079 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0074 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel SUMMERWIND is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0074 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0083 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel HUNTRESS is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0083 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0068 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel SEA ROSE is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0068 at
Please submit your comments, including the attachments, following the
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0071 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel VAGARI is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0071 at
Please submit your comments, including the attachments, following the instructions provided under the above
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0077 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel STAR SAPPHIRE is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0077 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0069 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel GONE AGAIN is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0069 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0072 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel ELSKOV is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0072 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0081 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel LILI is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0081 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Maritime Administration, DOT.
Notice.
The Secretary of Transportation, as represented by the Maritime Administration (MARAD), is authorized to issue coastwise endorsement eligibility determinations for foreign-built vessels which will carry no more than twelve passengers for hire. A request for such a determination has been received by MARAD. By this notice, MARAD seeks comments from interested parties as to any effect this action may have on U.S. vessel builders or businesses in the U.S. that use U.S.-flag vessels. Information about the requestor's vessel, including a brief description of the proposed service, is listed below.
Submit comments on or before May 18, 2023.
You may submit comments identified by DOT Docket Number MARAD-2023-0075 by any one of the following methods:
•
•
If you mail or hand-deliver your comments, we recommend that you include your name and a mailing address, an email address, or a telephone number in the body of your document so that we can contact you if we have questions regarding your submission.
James Mead, U.S. Department of Transportation, Maritime Administration, 1200 New Jersey Avenue SE, Room W23-459, Washington, DC 20590. Telephone 202-366-5723, Email
As described in the application, the intended service of the vessel LATITUDE 41 is:
The complete application is available for review identified in the DOT docket as MARAD 2023-0075 at
Please submit your comments, including the attachments, following the instructions provided under the above heading entitled
Go to the docket online at
Yes. Be aware that your entire comment, including your personal identifying information, will be made publicly available.
If you wish to submit comments under a claim of confidentiality, you should submit the information you claim to be confidential commercial information by email to
In the event MARAD receives a Freedom of Information Act (FOIA) request for the information, procedures described in the Department's FOIA regulation at 49 CFR 7.29 will be followed. Only information that is ultimately determined to be confidential under those procedures will be exempt from disclosure under FOIA.
Anyone can search the electronic form of all comments received into any of our dockets by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). For information on DOT's compliance with the Privacy Act, please visit
By Order of the Maritime Administrator.
Office of the National Coordinator for Health Information Technology (ONC), Department of Health and Human Services (HHS).
Proposed rule.
This proposed rule would implement the Electronic Health Record (EHR) Reporting Program provision of the 21st Century Cures Act by establishing new Conditions and Maintenance of Certification requirements for health information technology (health IT) developers under the ONC Health IT Certification Program (Program). This proposed rule would also make several updates to certification criteria and implementation specifications recognized by the Program, including a revised certification criterion for decision support and revised certification criteria for patient demographics and observations and electronic case reporting. This proposed rule would establish a new baseline version of the United States Core Data for Interoperability (USCDI). Additionally, this proposed rule would provide enhancements to support information sharing under the information blocking regulations. The implementation of these provisions would advance interoperability, improve transparency, and support the access, exchange, and use of electronic health information. The proposed rule would also update the Program in additional ways to advance interoperability, enhance health IT certification, and reduce burden and costs.
To be assured consideration, written or electronic comments must be received at one of the addresses provided below, no later than 5 p.m. on June 20, 2023.
You may submit comments, identified by RIN 0955-AA03, by any of the following methods (please do not submit duplicate comments). Because of staff and resource limitations, we cannot accept comments by facsimile (FAX) transmission.
•
•
•
Michael Lipinski, Office of Policy, Office of the National Coordinator for Health Information Technology, 202-690-7151.
i. The United States Core Data for Interoperability Standard Version 3 (USCDI v3)
ii. C-CDA Companion Guide Updates
iii. “Minimum Standards” Code Sets Updates
iv. Electronic Case Reporting
v. Decision Support Interventions and Predictive Models
vi. Synchronized Clocks Standard
vii. Standardized API for Patient and Population Services
viii. Patient Demographics and Observations Certification Criterion in § 170.315(a)(5)
ix. Updates to Transitions of Care Certification Criterion in § 170.315(b)(1)
x. Patient Requested Restrictions Certification Criterion
xi. Requirement for Health IT Developers To Update Their Previously Certified Health IT
The Secretary of Health and Human Services has delegated responsibilities to ONC for the implementation of certain provisions in Title IV of the 21st Century Cures Act (Pub. L. 114-255, Dec. 13, 2016) (Cures Act) including: the Electronic Health Record (EHR) Reporting Program condition and maintenance of certification requirements under the ONC Health IT Certification Program (Program) and identifying reasonable and necessary activities that do not constitute information blocking.
In addition to fulfilling the HITECH Act's and Cures Act's requirements described above and advancing interoperability, the proposed rule would contribute to fulfilling Executive Orders (E.O.) 13994, 13985, 14036, 14058, and 14091. The President issued E.O. 13994 on January 21, 2021, to ensure a data-driven response to COVID-19 and future high-consequence public health threats. The Cures Act and the information blocking provisions in the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program (85 FR 25642) (ONC Cures Act Final Rule) have enabled critical steps to making data available across the healthcare system. The proposed update in this proposed rule to adopt the United States Core Data for Interoperability Standard Version 3 (USCDI v3) would promote the establishment and use of interoperable data sets of EHI for interoperable health data exchange. As discussed in section III.C.1, USCDI v3 would facilitate the gathering, sharing, and publication of data for use in public health and emergency response (
We are committed to advancing health equity, and this proposed rule is consistent with E.O. 13985 of January 20, 2021, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government
As discussed in section III.C.1.c, the proposal to adopt USCDI v3 also supports the concept of “health equity by design,” where health equity considerations are identified and incorporated from the beginning and throughout the technology design, build, and implementation process, and health equity strategies, tactics, and patterns are guiding principles for developers, enforced by technical architecture, and built into the technology at every layer. If the proposal to adopt USCDI v3 is finalized, certified health IT products and capabilities should be designed with a foundational approach to promote equity. As a result, by their very design, certified health IT and the workflows around them should support equity and efforts to reduce disparities.
E.O. 14091 of Feb. 16, 2023, builds upon previous equity-related E.O.s, including E.O. 13985. Section 1 of E.O. 14091 requires the Federal Government to “promote equity in science and root out bias in the design and use of new technologies, such as artificial intelligence.” Section 8 of E.O. 14091 requires agencies to “prevent and address discrimination and advance equity for all” and to “consider opportunities to prevent and remedy discrimination, including by protecting the public from algorithmic discrimination.”
This proposed rule would revise the existing clinical decision support (CDS) certification criterion by proposing a “Decision Support Interventions” (DSIs) certification criterion to keep pace with
Together, these proposed requirements should improve transparency, promote trustworthiness, and incentivize the development and wider use of fair, appropriate, valid, effective, and safe predictive DSIs to aid decision-making. The resulting information transparency would enable users, including health care providers, to scrutinize these technologies and would increase public trust and confidence in these technologies. The resulting information transparency could expand the use of these technologies in safer, more appropriate, and more equitable ways. This transparency would also inform wider discussions across industry and academia regarding how to evaluate and communicate performance related to predictive decision support interventions.
President Biden's E.O. 14036, Promoting Competition in the American Economy, issued on July 9, 2021, established a whole-of-government effort to promote competition in the American economy and reaffirmed the policy stated in E.O. 13725 of April 15, 2016 (Steps to Increase Competition and Better Inform Consumers and Workers to Support Continued Growth of the American Economy).
Further, as described in section IV, this proposed rule would provide enhancements to support information sharing under the information blocking regulations and promote innovation and competition, as well as address market consolidation. As we have noted, addressing information blocking is critical for promoting innovation and competition in health IT and for the delivery of healthcare services to individuals. In both the ONC Cures Act Proposed (84 FR 7508) and Final (85 FR 25790 through 25791) Rules, we discussed how the information blocking provisions provide a comprehensive response to the issues identified by empirical and economic research that suggested that information blocking may weaken competition, encourage consolidation, and create barriers to entry for developers of new and innovative applications and technologies that enable more effective uses of EHI to improve population health and the patient experience.
Lastly, in support of E.O. 14058, Transforming Federal Customer Experience and Service Delivery to Rebuild Trust in Government, issued on December 16, 2021, we are committed to advancing the equitable and effective delivery of services with a focus on the experience of individuals, health IT developers, and health care providers.
We also strive to improve federal agency coordination. ONC works with the Centers for Medicare & Medicaid Services (CMS) to ensure that our own certification timelines complement timelines for CMS programs that reference ONC regulations, such as the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of the Merit-based Incentive Payment System (MIPS). In the interest of clarity and cohesion among HHS components, we have proposed to align some of our compliance dates to the calendar year for consistency with calendar-year based performance periods in CMS programs when participants may be required to use updated certified health IT. We believe this approach reduces confusion for participants in these programs and better serves the public interest.
Section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a certification program or programs for the voluntary certification of health IT. ONC first introduced the concept of an “edition” of ONC health IT certification criteria in 2012. In 2012, we stated that we would refer to the certification criteria adopted in §§ 170.302, 170.304, and 170.306 collectively as the “2011 Edition EHR certification criteria” and that the certification criteria adopted in § 170.314 would be referred to as the “2014 Edition EHR certification criteria” (77 FR 13836). In 2015, we issued a final rule, “2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications,” (2015 Edition Final Rule) and adopted the “2015 Edition Health IT Certification Criteria” (80 FR 62602). We codified the 2015 Edition certification criteria in § 170.315 to set them apart from other editions of certification criteria (80 FR 62608). In 2020, we published the ONC Cures Act Final Rule (85 FR 25642) and adopted updates to the 2015 Edition. These updates included new certification criteria, standards, and requirements, as well as incremental revisions to existing 2015 Edition certification criteria to better enable interoperability and the access, exchange, and use of electronic health information (85 FR 25664-65). Because we did not adopt a wholesale new edition of certification criteria in a different CFR section, we retained the overall 2015 Edition title for the changes included in the ONC Cures Act Final Rule and made specific timebound compliance changes within certification criteria.
Subsequent to publication of the ONC Cures Act Final Rule through public meetings and correspondence, we heard that the continued use and reference to the 2015 Edition inaccurately implied an age and outdatedness to the certification criteria we had adopted. More importantly, we heard significant positive feedback that the incremental approach to updates is generally beneficial as a long-term approach. Specifically, we heard that a consistent, transparent, incremental update cycle that includes the following features would be preferred by some: (1) regular updates to recognize standards advancement and an allowance for voluntary standards advancement between updates, (2) incremental updates rather than wholesale certified Health IT Module certification criteria overhauls, (3) a predictable timeline for updates based on standards development cycles with reasonable development timelines, and (4) a reasonable development timeline for any new criterion based on the specific development needs.
For these reasons, we no longer believe that it is helpful or necessary to maintain an “edition” naming convention or to adopt entirely new editions of certification criteria to encapsulate updates over time. Instead, we believe there should be a single set of certification criteria, which will be updated in an incremental fashion in closer alignment to standards development cycles and regular health IT development timelines. Therefore, in section III.A, we propose to rename all criteria within the Program simply as “ONC Certification Criteria for Health IT.” We believe maintaining a single set of “ONC Certification Criteria for Health IT” would create more stability for the Program and for federal partners who reference the Program, as well as make it easier for developers of certified health IT to maintain their product certificates over time. This proposal to remove “editions” from the Program would also help users of certified health IT identify which certification criteria are necessary for their participation in other HHS programs, such as Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of the MIPS. For example, users would only need to know that their Health IT Module is certified by ONC in accordance with the ONC Certification Criteria for Health IT for successful participation in MIPS, as compared to the current state where they must also know if the Health IT Module complies with the 2014 Edition Certification Criteria, the 2015 Edition Certification Criteria, or the 2015 Edition Cures Update Certification Criteria.
In addition, we believe that this approach will have the benefit of reducing administrative burden for health IT developers with Health IT Modules certified through the Program. Previously, duplicative references to certification criteria across different year themed editions created administrative burden on developers as they had the effect of requiring health IT developers to seek an updated certificate attributed to the “new” duplicated certification criterion even in circumstances when the certification criterion remained substantively unchanged. Under this proposal, unchanged certification criteria would no longer be duplicated as separate criteria under multiple editions.
In the ONC Cures Act Final Rule, ONC adopted the United States Core Data for Interoperability (USCDI) as a standard to replace the Common Clinical Data Set (CCDS) in several ONC
ONC also indicated in the ONC Cures Act Final Rule that we intended to establish and follow a predictable, transparent, and collaborative process to expand future versions of the USCDI, including providing the public with the opportunity to comment on the USCDI's expansion (85 FR 25670). ONC established a process, including creating the ONC New Data Element and Class (ONDEC) submission system,
Because USCDI is the standard for data required to be accessible through certified health IT for numerous certification criteria, expanding the data elements and data classes included in USCDI increases the amount of data available to be used and exchanged for patient care. To advance interoperability, in section III.C.1, ONC proposes to add the newly released USCDI v3 in § 170.213(b). We propose that USCDI v1 would remain in regulation and now be codified in § 170.213(a) and we propose to add USCDI v3 to § 170.213 (to be codified as § 170.213(b)). We also propose to incorporate by reference USCDI v3 in § 170.299 as of the effective date of the final rule. In addition, we propose that the USCDI v1 (July 2020 Errata) in the USCDI standard in § 170.213(a) will expire on January 1, 2025. Under this proposal, both versions would be referenced as applicable in the USCDI standard in § 170.213 for the time period up to and including December 31, 2024.
In section III.C.2, we propose to adopt the HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 3—US Realm (C-CDA Companion Guide R3) in § 170.205(a)(6). The C-CDA Companion Guide R3 provides supplemental guidance and additional technical clarification for specifying data in the C-CDA Release 2.1, including data specified in USCDI v2. However, it is our understanding that HL7 is working on updating the C-CDA Companion Guide for USCDI v3. If the updated C-CDA Companion Guide Release 4 (R4) is published before the date of publication of the final rule, it is our intention to consider adopting the updated Companion Guide that provides guidance and clarifications for specifying data in USCDI v3.
In the 2015 Edition Final Rule, we established a policy of adopting newer versions of “minimum standards” code sets that update frequently (80 FR 62612). Adopting newer versions of these code sets enables improved interoperability and implementation of health IT with minimal additional burden (77 FR 54170). If adopted, newer versions of these minimum standards code sets would serve as the baseline for certification, and developers of certified health IT would be able to use newer versions of these adopted standards on a voluntary basis. Because these code sets are updated frequently, we will consider whether it may be more appropriate to adopt a version of a minimum standards code set issued after publication of this proposed rule but before publication of a final rule. In section III.C.3, we propose to adopt newer versions of the following minimum standards code sets:
In addition to updating the minimum standards code sets listed above, we propose to update some of the certification criteria that reference those minimum standards. These criteria include § 170.315(a)(5)(i)(A)(
We also propose to change the heading of § 170.207(o) from “sexual orientation and gender identity” to “sexual orientation and gender information” to acknowledge that § 170.207(o) may include standard code sets to support other gender related data items.
In section III.C.4 of this proposed rule, we propose to revise the “transmission to public health agencies—electronic case reporting” criterion in § 170.315(f)(5) to adopt consensus-based, industry-developed electronic standards and implementation guides (IGs) to replace all functional, descriptive requirements in the present criterion in § 170.315(f)(5). These standards are proposed to support the following requirements for Health IT Modules certified to § 170.315(f)(5): (i) create a case report for electronic transmission; (ii) consume and process a case report response; and (iii) consume and process electronic case reporting trigger codes and parameters. We note that these electronic standards are standards-based representations of the functional requirements described in the existing criterion in § 170.315(f)(5) as described in section III.C.4 of this preamble.
In section III.C.5 of this proposed rule, we propose the certification criterion, “decision support interventions (DSI)” in § 170.315(b)(11). The DSI criterion is a revised certification criterion as it serves as both an iterative and replacement criterion for the “clinical decision support (CDS)” criterion in § 170.315(a)(9). This criterion would reflect an array of contemporary functionalities, data elements, and software applications, including the use of predictive models or algorithms, that certified Health IT Module(s) enable or interface with to aid decision-making in healthcare.
We propose to adopt a new definition for “predictive decision support intervention,” in § 170.102, and we propose that developers of certified health IT with Health IT Module(s) certified to the criterion we propose in § 170.315(b)(11) that enable or interface with predictive DSIs would be subject to requirements to provide transparency of predictive DSIs. Specifically, we propose that Health IT Modules that enable or interface with predictive DSIs enable a user to review predictive DSI “source attribute” information through the Health IT Module. We also propose that developers of certified health IT with Health IT Modules that enable or interface with predictive DSIs employ or engage in “intervention risk management” practices. We also propose that summary information regarding these intervention risk management practices be made available via a publicly accessible hyperlink. Together, our proposals for predictive DSI-specific source attributes and intervention risk management practices information are intended to provide appropriate information to help guide medical decisions at the time and place of care, consistent with 42 U.S.C. 300jj-11(b)(4).
We propose that Health IT Modules certified to § 170.315(b)(11) enable users to provide feedback regarding DSI information displayed through the Health IT Module, and that such Health IT Modules make available such feedback data for export in a computable format.
We propose that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) comply with these new requirements by December 31, 2024. For the intervening time between finalization of this proposed rule and December 31, 2024, we propose to add § 170.315(a)(9) to the list of applicable certification criteria for the real-world testing Condition and Maintenance of Certification requirement in § 170.405(a), thus requiring developers of certified health IT with Health IT Module(s) certified to § 170.315(a)(9) or § 170.315(b)(11) to participate in real world testing plan and results submission.
Finally, we propose to update the Base EHR definition in § 170.102 to include an option of either the existing “clinical decision support (CDS)” version of the criterion in § 170.315(a)(9) or the revised “decision support interventions” criterion in § 170.315(b)(11) for the period up to and including December 31, 2024, and to include only “decision support interventions” in § 170.315(b)(11) on and after January 1, 2025. We discuss in section III.C.5.d of this preamble proposals that would constitute changes to the CDS criterion, as the new DSI criterion. We describe how much of the structure and requirements are duplicated across these criteria and reflect the capabilities included in the CDS criterion with which Program participants have years of familiarity and can find, for comparison purposes, in § 170.315(a)(9).
We propose in section III.C.6 to remove the current named specification for clock synchronization, which is Network Time Protocol (NTP v4 of RFC 5905), in § 170.210(g), based on public feedback and reflective of contemporary norms within the industry. Additionally, we propose to keep the requirement for any network time protocol (NTP) standard to be present, though any NTP standard could be used.
We propose in section III.C.7 to revise the “standardized API for patient and population services” certification criterion in § 170.315(g)(10) in several ways. We propose to require a certified Health IT Module's authorization server to issue a refresh token according to the implementation specification adopted in § 170.215(c). The token should be valid for a period of no less than three months and will apply to all applications using the “confidential app” profile for both first time and subsequent connections.
We also propose to adopt the FHIR US Core Implementation Guide STU version 5.0.1 in § 170.215(b)(1)(ii). Based on the annual US Core release cycle, we believe US Core IG v6.0.0 will be published before ONC issues a final rule.
Additionally, we propose to amend the API Condition and Maintenance of Certification requirements by adding the requirement that Certified API Developers with patient-facing apps must publish their service base URLs for all customers, regardless of whether the certified Health IT Modules are centrally managed by the Certified API Developer or locally deployed by an API Information Source, according to a specified format.
We also propose to revise the requirement in § 170.315(g)(10)(vi) to specify that Health IT Modules presented for certification that allow short-lived access tokens to expire, in lieu of immediate access token revocation, must have such access tokens expire within one hour of the request. This revised requirement would align with industry standard practice for short-lived access tokens, would provide clarity and consistent expectations that developers revoke access or expire access privileges within one hour of a request, and would offer patients an assurance that an application's access to their data would be revoked or expired within one hour of a request.
We propose to adopt the Substitutable Medical Applications, Reusable Technologies (SMART) Application Launch Framework Implementation Guide Release 2.0.0 (SMART v2 Guide) in § 170.215(c)(2), which would replace SMART v1 Guide as the standard in § 170.215(a)(3) (proposed in this rule as § 170.215(c)(1)). The SMART v2 Guide iterates on the features of the SMART v1 Guide by including new features and technical revisions based on industry consensus, including features that reflect security best practices. We propose that the availability of the SMART v1 Guide to be adopted as a standard in the Program would expire on January 1, 2025. After this time, the SMART v2 Guide would be the only version of the IG available for use in the Program.
In section III.C.1 of this proposed rule, we introduce proposals to change certain data elements in USCDI, namely Sex (Assigned at Birth), Sexual Orientation, and Gender Identity, that are also data elements in § 170.315(a)(5). We propose these changes to reflect public feedback that the standards and terms used to represent these data elements needed to be updated. Therefore, to ensure consistency, in section III.C.8 of this preamble, we propose to change the name of the certification criterion in § 170.315(a)(5) from “demographics” to “patient demographics and observations.” Additionally, in order to ensure consistent capture of these data elements across health IT, we propose in section III.C.8 to carry these changes
We propose to replace the specific codes sets referenced in § 170.315(a)(5)(i)(D) and (E), Sexual Orientation and Gender Identity, respectively, with the Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) code set, as referenced in the standard proposed in § 170.207(o)(3). We propose that the adoption of the code sets referenced in § 170.207(n)(1) would expire on January 1, 2026, and we also propose that health IT developers can continue to use the specific codes in the current terminology standard until December 31, 2025, in order to provide adequate time for health IT systems to transition to the updated terminology standards.
As also discussed in section III.C.1 of this proposed rule, we have taken note of efforts to develop clinically relevant ways of identifying a patient's sex based on observations, to be used by a patient's clinician when considering or evaluating diagnostic or therapeutic services in areas such as radiology, laboratory, and genetic testing. The concept “Sex For Clinical Use” (SFCU) is seen as a valuable tool in addressing these concerns and therefore important for clinical capture. We also propose to add SFCU as a new data element in § 170.315(a)(5)(i)(F). Additionally, we propose to add new data elements “Name to Use” in § 170.315(a)(5)(i)(G) and “Pronouns” in § 170.315(a)(5)(i)(H), to facilitate data capture that supports providers' ability to provide culturally competent care for their patients.
We propose in section III.C.9 to update the “transitions of care” certification criterion (§ 170.315(b)(1)) to align it with changes proposed in § 170.213, including the proposed adoption of USCDI v3 in § 170.213(b)). This change would ensure that Health IT Modules certified to § 170.315(b)(1) are capable of accessing, exchanging, and using USCDI data elements referenced in § 170.213.
We believe that individuals should be provided a reasonable opportunity and technical capability to make informed decisions about the collection, use, and disclosure of their electronic health information. The Health Insurance Portability and Accountability Act (HIPAA)
We propose a new certification criterion in § 170.315(d)(14), an addition to ONC's Privacy and Security Certification Framework under the Program in § 170.550(h), and a revision to an existing criterion in § 170.315(e)(1) to support additional tools for implementing patient requested information privacy restrictions.
We propose to make explicit in the introductory text in § 170.315 that health IT developers voluntarily participating in the Program must update their certified Health IT Modules and provide that updated certified health IT to customers in accordance with the timelines defined for a specific criterion or standard included in § 170.315. More specifically, we propose in section III.C.11 that health IT developers with health IT certified to any of the certification criteria in § 170.315 would need to update their previously certified Health IT Modules to be compliant with any revised certification criterion adopted in § 170.315, including any new standards adopted in 45 CFR part 170 subpart B and capabilities included in the revised certification criterion. We further propose that health IT developers would also need to provide the updated heath IT to customers of the previously certified health IT according to the timelines established for that criterion and any applicable standards.
We propose in section III.D to establish additional Assurances Condition and Maintenance of Certification requirements. We propose as a Condition of Certification that a health IT developer must provide an assurance that it will not interfere with a customer's timely access to interoperable health IT certified under the Program. To support this assurance, we propose two accompanying Maintenance of Certification requirements. We propose that a health IT developer must update a Health IT Module, once certified to a certification criterion adopted in § 170.315, to all applicable revised certification criteria, including the most recently adopted capabilities and standards included in the revised certification criterion. We also propose that a health IT developer must provide all Health IT Modules certified to a revised certification criterion to its customers of such certified health IT. Additionally, we propose separate “timely access” or “timeliness” requirements for each of the two proposed Maintenance of Certification requirements above dictating by when a Health IT Module must be updated to revised certification criteria and by when a Health IT Module certified to a revised certification criterion must be provided to the health IT developer's customers.
Section 4002(a) of the Cures Act added a new Condition and Maintenance of Certification requirement that health IT developers must successfully test the real-world use of health IT for interoperability in the type(s) of setting(s) in which such technology would be marketed. Many health IT developers update their certified Health IT Module(s) on a regular basis leveraging the flexibility provided through ONC's Inherited Certified Status (ICS).
In order to ensure that all developers continue to test the real world use of their technology as required, we propose in section III.E to eliminate this anomaly by requiring health IT developers to include in their real world
The Cures Act specified requirements in section 4002(c) to establish an Electronic Health Record (EHR) Reporting Program to provide transparent reporting on certified health IT in the categories of interoperability, usability and user-centered design, security, conformance to certification testing, and other categories, as appropriate to measure the performance of EHR technology. The Cures Act also specified that a health IT developer be required, as a Condition and Maintenance of Certification requirement under the ONC Health IT Certification Program, to submit responses to reporting criteria in accordance with the Electronic Health Record Reporting Program established with respect to all certified technology offered by such developer. For clarity purposes, we intend to refer to the Condition and Maintenance of Certification associated with the “EHR Reporting Program” as the “Insights” Condition and Maintenance of Certification (also referred to as the “Insights Condition”) throughout this proposed rule. We believe this descriptive name captures the essence of this requirement and will help avoid confusion that might occur through use of the term “EHR Reporting Program.”
We propose in section III.F to adopt nine reporting measures for developers of certified health IT that focus initially on the interoperability category, emphasizing four areas of interoperability: individuals' access to electronic health information, public health information exchange, clinical care information exchange, and standards adoption and conformance. Through this first set of proposed measures, ONC intends to provide insights on the interoperability category specified in the Cures Act. We intend to explore the other Cures Act categories (security, usability and user-centered design, conformance to certification testing, and other categories to measure the performance of EHR technology) in future years.
We also propose in section III.F to implement the Insights Condition and Maintenance of Certification requirements in § 170.407 in two phases, where some of the measures will be required to be reported earlier than others. For each proposed measure, we have included information on the rationale for proposing the measure, the proposed numerators and denominators, and other key topics. Overall, the intent of the Insights Condition is to provide transparent reporting, address information gaps in the health IT marketplace, and provide insights on the use of health IT.
We propose in section IV.A to define what it means to “offer health information technology” or “offer health IT” for purposes of the information blocking regulations in 45 CFR part 171. This definition of what it means to
We also propose in section IV.A to modify the
We propose in section IV.A to revise the text of § 171.103, the information blocking definition, to remove paragraph (b) (
We note that we do not propose to change the scope of EHI for purposes of the information blocking definition, only to update the CFR text to remove the paragraph specific to the period of time now passed. Similarly, because we included the same time period in reference to the scope of electronic health information in two paragraphs of the Content and Manner exception (§ 171.301(a)(1) and (2)), we propose to revise § 171.301 to remove from the regulatory text the existing § 171.301(a)(1) and (2) as no longer necessary.
We propose in section IV.B to revise the Infeasibility Exception codified in 45 CFR 171.204(a) by adding two new conditions and by revising one existing condition to further clarify when an actor's practice of not fulfilling a request for access, exchange, or use of EHI meets the condition. First, we propose to revise the “uncontrollable events” condition in § 171.204(a)(1) to further
The first new infeasibility condition would apply to an actor's practice of denying a third party's request to enable use of EHI in order to modify EHI, including but not limited to creation and deletion functionality, provided the request is not from a health care provider requesting such use from an actor that is its business associate. The second new infeasibility condition would apply where an actor has exhausted the manner exception in § 171.301, including offering all alternative manners in accordance with § 171.301(b), and the actor does not currently provide a substantial number of individuals or entities similarly situated to the requestor with the same requested access, exchange, or use of the requested EHI.
We also seek comment on ways health IT can support EHI segmentation for access, exchange, and use of EHI; and particularly how the Program, through the certification of health IT to certain functionalities and/or standards, can support EHI segmentation for access, exchange, and use, including to assist health care providers with sharing EHI consistent with patient preferences and all laws applicable to the creation, use, and sharing of EHI.
Additionally, in section IV.B, we propose to add a Trusted Exchange Framework and Common Agreement (TEFCA) condition to the proposed revised and renamed Manner Exception, proposed to be codified in 45 CFR 171.301. This proposal aligns with a foundational policy construct underpinning the Manner Exception in that it facilitates an actor reaching agreeable terms with a requestor to fulfill an EHI request and acknowledges that certain agreements have been reached between these parties for the access, exchange, and use of EHI.
E.O. 12866 on Regulatory Planning and Review and E.O.13563 on Improving Regulation and Regulatory Review 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 that may: (1) have 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; (2) create a serious inconsistency or otherwise interfere with an action taken or planned by another agency; (3) materially alter the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raise 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 (RIA) must be prepared for major rules with significant effects as per section 3(f)(1)) ($100 million or more in any one year). OMB has determined that this proposed rule is a significant rule as the potential costs associated with this proposed rule could be greater than $100 million per year. Accordingly, we have prepared an RIA that to the best of our ability presents the costs and benefits of this proposed rule. We have estimated the potential monetary costs and benefits of this proposed rule for the health IT community, including costs and benefits as they relate to health IT developers, health care providers, patients, and the Federal Government (
We note that we have rounded all estimates to the nearest dollar and that all estimates are expressed in 2021 dollars as it is the most recent data available to address all cost and benefit estimates consistently. The wages used to derive the cost estimates are from the May 2021 National Occupational Employment and Wage Estimates reported by the U.S. Bureau of Labor Statistics.
We estimate that the total annual cost for this proposed rule for the first year after it is finalized (including one-time costs), based on the cost estimates outlined above and throughout this RIA, would result in $742 million. The total undiscounted perpetual cost over a 10-year period for this proposed rule (starting in year three), based on the cost estimates outlined above, would result in $712 million. We estimate the total costs to health IT developers to be $742 million and estimate the government (ONC) costs to be between $62,000 to $124,000.
We estimate the total annual benefit for this proposed rule, based on the benefit estimates outlined above, would be on average $1.0 billion. We estimate the total undiscounted perpetual annual net benefit for this proposed rule (starting in year three), based on the estimates outlined above, would be $326 million.
The Health Information Technology for Economic and Clinical Health Act (HITECH Act), Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act amended the Public Health Service Act (PHSA) and created “Title XXX—Health Information Technology and Quality” (Title XXX) to improve healthcare quality, safety, and efficiency through the promotion of health IT and electronic health information (EHI) exchange.
The 21st Century Cures Act, Public Law 114-255 (Cures Act), was enacted on December 13, 2016, to accelerate the discovery, development, and delivery of 21st century cures, and for other purposes. The Cures Act, through Title IV—Delivery, amended the HITECH Act by modifying or adding certain provisions to the PHSA relating to health IT.
Section 119 of Title I, Division CC of the Consolidated Appropriations Act, 2021, Public Law 116-260 (CAA), enacted on December 27, 2020, requires PDP sponsors of prescription drug plans to implement one or more real-time benefit tools (RTBTs) that meet the requirements described in the statute, after the Secretary has adopted a standard for RTBTs and at a time determined appropriate by the Secretary. For purposes of the requirement to implement a real-time benefit tool in section 1860D-4(o)(1) of the Social Security Act, described above, the CAA provides that one of the
The HITECH Act established two Federal advisory committees, the Health IT Policy Committee (HITPC) and the Health IT Standards Committee (HITSC). Each was responsible for advising the National Coordinator for Health Information Technology (National Coordinator) on different aspects of standards, implementation specifications, and certification criteria.
Section 4003(e) of the Cures Act amended sections 3002 and 3003 of the PHSA by replacing, in an amended section 3002, the HITPC and HITSC with one committee named the Health Information Technology Advisory Committee (Health IT Advisory Committee or HITAC). Section 3002(a) of the PHSA, as added by the Cures Act, establishes that the HITAC recommends to the National Coordinator policies and standards, implementation specifications, and certification criteria, relating to the implementation of a health information technology infrastructure, nationally and locally, that advances the electronic access, exchange, and use of health information. Further described in section 3002(b)(1) of the PHSA, this includes recommending to the National Coordinator a policy framework to advance interoperable health information technology infrastructure, updating recommendations to the policy framework, and making new recommendations, as appropriate. Section 3002(b)(2)(A) of the PHSA specifies that in general, the HITAC shall recommend to the National Coordinator for purposes of adoption under section 3004, standards, implementation specifications, and certification criteria and an order of priority for the development, harmonization, and recognition of such standards, specifications, and certification criteria. Like the process previously required of the former HITPC and HITSC, section 3002(b)(5) of the PHSA requires the HITAC to develop a schedule, updated annually, for the assessment of policy recommendations, which the Secretary publishes in the
Section 3004 of the PHSA establishes a process for the adoption of health IT standards, implementation specifications, and certification criteria and authorizes the Secretary to adopt such standards, implementation specifications, and certification criteria. As specified in section 3004(a)(1), the Secretary is required, in consultation with representatives of other relevant federal agencies, to jointly review standards, implementation specifications, and certification criteria endorsed by the National Coordinator under section 3001(c) and subsequently determine whether to propose the adoption of such standards, implementation specifications, or certification criteria. Section 3004(a)(3) requires the Secretary to publish all such determinations in the
Section 3004(b)(3) of the PHSA, titled, Subsequent Standards Activity, provides that the Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent with the schedule published by the HITAC. We consider this provision in the broader context of the HITECH Act and Cures Act to grant the Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITAC and endorsed by the National Coordinator, as well as other appropriate and necessary health IT standards, implementation specifications, and certification criteria.
Section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a certification program or programs for the voluntary certification of health IT. Section 3001(c)(5)(A) specifies that the National Coordinator, in consultation with the Director of the National Institute of Standards and Technology (NIST), shall keep or recognize a program or programs for the voluntary certification of health IT that is in compliance with applicable certification criteria adopted under section 3004 of the PHSA. The certification program(s) must also include, as appropriate, testing of the technology in accordance with section 13201(b) of the HITECH Act. Section 13201(b) of the HITECH Act requires that, with respect to the development of standards and implementation specifications, the Director of NIST shall support the establishment of a conformance testing infrastructure, including the development of technical test beds. Section 13201(b) also indicates that the development of this conformance testing infrastructure may include a program to accredit independent, non-federal laboratories to perform testing.
Section 4003(b) of the Cures Act added section 3001(c)(9)(B)(i) to the PHSA, which requires the National Coordinator “to convene appropriate public and private stakeholders” with the goal of developing or supporting a Trusted Exchange Framework and a Common Agreement (collectively, TEFCA) for the purpose of ensuring full network-to-network exchange of health information. Section 3001(c)(9)(B) outlines provisions related to the establishment of a Trusted Exchange Framework for trust policies and practices and a Common Agreement for exchange between health information networks (HINs)—including provisions for the National Coordinator, in collaboration with the NIST, to provide technical assistance on implementation and pilot testing of TEFCA. Section 3001(c)(9)(C) requires the National Coordinator to publish TEFCA on its website and in the
Section 4002(a) of the Cures Act amended section 3001(c)(5) of the PHSA by adding section 3001(c)(5)(D), which requires the Secretary, through notice and comment rulemaking, to require conditions of certification and maintenance of certification for the Program. Specifically, the health IT developers or entities with technology certified under the Program must, in order to maintain such certification status, adhere to certain conditions and maintenance of certification requirements concerning information blocking; assurances regarding appropriate exchange, access, and use of electronic health information; communications regarding health IT; application programing interfaces (APIs); real world testing; attestations regarding certain conditions and maintenance of certification requirements; and submission of reporting criteria under the EHR Reporting Program in accordance with section 3009A(b) of the PHSA.
The Secretary issued an interim final rule with request for comments on January 13, 2010, “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic
We have engaged in multiple rulemakings to update standards, implementation specifications, certification criteria, and the certification program, a history of which can be found in the October 16, 2015, final rule “2015 Edition Health Information (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications” (80 FR 62602) (2015 Edition Final Rule). The history can be found at 80 FR 62606. A correction notice was published for the 2015 Edition Final Rule on December 11, 2015 (80 FR 76868), to correct preamble and regulatory text errors and clarify requirements of the Common Clinical Data Set (CCDS), the 2015 Edition privacy and security certification framework, and the mandatory disclosures for health IT developers.
The 2015 Edition Final Rule established a new edition of certification criteria (“2015 Edition health IT certification criteria” or “2015 Edition”) and a new 2015 Edition Base EHR definition. The 2015 Edition established the minimum capabilities and specified the related minimum standards and implementation specifications that certified electronic health record technology (CEHRT) would need to include to support the achievement of “meaningful use” by eligible clinicians, eligible hospitals, and critical access hospitals under the Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs) (now referred to as the Promoting Interoperability (PI) Programs) when the 2015 Edition is required for use under these and other programs referencing the CEHRT definition. The final rule also adopted a proposal to change the Program's name to the “ONC Health IT Certification Program” from the ONC HIT Certification Program, modified the Program to make it more accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond the ambulatory and inpatient settings, and adopted new and revised Principles of Proper Conduct (PoPC) for ONC-Authorized Certification Bodies (ONC-ACBs).
After issuing a proposed rule on March 2, 2016, “ONC Health IT Certification Program: Enhanced Oversight and Accountability” (81 FR 11056), we published a final rule by the same title (81 FR 72404) (EOA Final Rule) on October 19, 2016. The EOA Final Rule finalized modifications and new requirements under the Program, including provisions related to our role in the Program. The final rule created a regulatory framework for our direct review of health IT certified under the Program, including, when necessary, requiring the correction of non-conformities found in health IT certified under the Program and suspending and terminating certifications issued to Complete EHRs and Health IT Modules. The final rule also set forth processes for us to authorize and oversee accredited testing laboratories under the Program. In addition, it included provisions for expanded public availability of certified health IT surveillance results.
On March 4, 2019, the Secretary published a proposed rule titled, “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (84 FR 7424) (ONC Cures Act Proposed Rule). The proposed rule proposed to implement certain provisions of the Cures Act that would advance interoperability and support the access, exchange, and use of electronic health information. We also requested comment in the ONC Cures Act Proposed Rule (84 FR 7467) as to whether certain health IT developers should be required to participate in TEFCA as a means of providing assurances to their customers and ONC that they are not taking actions that constitute information blocking or any other action that may inhibit the appropriate exchange, access, and use of EHI, with the goal of developing or supporting TEFCA for the purpose of ensuring full network-to-network exchange of health information.
On May 1, 2020, a final rule was published titled, “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (85 FR 25642) (ONC Cures Act Final Rule). This final rule implemented certain provisions of the Cures Act, including Conditions and Maintenance of Certification requirements for health information technology (health IT) developers, the voluntary certification of health IT for use by pediatric health providers, and reasonable and necessary activities that do not constitute information blocking. The final rule also implemented certain parts of the Cures Act to support patients' access to their EHI, and the implementation of information blocking policies that support patient electronic access. Additionally, the final rule modified the 2015 Edition health IT certification criteria and Program in other ways to advance interoperability, enhance health IT certification, and reduce burden and costs, as well as improving patient and health care provider access to EHI and promoting competition. On November 4, 2020, the Secretary published an interim final rule with comment period titled, “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency” (85 FR 70064) (Cures Act Interim Final Rule). The interim final rule extended certain compliance dates and timeframes adopted in the ONC Cures Act Final Rule to offer the healthcare system additional flexibilities in furnishing services to combat the COVID-19 pandemic, including extending the applicability date for information blocking provisions to April 5, 2021.
On January 19, 2022, we published a notice titled, “Notice of Publication of the Trusted Exchange Framework and Common Agreement” (87 FR 2800) (“TEFCA”). The notice fulfilled an obligation under section 3001(c)(9)(C) of the PHSA, which requires the National Coordinator for Health Information Technology to publish on the Office of the National Coordinator for Health Information Technology's public internet website, and in the
ONC first introduced the concept of an “edition” of ONC health IT certification criteria in 2012. In March 2012, in the 2014 Edition Proposed
We coined the “2011 Edition” and “2014 Edition” because the edition's name was designed to coincide with the first year in which compliance with that edition of certification criteria was required for use under the Medicare and Medicaid EHR Incentive Programs (79 FR 54431). We thought this approach would simplify communications related to the certification criteria editions and enable clear compliance statements like “an EP needs to be using 2014 Edition CEHRT when they demonstrate meaningful use . . . in CY 2014” (79 FR 54431). This approach resulted for many people in a direct, and limited in scope, link between certification criteria editions and “meaningful use” even though these certification criteria were already being referenced by other HHS programs (
In September 2014, we issued a final rule to update the 2014 Edition with “2014 Edition Release 2” certification criteria and to remove the 2011 Edition from the Code of Federal Regulations (CFR) starting in 2015 (79 FR 54430). At that time, EHR technology certified to the 2011 Edition had become outmoded, no longer met the CEHRT definition, and no longer supported an acceptable level of interoperability (79 FR 54447). Further, as referenced by OIG and CMS in the rulemakings completed by those agencies around donations of EHR items and services, we had planned to retire old or no longer applicable certification criteria editions ((78 FR 79205) and (78 FR 78754), respectively). During this same time period, we jointly issued with CMS a final rule (79 FR 52910) that allowed for continued use of 2011 Edition CEHRT in combination with 2014 Edition CEHRT within 2014, which allowed for certain providers to meet meaningful use requirements with EHRs certified to the 2011 or the 2014 Edition criteria, or a combination of both editions, for an EHR Reporting Period in 2014.
Accordingly, we set out to establish a simpler approach that could be used for future certification criteria editions. First, we intentionally adopted an overlapping transition period from any one edition to a subsequent edition (
Following this approach, in 2015, ONC issued a final rule, “2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications,” (2015 Edition Final Rule) and adopted the “2015 Edition Health IT Certification Criteria” (80 FR 62602). We codified the 2015 Edition certification criteria in § 170.315 to set them apart from other editions of certification criteria (80 FR 62608). Importantly, the program compliance requirements for certain health care providers to use 2015 Edition certified health IT was ultimately set by CMS to start in 2019 (83 FR 41144).
Four years later, as part of implementation of the 21st Century Cures Act, we issued the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Proposed Rule (84 FR 7424) to update to the 2015 Edition, mindful that 2015 Edition certified health IT was just being implemented. In 2020, we published the ONC Cures Act Final Rule (85 FR 25642) and adopted updates to the 2015 Edition. These updates included new certification criteria, standards, and requirements, as well as incremental revisions to existing 2015 Edition certification criteria to better enable interoperability and the access, exchange, and use of EHI (85 FR 25664-65). Because we did not adopt a new edition of certification criteria in a different CFR section, we retained the overall 2015 Edition title for the changes included in the ONC Cures Act Final Rule and made specific timebound compliance changes within certification criteria.
In the final rule, we stated that we considered a variety of factors when we determined to update the 2015 Edition rather than adopt a new “edition.” First, we reviewed the scope of each proposed update and the cumulative scope of the proposals overall for health IT developers and sought to identify whether it would be more appropriate to require health IT developers participating in the Program to implement updates to Health IT Modules certified to the 2015 Edition or to test and certify health IT products to an entirely new edition of certification criteria. Second, we considered the impact that either approach would have on health care providers, including how such updated Health IT Modules or products certified to a new edition would be implemented by providers participating in CMS programs. We also noted that historically, with a new edition of certification criteria, health IT developers have packaged Health IT Modules certified to new, revised, and unchanged criteria into a wholly new certified product. We observed that historical data indicated that these complete updates to the edition were particularly challenging for both health IT developers seeking certification and for health care providers as they establish deadlines for a significant number of health IT developers to support and implement new products for a significant number of health care providers simultaneously. As a result, the burden of updating the technology is compounded for both health IT developers and health care providers (85 FR 25665).
Our intent with this approach was to maintain a single set of certification criteria that have been updated to include the most recent versions of adopted standards, and to establish an incremental approach to health IT updates over time. In the ONC Cures Act Final Rule, we stated our belief that this approach should also include development timelines based on the updates required for each criterion and a transition period allowing for multiple standards to be used for a reasonable period of time. We noted our belief that, as a whole, this approach can help to reduce the burden on health IT developers and health care providers and could allow health IT developers to implement updates in the manner most appropriate for their product and their customers (85 FR 25665). Commenters noted this approach would provide stability and that an incremental approach best serves the health care provider and health IT developer community (85 FR 25664).
However, in response to public comment related to how we communicate and avoid public confusion (85 FR 25666), we distinguished the “original” 2015 Edition certification criteria from the new and revised 2015 Edition certification criteria by referring to the updates we adopted as the 2015 Edition “Cures Update” certification criteria. Subsequent to publication of the final rule, through public meetings and correspondence, we have been informed that the continued use and reference to the 2015 Edition inaccurately implied an age and outdatedness to the certification criteria we had adopted. More importantly, we have received significant positive feedback expressing that the incremental approach to updates is generally beneficial as a long-term approach. Specifically, feedback conveyed that a consistent, transparent, incremental update cycle that includes the following features would be preferred by some: (1) regular updates to recognize standards advancement and an allowance for voluntary standards advancement between updates, (2) incremental updates rather than “wholesale” product overhauls, (3) a predictable timeline for updates based on standards development cycles with reasonable development timelines, and (4) a reasonable development timeline for any new criterion based on the specific development needs.
For these reasons, we no longer believe that it is helpful or necessary to maintain an “edition” naming convention and to adopt entirely new editions of certification criteria to encapsulate updates over time. Instead, we believe that there should be a single set of certification criteria, which would be updated in an incremental fashion in closer alignment to standards development cycles and regular health IT development timelines. We therefore propose to rename all certification criteria within the Program simply as “ONC Certification Criteria for Health IT.” We believe maintaining a single set of “ONC Certification Criteria for Health IT” would create more stability for users of health IT and Program partners, such as CMS, as well as make it easier for developers of certified health IT to maintain their product certificates over time. In addition, we believe that this approach will have the benefit of reducing administrative burden for health IT developers participating in the Program. Previously, duplicative references to separate certification criteria under multiple year-themed editions created administrative burden on developers, as they had the effect of requiring health IT developers to seek an updated certificate attributed to the “new” duplicated certification criterion even in circumstances when the certification criterion remained substantively unchanged. Under this proposal, unchanged certification criteria would no longer be duplicated as separate criteria under multiple editions. Accordingly, we propose to rename § 170.315 as the “ONC Certification Criteria for Health IT” and replace all references throughout 45 CFR part 170 to the “2015 Edition” with this new description (this would impact the wording, though not the substance or effect, of §§ 170.102, 170.405, 170.406, 170.523, 170.524, and 170.550, as shown in proposed revised regulation text, below). We welcome public comment on this proposal.
In the 2014 Edition Final Rule we defined the terms “new,” “revised,” and “unchanged” to both describe the differences between the 2014 Edition certification criteria and the 2011 Edition certification criteria, as well as establish what certification criteria in the 2014 Edition were eligible for gap certification
(1) All applicable new and/or revised certification criteria adopted by the Secretary at subpart C of this
(2) All other applicable certification criteria adopted by the Secretary at subpart C of this part based on the test results used to previously certify the Complete EHR or Health IT Module(s) under the ONC Health IT Certification Program (§ 170.502).
• “New” certification criteria are those that as a whole only include capabilities never referenced in previously adopted certification criteria editions and to which a Health IT Module presented for certification to the 2015 Edition could have never previously been certified.
• “Revised” certification criteria are those that include the capabilities referenced in a previously adopted edition of certification criteria as well as changed or additional new capabilities; and to which a Health IT Module presented for certification to the 2015 Edition could not have been previously certified to all of the included capabilities.
• “Unchanged” certification criteria are those that include the same capabilities as compared to prior certification criteria of adopted editions; and to which a Health IT Module presented for certification to the 2015 Edition could have been previously certified to all of the included capabilities (80 FR 62608).
We propose that these same concepts as applied to the certification criteria would continue to be used by the Program in the absence of a year named “edition.” However, for clarity, we now propose to define “revised certification criterion (or criteria)” in § 170.102 to mean a certification criterion that meets at least one of the following: (1) has added or changed the functions or capabilities described in the existing criterion in 45 CFR 170 part C; (2) has an added or changed standard or implementation specification referenced in the existing criterion in 45 CFR part 170 subpart B; or (3) is specified through notice and comment rulemaking as an iterative or replacement version of an existing criterion in 45 CFR part 170 subpart C.
By way of example, proposed provisions (1) and (2) were met in § 170.315(b)(3) in the ONC Cures Act Final Rule (85 FR 25683) because we modified this criterion to include new functions or capabilities in § 170.315(b)(3)(ii)(A)(
We would continue to use these terms when: communicating proposals for future criteria, such as revising a criterion that will maintain its place in the CFR or establishing a new criterion that is an iterative or replacement criterion in the Program; establishing scenarios for when gap certification is an option for developers of certified health IT; and when setting expiration dates or applicable timelines related to standards and certification criteria. Through the development of educational resources, such as fact sheets
We propose the following revised standards and implementation specifications: § 170.205(a); §§ 170.207(a), (c), (d), (e), (f), (m), (n), (o), (p), (r), and (s); § 170.210(g); § 170.213; § 170.215(b), and § 170.215(c). We propose new standards and implementation specifications in § 170.205(t) and § 170.205(o). Table 1 below includes the proposed new and revised certification criteria described in this rule.
When we published the 2015 Edition Final Rule, ONC released educational resources to inform the public. Educational and communication resources included charts on the 2015 Edition certification criteria, reader-friendly fact sheets on specific topics like addressing health disparities and patient engagement, the Companion Certification Guides, and a new “2015 Edition Standards Hub” to help interested parties quickly crosswalk and identify standards referenced by 2015 Edition certification criteria. While our proposal may have the near-term effect of requiring ONC to revise existing communications materials, as well as conforming regulatory updates and updates to materials by other agencies such as CMS that reference the 2015 Edition, we believe the overall benefit of having a single ONC branded set of certification criteria outweighs the burdens that result administratively, as well as for developers of certified health IT and their customers, from rolling out a new “edition.” Moreover, starting with the ONC Cures Act Final Rule, we developed a new approach for conformance requirement changes within certification criteria that, when applied in conjunction with this proposed approach, can also reduce administrative and regulatory burden and help to ensure the updates to criteria are clearly defined to support both a transition period and a predictable development timeline aligned to the scope of the specific update. In the ONC Cures Act Final Rule, we did not create a new CFR section as we had done previously but instead updated the existing CFR section, § 170.315. The new approach was designed to make it clear for health IT developers, as well as ONC-Authorized Testing Labs (ONC-ATLs) and ONC-ACBs, how long certain capabilities and standards remain available for the purposes of certification. We also implemented new Maintenance of Certification requirements as a result of the Cures Act to give health IT developers specific deadlines relative to complying with updated technical requirements, while still allowing developers to continue supporting technology certified to the prior version of certification criteria or standards for use by their customers.
Building upon this approach, in this proposed rule, we also propose modifications to our approach for setting applicability or implementation timelines for both our certification criteria and the standards adopted in 45 CFR part 170. This approach includes establishing the dates by which an existing version of a certification criterion is no longer applicable because a new or revised version of that criterion is adopted. In addition, we have proposed to establish applicable timelines, including expiration dates, for the adoption of standards when a new or revised version of the standard is adopted for the same purpose. This proposed approach would support the ongoing establishment of clear timelines associated with the specific criterion or standard in alignment with the development and update cycle for that specific criterion or standard—again supporting an incremental and flexible approach.
In addition, we believe this approach would facilitate ease of reference for federal, state, local or tribal programs seeking to align their program requirements to the standards and implementation specifications available in certified health IT. These programs may not require use of the entirety of the Base EHR, or they may not even require the use of certified health IT, but they may still seek to align to a specific certification criterion or a specific standard where applicable to their program goals and consistent with their applicable authorities. Furthermore, as we move away from the use of editions to define updated timelines, we believe it is important to continue to provide clarity on existing Program requirements and to ensure that customers are provided with timely technology updates. We therefore propose to incorporate the applicable timelines and expiration dates for functional and standards updates within each individual criterion or standard. In section III.C.11 of this proposed rule, we propose to make explicit in the introductory text in § 170.315 that health IT developers voluntarily participating in the Program must update their certified Health IT Modules and provide that updated certified health IT to customers in accordance with the timelines defined for each criterion and standard if they intend to maintain certification of the Health IT Module. (For ease of reference and reading, we use “developer of certified health IT” in this proposed rule to reference developers who voluntarily participate in the Program). We believe this approach will also help to advance interoperability. Under this proposal, a developer of certified health IT would not be required to provide technology updates for certification criteria or standards to a user who declined such updates. However, we note that if such an update is not provided, and the Health IT Module was previously certified to a criterion or criteria that now make it subject to a “revised” criterion or criteria, the Health IT Module would no longer be certified under the Program, in the same manner that previously removed or expired “editions” are no longer certified under the Program.
We direct readers to section III.C.11 of this proposed rule for further discussion of the requirements for health IT developers voluntarily participating in the Program related to health IT certification updates.
In the ONC Cures Act Final Rule, we revised the Principles of Proper Conduct for ONC-ACBs and ONC-ATLs by revising the records retention policies to include the “life of the edition” (85 FR 25710 through 25713). Specifically, we clarified that the records retention provisions in §§ 170.523 and 170.524 included the “life of the edition” as well as three years after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules. We explained that “[b]ecause the `life of the edition' begins with the codification of an edition of certification criteria in the CFR and ends on the effective date of the final rule that removes the applicable edition from the CFR, the start and end dates for the `life of the edition' are published in the
The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701
• The United States Core Data for Interoperability (USCDI), October 2022 Errata, Version 3 (v3) standard. We propose to adopt USCDI v3 (October 2022 Errata) in § 170.213. This standard is a hybrid of government policy (
• The standard we propose to adopt in § 170.207(f)(3) for race and ethnicity.
We are not aware of any voluntary consensus standards that could serve as an alternative for the purposes we describe in further detail throughout this proposed rule including establishing a baseline set of data that can be commonly exchanged across care settings for a wide range of uses. We refer readers to section III.C.1 of this preamble for a discussion of the USCDI.
In accordance with Office of the Federal Register regulations related to “incorporation by reference,” 1 CFR part 51, which we follow when we adopt proposed standards and/or implementation specifications in any subsequent final rule, the entire standard or implementation specification document is deemed published in the
The Office of the Federal Register has established requirements for materials (
The United States Core Data for Interoperability (USCDI) is a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange.
USCDI v1 established a baseline set of data that can be commonly exchanged across care settings for a wide range of uses and is a required part of certain certification criteria in the 2015 Edition Cures Update. These certification criteria include transitions of care; clinical information reconciliation and incorporation; view, download, and
ONC stated in the ONC Cures Act Final Rule that we intended to utilize a predictable, transparent, and collaborative process to expand USCDI, including providing the public with the opportunity to comment on USCDI's expansion (85 FR 25670). We also noted that health IT developers would be able to use the Standards Version Advancement Process (SVAP) to voluntarily implement and use a newer, National Coordinator-approved version of USCDI in the future without waiting for ONC to propose and adopt via rulemaking an updated version of the USCDI (85 FR 25669). ONC, therefore, established a process for expanding USCDI based on public input and submissions of new data elements and classes.
ONC has received several hundred submissions through ONDEC recommending new and updated data classes and data elements during each annual update cycle. In July 2021, ONC published USCDI Version 2 (USCDI v2),
We propose to update the USCDI standard in § 170.213 by adding the newly released USCDI v3 and by establishing a January 1, 2025, expiration date for USCDI v1 (July 2020 Errata) for purposes of the Program. We propose to add USCDI v3 in § 170.213(b) and incorporate it by reference in § 170.299. Specifically, USCDI v3 in this proposed rule refers to the USCDI v3 (October 2022 Errata). We propose to codify the existing reference to USCDI v1 (July 2020 Errata) in § 170.213(a). We propose that as of January 1, 2025, any Health IT Modules seeking certification for criteria referencing § 170.213 would need to be capable of exchanging the data classes and data elements that comprise USCDI v3.
The USCDI standard is currently cross-referenced, via cross-reference to § 170.213, in certain certification criteria. A Health IT Module could currently be certified to any of these criteria by ensuring that it complies with either the USCDI v1 or USCDI v2 standards, since USCDI v2 is approved for SVAP. Should we adopt our proposal to add the USCDI v3 in § 170.213, Health IT Modules certified to these criteria that cross-reference § 170.213 could also be certified by meeting the USCDI v3 standard. Through December 31, 2024, we propose that a Health IT Module certified to criteria that cross-reference § 170.213 may be certified by complying with (1) USCDI v1; (2) USCDI v2 under SVAP; and (3) USCDI v3. We propose to allow only USCDI v3 after this date for the criteria that cross-reference § 170.213. The criteria cross-referencing to USCDI via cross-reference to § 170.213 are as follows:
• “Care coordination—Transitions of care—Create” (§ 170.315(b)(1)(iii)(A)(
• “Care coordination—Clinical information reconciliation and incorporation—Reconciliation” (§ 170.315(b)(2)(iii)(D)(
• “Patient engagement—View, download, and transmit to 3rd party—View” (§ 170.315(e)(1)(i)(A)(
• “Design and performance—Consolidated CDA creation performance” (§ 170.315(g)(6)(i)(A));
• “Design and performance—Application access—all data request—Functional requirements” (§ 170.315(g)(9)(i)(A)(
• “Design and performance—Standardized API for patient and population services—Data response” (§ 170.315(g)(10)(i)(A) and (B)).
We note that § 170.315(f)(5) also currently references § 170.213. However, as discussed later in this preamble, we propose to rely on specific
As noted previously, a developer of certified health IT would not be required to provide technology updates for certified criteria or standards to a user who declined such updates. However, we note that if such an update is not provided, even if the version of the Health IT Module in use still operates, that version would no longer be considered certified. This means that it may no longer meet the requirements of HHS programs requiring the use of certified health IT.
We propose to add introductory text to § 170.213 noting that the Secretary adopts the following standards as the standards available for the purpose of representing electronic health information, and we also propose to include the date the adoption of the standard in § 170.213(a) expires. Consistent with our proposals in sections III.A and III.C.11, we propose this expiration date to be January 1, 2025. Health IT developers with Health IT Modules certified to certification criteria that reference § 170.213 would have to update such certified health IT to USCDI v3 and provide it to customers by December 31, 2024. Further, we propose that Health IT Modules certified to the above-listed certification criteria would need to update their Health IT Modules to accommodate USCDI v3 data elements using the FHIR US Core Implementation Guide Version 5.0.1 in § 170.215(b)(1)(ii) and the HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 in § 170.205(a)(6). If the FHIR US Core Implementation Guide and the HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide are updated before the date of publication of the final rule, it is our intent to consider adopting the updated versions that support USCDI v3.
We clarify that under this proposal, for the time period up to and including December 31, 2024, USCDI v1 would remain applicable as the minimum version of the USCDI required for certification criteria that reference § 170.213. This means that upon the effective date of a rule finalizing this proposal, for the identified certification criteria that reference § 170.213, the following would apply as available versions of USCDI for certification and compliance:
• USCDI v1 (2020 Errata) for the time period up to and including December 31, 2024 (the adoption of the standard expires on January 1, 2025),
• USCDI v3.
We refer to the term “expires” in standards throughout this proposed rule, and it would mean that the Secretary no longer recognizes the standard in the Code of Federal Regulations and its use for purposes of the Program is no longer available.
USCDI v2 would remain available via SVAP for developers of certified health IT who want to voluntarily update their Health IT Modules, or for developers of certified health IT who want to certify to applicable criteria in addition to or instead of USCDI v1 up to and including December 31, 2024.
Additionally, because we finalized in the ONC Cures Act Final Rule that the Common Clinical Data Set (CCDS) would no longer be applicable for certified Health IT Modules 24 months after the publication date of the ONC Cures Act Final Rule (85 FR 25671), and then extended that date to December 31, 2022 in the interim final rule titled “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency” (85 FR 70073), we propose to remove references to CCDS in the following sections of 45 CFR 170.315: § 170.315(b)(1)(iii)(A)(
ONC proposes to update the USCDI standard in § 170.213 by proposing a January 1, 2025 expiration date for USCDI v1 (July 2020 Errata) and by adding the newly released USCDI v3 (October 2022 Errata). ONC proposes to incorporate USCDI v3 by reference in § 170.299. USCDI v3 includes all data elements defined in USCDI v1 and USCDI v2, and includes additional data elements added in USCDI v3.
Adopting USCDI v3 would provide more comprehensive health data for providers and patients accessing and exchanging electronic health information. USCDI v3 includes Sexual Orientation, Gender Identity, Functional Status, Disability Status, Mental/Cognitive Status, and Social Determinants of Health data elements including: SDOH Assessment, SDOH Goals, SDOH Interventions, and SDOH Problems/Health Concerns. Access, exchange, and use of these data elements can support more informed care for patients. These data elements are described in more detail below.
While the SVAP process provides an opportunity for health IT developers to voluntarily update their certified products to newer versions of USCDI, setting a new USCDI v3 floor for all certified health IT that includes Health IT Modules certified to certification criteria that reference § 170.213 would enable a more consistent adoption of an expanded baseline set of data, realizing the benefits described above. We propose to add USCDI v3 to § 170.213 in addition to USCDI v1 (July 2020 Errata). Because USCDI v1 (July 2020 Errata) may be used for the time period up to and including December 31, 2024, we propose to amend § 170.213 to include paragraph (a) that will note that the USCDI v1 (July 2020 Errata) standard will expire on January 1, 2025, and paragraph (b) that will note the addition of USCDI v3.
Below, we describe the data classes and data elements in USCDI v3 that are not included in USCDI v1. We also describe any data classes or data elements that were changed through the USCDI update processes when comparing USCDI v3 to USCDI v1. For the overall structure and organization of the USCDI standard, including USCDI v3, we urge the public to consult
SDOH
SDOH data are often categorized into domains based on the type of circumstances they are intended to represent, such as food or housing insecurity. However, many of these circumstances overlap, and there are continuing efforts aiming to capture additional areas of focus such as broadband access or environmental risk factors.
USCDI v3 includes four SDOH data elements that represent specific aspects of SDOH data related to the use or purpose of the SDOH data rather than based on the domain. In this way, the data elements can emphasize the use case aspect of the data and expand to additional domains over time. These data elements are new for USCDI v3 as compared to USCDI v1. However, because each of these aspects is closely related to data elements that exist in USCDI data classes, these new data elements were organized into the applicable existing data classes.
In USCDI v1, the Care Team Member data class had one data element to capture all aspects about a care team member. ONC received submissions recommending the addition of more granular data elements that provide greater detail around a patient's health care provider and other members of the care team. USCDI v3 includes five Care Team Member data elements: Name, Identifier, Role, Location, and Telecom.
For the data element Discharge Summary Note in the Clinical Notes data class, we specified additional requirements in USCDI v3 including admission and discharge dates and locations, discharge instructions, and reason(s) for hospitalization, which are also required elements in the Transitions of Care certification criterion (§ 170.315(b)(1)).
USCDI v3 includes a data class for Clinical Tests, which has two data elements, Clinical Test and Clinical Test Result/Report. This is a new data class as compared to USCDI v1. These elements will enable the capture and exchange of non-imaging and non-laboratory tests. Some examples include electrocardiogram (ECG), visual acuity exam, macular (ophthalmic) exam, or graded exercise testing (GXT). These tests are routinely performed on patients and result in structured or unstructured (narrative) findings that facilitate the diagnosis and management of a patient's condition(s).
USCDI v3 includes the Diagnostic Imaging data class and its two elements: Diagnostic Imaging Test and Diagnostic Imaging Report. This is a new data class as compared to USCDI v1. These data elements added a critical missing capability of health IT to capture and exchange structured and unstructured imaging test and report data for a patient.
USCDI v3 includes the Encounter Information data class, which includes five data elements: Encounter Type, Encounter Diagnosis, Encounter Time, Encounter Location, and Encounter Disposition. This is a new data class as compared to USCDI v1.
USCDI v3 includes the Health Insurance Information data class, which provides an opportunity for health IT to capture and exchange key elements of healthcare insurance coverage. This information can be useful for patient matching and record linkage, coverage determination, prior authorization, price transparency, claims and reimbursement efficiencies, and identifying disparities related to insurance coverage. This is a new data class as compared to USCDI v1. This data class includes seven data elements: Coverage Status, Coverage Type, Relationship to Subscriber, Member Identifier, Subscriber Identifier, Group Identifier, and Payer Identifier.
USCDI v3 includes a data class called Health Status Assessments, which contains four new data elements: Disability Status, Mental/Cognitive Status, Functional Status, and Pregnancy Status. This is a new data class as compared to USCDI v1. In USCDI v3, the Health Status Assessments data class also includes two data elements that have been recategorized, Health Concerns and Smoking Status, which were previously part of different data classes in USCDI. The Health Status Assessments data class provides a broader context for these data elements. The ability to capture and exchange data that represent the assessment performed and the assessment component results helps health care providers address inequities by being able to readily identify and address a patient's conditions characterized with these data.
USCDI v3 includes Specimen Type and Result Status data elements, which
USCDI v3 includes Dose, Dose Units of Measure, Indication, and Fill Status data elements, which have been added to the USCDI Medications data class in response to public feedback and because these data elements are necessary for certain CMS reporting programs and are also critical to certain ONC certification criteria (including the electronic prescribing certification criterion at § 170.315(b)(3)).
Based on submissions and comments during the USCDI update processes described above, ONC changed or added data elements in the Patient Demographics/Information data class.
USCDI v3 includes data elements Sexual Orientation and Gender Identity, which have been added to the USCDI Patient Demographics/Information data class. Previously, ONC adopted standards for Sexual Orientation in the demographics criterion in § 170.315(a)(5)(i)(D) and for Gender Identity in the demographics criterion in § 170.315(a)(5)(i)(E). These criteria include requirements to code Sexual Orientation and Gender Identity according to the adopted SNOMED CT® codes and HL7 Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor as referenced § 170.207(o)(1) and § 170.207(o)(2), respectively.
These codes reflect an attempt to exchange data regarding Sexual Orientation and Gender Identity in a consistent manner. Public feedback has, however, indicated that the required SNOMED CT® codes do not appropriately and accurately capture all applicable sexual orientations or gender identities. We also understand that the existing standards reference specific codes from the HL7 Version 3 Standard, Value Set for NullFlavor, which are primarily used by health IT developers to indicate when there is not information available to represent Sexual Orientation or Gender Identity. The HL7 Gender Harmony Project has developed an informative document
Accordingly, we propose to remove the requirement to use specific codes for representing Sexual Orientation and Gender Identity and have removed the codes as applicable vocabulary standards from USCDI v3. Rather, to continue to promote interoperability while also providing health care providers with flexibility to better support clinical care, certified health IT with Health IT Modules certified to criteria that reference § 170.213 would be required to be capable of representing Sexual Orientation and Gender Identity in SNOMED CT® when such information is exchanged as part of USCDI. We believe that it is best to let the health IT community develop the list of appropriate values for Sexual Orientation and Gender Identity, whether through implementation specifications or developing additional codes in SNOMED CT®.
We received strong support from commenters in response to our request during the Draft USCDI v3 public feedback period that the USCDI term Sex (Assigned at Birth) was too limiting for the industry. In subsequent exploration and analysis, we learned that this element is represented in different ways in a number of jurisdictions, so the meaning is unclear.
There was support to align the term in USCDI with the term Recorded Sex or Gender as part of the Gender Harmony Project. We understand that the term Recorded Sex or Gender is a more expansive term that defines the value of patient's sex recorded in administrative or legal documents, and indeed Sex (Assigned at Birth) could be considered as a specific type or recorded value with the identifier being assigned at birth. However, in order to be least disruptive to the industry, while at the same time, acknowledging the shortcomings of our current term, we have recharacterized the USCDI data element Sex (Assigned at Birth) to Sex. We note that this is presently a change in the name of the element and will have no immediate impact on health IT developers of certified health IT, which will continue to exchange the value of patient's sex they have been historically exchanging using USCDI. However, we anticipate this change to support future enhancements to improve precision in the meaning through work done by health IT developers of certified health IT.
USCDI v3 does not require the use of certain specific codes for representing Sex. As discussed previously, we propose to remove the requirement in § 170.315(a)(5)(i)(C) and § 170.315(b)(1)(iii)(G)(
Finally, we have taken note of the substantial effort in this area to develop a clinically meaningful way for identifying a patient's sex from observable information (
ONC also sought feedback on the value of adoption of an applicable vocabulary standard for patient addresses.
USCDI v3 includes six data elements added to the prior USCDI Patient Demographics/Information data class: Related Person's Name, Related Person's Relationship, Date of Death, Occupation, Occupation Industry, and Tribal Affiliation. Related Person's Name and Related Person's Relationship enable linkages between maternal and child records as well as identifying and linking other related persons, such as custodians and guardians. Date of Death supports patient matching, adverse event, public health, and vital records reporting. Occupation and Occupation Industry data elements were added to support public health, and to capture military service. Finally, Tribal Affiliation is captured by the Indian Health Service (IHS), an agency within the Department of Health and Human Services, to aid in the determination of eligibility for IHS services, care-coordination with non-tribal medical facilities, and identification of disparities in healthcare in and across American Indian and Alaska Native populations.
As discussed in sub-section i of this section, USCDI v3 includes the SDOH Problems/Health Concerns data element added to the prior USCDI Problems data class. In addition, USCDI v3 includes Date of Diagnosis and Date of Resolution data elements added to the prior USCDI Problems data class to include timing elements for recorded and maintained problem lists within electronic health records.
USCDI v3 includes the Reason for Referral data element added to the prior USCDI Procedures data class. This data element is already part of the Program requirements for the transitions of care certification criterion (§ 170.315(b)(1)(iii)(E)) in the ambulatory setting and is broadly implemented in health IT. As discussed in sub-section i of this section, the USCDI v3 also includes the SDOH Interventions data element added to the prior USCDI Procedures data class.
In the 2015 Edition Final Rule, we established a policy for minimum standards code sets that update frequently throughout a calendar year at 80 FR 62612, and we have listed several standards as minimum standards code sets in 45 CFR part 170 subpart B. As with all adopted minimum standards code sets, health IT can be certified to newer versions of the adopted baseline version minimum standards code sets for purposes of certification, unless the Secretary specifically prohibits the use of a newer version (see § 170.555 and 77 FR 54268). In USCDI v3, we included the most recent versions of the minimum standards code sets.
We propose to adopt the HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 3—US Realm in § 170.205(a)(6) (“C-CDA Companion Guide R3”). The C-CDA Companion Guide R3 provides supplemental guidance and additional technical clarification for specifying data in the C-CDA Release 2.1 for USCDI v2. However, it is our understanding that HL7 is working on updating the C-CDA R2.1 Companion Guide (Release 4) for USCDI v3. If the C-CDA Companion Guide Release 4 (R4) is published before the date of publication of the final rule, it is our intention to consider adopting the updated Companion Guide R4 that provides guidance and clarifications for specifying data in USCDI v3 since we propose to adopt USCDI v3 as the baseline in this proposed rule.
As mentioned above, HL7® has been updating the C-CDA Companion Guide to accommodate the new data classes and elements in each USCDI version. To allow developers to voluntarily update to USCDI v2, ONC included the C-CDA Companion Guide R3 in the SVAP Approved Standards List for 2022. ONC released the SVAP Approved Standards List for 2022 in June 2022. We anticipate that the C-CDA Companion Guide R4 would support updates included in proposed USCDI v3. We note that the adoption of the C-CDA Companion Guide R4 would align with our goal to increase the use of consistently implemented standards among health IT developers and improve interoperability. We propose to adopt the C-CDA Companion Guide R3 as a standard in § 170.205(a)(6) and incorporate it by reference in § 170.299. As stated above, if the C-CDA Companion Guide R4 is available at the time of publication of the final rule, we intend to consider adopting the C-CDA Companion Guide R4, which would support the updates included in proposed USCDI v3.
Consistent with our proposals in sections III.A and III.C.11, we propose to revise § 170.205(a)(5) to add that the adoption of the standard in § 170.205(a)(5) expires on January 1, 2025. Developers of certified health IT with Health IT Modules certified to criteria that reference § 170.205(a)(5) would have to update those Health IT Modules to § 170.205(a)(6) and provide them to customers by January 1, 2025. We clarify that under this proposal, for the time period up to and including December 31, 2024, HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 would remain applicable as the minimum version required in the Program. This means that upon the effective date of a final rule, for the identified certification criteria, the following would apply as the minimum version for C-CDA for certification and compliance:
• HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 (incorporated by reference in § 170.299) for the time period up to and including December 31, 2024,
• HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3.
Further, we propose that Health IT Modules certified to the certification criteria below would need to update to the HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 in § 170.205(a)(6) by January 1, 2025:
• “transitions of care” (§ 170.315(b)(1)(iii)(A));
• “clinical information reconciliation and incorporation” (§ 170.315(b)(2)(i), (ii), and (iv));
• “care plan” (§ 170.315(b)(9)(ii));
• “view, download, and transmit to 3rd party” (§ 170.315(e)(1)(i)(A) and (B));
• “consolidated CDA creation performance” (§ 170.315(g)(6)(i)); and
• “application access—all data request” (§ 170.315(g)(9)(i)).
For the purposes of meeting that compliance timeline, we expect health IT developers to update their certified health IT without new mandatory testing and notify their ONC-ACB on the date at which they have reached compliance. Developers would also need to factor these updates into their next real world testing plan.
We established a policy in the 2015 Edition Final Rule for minimum standards code sets that update frequently (80 FR 62612). In prior rulemaking, we discussed the benefits of adopting newer versions of minimum standards code sets, including the improved interoperability and implementation of health IT with minimal additional burden (77 FR 54170). When determining whether to propose newer versions of minimum standards code sets, we consider the impact on interoperability and whether a newer version would require substantive effort for developers of certified health IT to implement. If adopted, newer versions of minimum standards code sets would serve as the baseline for certification and developers of certified health IT would be able to use newer versions of these adopted standards on a voluntary basis. We reiterate that while minimum standard code sets update frequently, perhaps several times in a single year, these updates are confined to concepts within the code system, not substantive changes to the standards themselves. We propose to adopt the following versions of the minimum standards codes sets listed below.
We propose to remove and reserve § 170.207(a)(3), IHTSDO SNOMED CT® International Release July 2012 and US Extension to SNOMED CT® March 2012 Release. We propose to revise § 170.207(a)(1), which is currently reserved, to reference SNOMED CT US Edition March 2022 and incorporate it by reference in § 170.299.
We propose to remove and reserve § 170.207(c)(2), Logical Observation Identifiers Names and Codes (LOINC®) Database version 2.40. We propose to revise § 170.207(c)(1), which is currently reserved, to reference LOINC Database version 2.72, February 16, 2022, and incorporate it by reference in § 170.299.
• § 170.207(d)—Medications
We propose to revise § 170.207(d)(1), which is currently reserved, to reference RxNorm July 5, 2022, Full Monthly Release and incorporate it by reference in § 170.299. We propose to reference the code sets specified in 45 CFR 162.1002(c)(1) which include International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM); International Classification of Diseases, 10th Revision, Procedure Coding System (ICD-10-PCS) (including The Official ICD-10-PCS Guidelines for Coding and Reporting); National Drug Codes (NDC); the combination of Health Care Financing Administration Common Procedure Coding System (HCPCS), as maintained and distributed by HHS, and Current Procedural Terminology, Fourth Edition (CPT-4), as maintained and distributed by the American Medical Association, for physician services and other healthcare services; Health Care Financing Administration Common Procedure Coding System (HCPCS) as maintained and distributed by HHS, for all other substances, equipment, supplies, or other items used in healthcare services; and Code on Dental Procedures and Nomenclature, in § 170.207(d)(4).
• § 170.207(e)—Immunizations
We propose to revise § 170.207(e)(1), which is currently reserved, to reference CVX—VaccinesAdministered, June 15, 2022, and incorporate it by reference in § 170.299. We also propose to revise § 170.207(e)(2), which is currently reserved, to reference NDC—Vaccine NDC Linker, updates through July 19, 2022, and incorporate it by reference in § 170.299.
• § 170.207(f)—Race and ethnicity
We propose to add § 170.207(f)(3) to reference CDC Race and Ethnicity Code Set Version 1.2 (July 2021) and incorporate it by reference in § 170.299.
• § 170.207(m)—Numerical references
We propose to revise § 170.207(m)(2), which is currently reserved, to reference the Unified Code of Units of Measure (UCUM), Revision 2.1, November 21, 2017, and incorporate it by reference in § 170.299.
• § 170.207(n)—Sex
As described in this proposed rule in sections III.C.1 and III.C.8, we propose to revise § 170.207(n)(2), which is currently reserved, to reference the version of SNOMED CT® codes specified in § 170.207(a)(1). We also propose to add § 170.207(n)(3) to reference the version of LOINC® codes specified in § 170.207(c)(1).
• § 170.207(o)—Sexual orientation and gender information
We propose to change the heading of § 170.207(o) from “sexual orientation and gender identity” to “sexual orientation and gender information” to acknowledge that § 170.207(o) may include standard code sets to support other gender related data items. Additionally, as described in this proposed rule in sections III.C.1 and III.C.8, we propose to add § 170.207(o)(3) to reference the version of SNOMED CT® codes specified in § 170.207(a)(1) and to add § 170.207(o)(4) to reference the version of LOINC® codes specified in § 170.207(c)(1) for Pronouns.
• § 170.207(p)—Social, psychological, and behavioral data
We propose to revise § 170.207(p)(1) through (8) to reference the version of LOINC® codes specified in proposed § 170.207(c)(1) instead of § 170.207(c)(3). We propose to revise § 170.207(p)(4), (5) and (7) and (8) to reference the version of the Unified Code of Units of Measure in proposed § 170.207(m)(2), instead of § 170.207(m)(1). We also propose to revise § 170.207(p)(6) to include a reference to the version of the Unified Code of Units of Measure in proposed § 170.207(m)(2).
• § 170.207(r)—Provider type
We propose to revise § 170.207(r)(2), which is currently reserved, to reference Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, October 29, 2021, and incorporate it by reference in § 170.299.
• § 170.207(s)—Patient insurance
We propose to revise § 170.207(s)(2), which is currently reserved, to reference Public Health Data Standards Consortium Source of Payment Typology Code Set Version 9.2 (December 2020) and incorporate it by reference in § 170.299.
In addition to updating the minimum standards code sets listed above, we propose to update the certification criteria that reference those minimum standards. We propose to update some of the certification criteria that reference § 170.207(a) Problems, by replacing the reference to § 170.207(a)(4) in those criteria that reference it with a reference to the new proposed § 170.207(a)(1). These criteria include § 170.315(a)(12), (b)(1)(iii)(B)(
We propose to update two certification criteria that reference § 170.207(e) Immunizations. We propose to update the certification criterion § 170.315(f)(1)(i)(B), which references § 170.207(e)(3), to instead reference the new proposed § 170.207(e)(1). We also propose to update the certification criterion § 170.315(f)(1)(i)(C), which references § 170.207(e)(4), by replacing the reference to § 170.207(e)(4) in that criterion with a reference to the new proposed § 170.207(e)(2).
We propose to update several certification criteria that reference § 170.207(f) Race and Ethnicity. We propose to update certification criteria that reference § 170.207(f)(2) to instead reference the new proposed § 170.207(f)(3). These criteria include § 170.315(a)(5)(i)(A)(
As described in sections III.C.1 and III.C.8 of this proposed rule, we propose to update criteria that reference § 170.207(n) Sex by updating criteria that reference § 170.207(n)(1) to reference the new proposed § 170.207(n)(2). More specifically, we propose to update § 170.315(a)(5)(i)(C) to reference § 170.207(n)(1) for the time period up to and including December 31, 2025, or to reference § 170.207(n)(2). We also propose to update § 170.315(c)(4)(iii)(G) to reference § 170.207(n)(2) and to update § 170.315(b)(1)(iii)(G)(
Additionally, as described in sections III.C.1 and III.C.8 of this proposed rule, we propose to update the criteria that reference § 170.207(o) Sexual orientation and gender information (as we propose to rename the criterion) by updating criteria that reference § 170.207(o)(1) and (2). We propose to replace the reference to § 170.207(o)(1) in § 170.315(a)(5)(i)(D) with a reference to the new proposed § 170.207(o)(3) and propose to replace the reference to § 170.207(o)(2) in § 170.315(a)(5)(i)(E) with a reference to the new proposed § 170.207(o)(3). More specifically, we propose to update § 170.315(a)(5)(i)(D) to reference § 170.207(o)(1) for the time period up to and including December 31, 2025, or to reference § 170.207(o)(3). We propose to update § 170.315(a)(5)(i)(E) to reference § 170.207(o)(2) for the time period up to and including December 31, 2025, or to reference § 170.207(o)(3).
We also propose to update § 170.315(c)(4)(iii)(C), which references § 170.207(r) Provider Type. Specifically, we propose to replace the reference to § 170.207(r)(1) in that criterion with a reference to the new proposed § 170.207(r)(2). We also propose to update § 170.315(c)(4)(iii)(E), which references § 170.207(s) Patient insurance. Specifically, we propose to replace the reference to § 170.207(s)(1) in that criterion with a reference to the new proposed § 170.207(s)(2).
Case reporting serves as early notification to Public Health Agencies (PHAs) for potential disease outbreaks and includes information that enables PHAs to start contact tracing and other prevention measures. Case reports include critical clinical information that is not included in syndromic surveillance or laboratory reporting and can help illuminate the impact of comorbidities, treatments, and variable access to care. Every state has laws requiring providers to submit case reports of specific reportable diseases and conditions. Electronic case reporting is the automated, real-time, bidirectional exchange of case report information between EHRs and PHAs.
ONC established initial content exchange standards in 45 CFR 170.205(g)(1) and (g)(2) to support a version of HL7® v2 for “electronic submission to public health agencies for surveillance or reporting” in the 2010 “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” Interim Final Rule (75 FR 2033). These standards were not specific to electronic case reporting; rather they supported the more generic submission of information to PHAs. The “transmission to public health agencies—electronic case reporting” certification criterion in § 170.315(f)(5) was later adopted in the 2015 Edition Final Rule to “support the electronic transmission of case reporting information to public health agencies” as part of the CMS EHR Incentive Programs (80 FR 62667).
In the ONC 2015 Edition Proposed Rule (80 FR 16804), we requested comment on whether to adopt a standardized method for electronic case reporting, including potentially adopting the “IHE Quality, Research, and Public Health Technical Framework Supplement, Structured Data Capture, Trial Implementation (September 5, 2014) standard” and the “HL7 FHIR Implementation Guide: SDC DSTU that would be balloted in mid-2015 in place of, or together with, the IHE Quality, Research, and Public Health Technical Framework Supplement” (80 FR 16855). In response to comments, we did not adopt a standard for this criterion in the 2015 Edition Final Rule, but instead outlined functional requirements that Health IT Modules would need to support for certification to the electronic case reporting criterion. These functional requirements included a requirement that a Health IT Module support the ability to “(1) consume and maintain a table of trigger codes to determine which encounters should initiate an initial case report being sent to public health to determine reportability; and (2) when a trigger is matched, create an initial case report that includes specific data (Common Clinical Data Set; encounter diagnoses; provider name, office contact information, and reason for visit, and an identifier representing the row and version of the trigger table that triggered the case report)” (80 FR 62667). In addition to establishing these functional requirements in the 2015 Edition Final Rule, we also described additional functionalities that would help support electronic case reporting to public health but did not adopt them as requirements for the ONC Health IT Certification Program (80 FR 62667); these functional requirements included: “(3) receive and display additional information, such as a “notice of reportability” and data fields to be
ONC described some of the context for standards development and the future for electronic case reporting. We stated “[a]s standards evolve . . . the future might include a FHIR-based approach. Therefore, we believe this overall initial certification approach establishes necessary flexibility within the ONC Health IT Certification Program related to electronic case reporting in that as technical approaches evolve to accomplish electronic case reporting they can be certified. In the future, we may be able to consider a specific standard for certification through rulemaking” (80 FR 62667).
In 2017, ONC established self-declaration as the demonstration method for electronic case reporting.
We also modified § 170.315(f)(5)(iii)(B) in the ONC Cures Act Final Rule to require Health IT Modules to support creation of electronic case reports based on (1) the data classes expressed in the standards in § 170.213, or (2) the Common Clinical Data Set (CCDS) until December 31, 2022 (85 FR 25667). This was proposed as part of a Program-wide effort to transition Health IT Modules certified to certification criteria that referenced the CCDS to instead support the USCDI v1 (85 FR 25670). ONC subsequently clarified that while either the CCDS or the USCDI v1 data set needed to be supported, “a health IT developer must attest to their product's ability to support the referenced standard(s) in § 170.315(f)(5)(iii)(B)(
Since ONC adopted 45 CFR 170.315(f)(5) as a functional requirement for Health IT Modules in the 2015 Edition, standards development organizations (SDOs), public health, and interested parties within the healthcare industry have balloted several standards related to electronic case reporting. The standards were produced and developed through a collaborative effort among many partners, including CDC, the Council of State and Territorial Epidemiologists (CSTE), the Association of State and Territorial Health Officials (ASTHO), the Association of Public Health Laboratories (APHL), electronic health record (EHR) developers, and the Health Level Seven (HL7) Public Health (PH) Work Group.
Recognizing advancement of standards development in this area, ONC analyzed the currently balloted standards for potential inclusion in the existing 45 CFR 170.315(f)(5) criterion. ONC examined the following standards for potential inclusion as a part of this criterion:
•
○
○
•
• HL7 CDA® R2 Implementation Guide: Public Health Case Report—the Electronic Initial Case Report (eICR) Release 2, STU Release 3.1—US Realm (HL7 CDA eICR IG)
○
• HL7 CDA® R2 Implementation Guide: Reportability Response, Release 1, STU Release 1.1—US Realm (HL7 CDA RR IG)
○
• Reportable Conditions Trigger Codes Value Set for Electronic Case Reporting. RCTC OID: 2.16.840.1.114222.4.11.7508, Release March 29, 2022
○ The Reportable Condition Trigger Codes (RCTC) are a nation-wide set of standardized codes to be implemented within an EHR that provide a preliminary identification of events that may be of interest to PHAs for electronic case reporting. The RCTC are the first step in a two-step process to determine reportability. The RCTC are single factor codes that represent any event that may be reportable to any PHA in the United States. A second level of evaluation still must be done against jurisdiction-specific reporting regulations, to confirm whether the event is reportable and to which PHA or agencies. The RCTC currently includes ICD 10 CM, SNOMED CT, LOINC, RxNorm, CVX, and CPT codes, representing condition-specific diagnoses, resulted lab tests names, lab results, lab orders for conditions reportable upon suspicion, and medications for select conditions.
We propose a deliberate path towards greater standardization and specification of electronic case reporting, moving from functional requirements to standards-based requirements in § 170.315(f)(5) to improve consistency of implementations and interoperability over time. Improvements in consistent implementation and case report interoperability would enable PHAs to have a vastly improved picture of where and when disease outbreaks occur. These standards would also enable health care providers and PHAs to engage in better, bi-directional exchange of information.
In this rule, we propose to revise the criterion in § 170.315(f)(5) to adopt consensus-based, industry-developed standards. These proposed standards would supplement the functional, descriptive requirements in the present criterion in § 170.315(f)(5) for the time period up to and including December 31, 2024, and ultimately replace them. We note that these electronic standards are standards-based representations of the functional requirements described in the existing criterion in § 170.315(f)(5). We propose to allow certification to the existing version of the certification criterion, which we propose to move to § 170.315(f)(5)(i), or the revised version of the certification criterion in proposed § 170.315(f)(5)(ii) beginning on the effective date of the final rule, and to allow certification to only the revised certification criterion in § 170.315(f)(5)(ii) after December 31, 2024.
For the revised version of the certification criterion, we propose requirements in regulation text that align with the functionalities included in the specified CDA and FHIR-based IGs proposed for adoption for the purpose of electronic case reporting. We propose to adopt three standards-based requirements for Health IT Modules certified to the revised certification criterion in § 170.315(f)(5). Specifically, in § 170.315(f)(5)(ii) we propose that a Health IT Module enable a user to:
• Consume and process electronic case reporting trigger codes and parameters and identify a reportable patient visit or encounter based on a match from the Reportable Conditions Trigger Code value set in § 170.205(t)(4) contained in the eRSD Specification Library as specified in the HL7 FHIR eCR IG in § 170.205(t)(1);
• Create a case report consistent with at least one of the following standards:
○ The eICR profile of the HL7 FHIR eCR IG in § 170.205(t)(1), or
○ The HL7 CDA eICR IG in § 170.205(t)(2);
• Receive, consume, and process a case report response that is formatted to either the RR profile of the HL7 FHIR IG in § 170.205(t)(1) or the HL7 CDA RR IG in § 170.205(t)(3); and
• Transmit a case report electronically to a system capable of receiving an electronic case report.
For the proposal in § 170.315(f)(5)(ii)(A) requiring a system to consume and process trigger codes, we propose that a certified Health IT Module identify a reportable patient visit or encounter based on a match from the Reportable Conditions Trigger Code value set in § 170.205(t)(4) contained in the eRSD Specification Library as specified in the HL7 FHIR eCR IG in § 170.205(t)(1) to support the functionality in § 170.315(f)(5)(ii)(A). We describe the standards and implementation specifications in further detail in the subsequent section of this proposed rule.
For the proposal in § 170.315(f)(5)(ii)(B) requiring a Health IT Module to enable a user to create a case report consistent with at least one of the proposed standards in that proposed certification criterion, we clarify that “at least,” means that Health IT Modules must support either the HL7 CDA eICR IG (in § 170.205(t)(2)) or the eICR profile of the HL7 FHIR eCR IG (in § 170.205(t)(1)), or both the CDA and FHIR IGs for the purposes of certification. Our intent is that a certified Health IT Module supports at least one of these kinds of IGs, but we do not preclude a Health IT Module from supporting both. For the proposal in § 170.315(f)(5)(ii)(C) to require that a certified Health IT Module support the receipt, consumption, and processing of reportability responses, we propose that a certified Health IT Module may implement this capability for receipt of responses formatted to either the reportability response profile of the HL7 FHIR eCR IG in § 170.205(t)(1) or the reportability response profile of the HL7 CDA RR IG in § 170.205(t)(3). However, we seek comment on whether we should instead require Health IT Modules to implement this capability for reportability responses formatted to both standards. As part of these proposed standards-based requirements in § 170.315(f)(5)(ii), we reiterate that Health IT Modules would need to follow the respective IG requirements for all “mandatory” and “must support” data elements listed in each IG, as
Additionally, we propose in § 170.315(f)(5)(ii) a fourth non-standards based functional requirement for Health IT Modules certified to § 170.315(f)(5)(ii). We propose in § 170.315(f)(5)(ii)(D) that such Health IT Modules be required to enable a user to electronically transmit a case report to a system capable of receiving case reports electronically. We emphasize that this fourth requirement is agnostic to the recipient of the electronic case report and does not prescribe a specific transport standard, reporting mechanism, or platform. We propose that certification to the updated criterion would be available for Health IT Modules upon the effective date of the final rule. In addition, because certification to § 170.315(f)(5)(i) would only be available through December 31, 2024, health IT developers with Health IT Modules certified to the § 170.315(f)(5) criterion based on meeting the requirements of § 170.315(f)(5)(i) would be required to update and provide their customers with a Health IT Module updated to the revised certification criterion by December 31, 2024, to keep their certification to § 170.315(f)(5) active, consistent with our proposals in sections III.A and III.C.11.
Finally, we note that for Health IT Modules certified to § 170.315(f)(5), the developer of such health IT must continue to demonstrate conformance to these requirements for Real World Testing plans and results per the requirements in § 170.405 regardless of whether the Health IT Module is certified to § 170.315(f)(5)(i) or (f)(5)(ii).
ONC has received feedback from numerous interested parties, including developers of certified health IT, PHAs, and federal partners, that it would be premature to identify a single set of standards for case reporting. We understand that many PHAs use systems that handle CDA-based messages and that many PHAs have not adopted FHIR-based messaging information systems. However, we also have heard that there is interest among some PHAs to leverage FHIR, and we see an opportunity to align requirements for electronic case reporting with other Program requirements that leverage FHIR for developers of certified health IT.
Given the emerging interest in FHIR, and the need to support current public health capabilities, we propose in § 170.315(f)(5)(ii)(B) to require a Health IT Module to create a case report for electronic transmission according to at least one of the following two HL7® standards: in accordance with the eICR profiles specified in the HL7 FHIR eCR IG in § 170.205(t)(1) or in accordance with the eICR profiles specified in the HL7 CDA eICR IG in § 170.205(t)(2). We anticipate that health IT developers would choose to support a CDA-based approach or a FHIR-based approach to support this criterion, but we would not want to preclude a developer from pursuing both approaches with its Health IT Module(s). We clarify that for purposes of Program requirements, a Health IT Module certified to § 170.315(f)(5) would not need to support both approaches; however, we acknowledge the possibility that a developer of certified health IT may choose to support both approaches to meet the needs of its customer base. As part of the proposed requirement in § 170.315(f)(5), we propose that Health IT Modules support all “mandatory” and “must support” data elements as applicable in either the eICR profiles of the HL7 FHIR eCR IG
We propose in § 170.315(f)(5)(ii)(C) to require that Health IT Modules certified to § 170.315(f)(5) support the receipt, consumption, and processing of reportability responses formatted according to the RR profiles defined in the HL7 FHIR eCR IG or the HL7 CDA RR IG. We seek comment on whether we should instead require Health IT Modules to have the capability to receive, consume and process a reportability response formatted to both standards. Again, as part of the proposed consume and process reportability response requirement in § 170.315(f)(5)(ii)(C), we propose that Health IT Modules support consuming and processing all “mandatory” and “must support” data elements as applicable in either the RR profiles of the HL7 FHIR eCR IG or the RR profiles of the HL7 CDA RR IG,
We believe that the health IT industry eventually will coalesce with the public health community around a single set of standards, but for the near-term, we believe that both CDA-based and FHIR-based standards will be leveraged for eICR and RR, depending on the unique circumstances of geography, jurisdiction, and users of certified health IT. We reiterate that health IT developers may choose to support both CDA and FHIR-based approaches for electronic case reporting, but we only propose to require support of at least one of these approaches for Health IT Modules certified to § 170.315(f)(5) pursuant to the Program. Additionally, health IT developers may choose to support functionalities beyond these requirements depending on their approach to electronic case reporting. We invite comment on our proposal to require Health IT Modules certified to § 170.315(f)(5) to support at least the RR profiles of the HL7 FHIR eCR IG or the HL7 CDA RR IG.
Finally, we propose in § 170.315(f)(5)(ii)(A) that a Health IT Module certified to § 170.315(f)(5) support the consumption and processing of electronic case report trigger codes and parameters based on a match from Reportable Conditions Trigger Code value set in § 170.205(t)(4)
We understand that the eRSD profiles include both trigger codes, as described in the RCTC value set, and more complex reporting parameters. We understand that the basics of electronic case reporting require a health IT developer to use, at a minimum, reportable conditions as represented in the RCTC value set to match with a patient visit and/or encounter, so we propose to require that Health IT Modules support the eRSD profiles in the HL7 FHIR eCR IG proposed § 170.205(t)(1) using the RCTC value set in proposed § 170.205(t)(4).
We propose to require certified Health IT Modules to support the ability to consume and process the eRSD profiles, which include the RCTC value set, regardless of whether such a Health IT Module supports a FHIR-based or CDA-based approach to certification. As part of the proposal to require Health IT Modules to consume and process the eRSD profiles in § 170.315(f)(5)(ii)(A), we clarify that a Health IT Module must support consuming and processing all “mandatory” and “must support” data elements of the eRSD Specification Library and the eRSD Supplemental Library specified in section 10.0.3 of the HL7 FHIR eCR IG.
We clarify that a certified Health IT Module need only support parsing and consuming the eRSD Specification Library and eRSD Supplemental Library because we understand that health IT developers may choose to either manually encode the electronic case reporting trigger logic into Health IT Modules or may support a more automated process for encoding the trigger logic into Health IT Modules. We request comment on this approach and on whether there is general support of the eRSD Specification Library and eRSD Supplemental Library for electronic case reporting triggering.
Per documentation in the HL7 CDA eICR IG,
We note that in the 2015 Edition Final Rule, we established a policy for minimum standards code sets that update frequently throughout a calendar year (80 FR 62612), and we have listed several standards as minimum standard code sets in 45 CFR part 170 subpart B. As with all adopted minimum standards code sets, health IT can be certified to newer versions of the adopted baseline version minimum standards code sets for purposes of certification, unless the Secretary specifically prohibits the use of a newer version (
The RCTC value set comprises single factor codes that represent any event that may be reportable to any PHA in the United States. The RCTC value set currently includes ICD-10 CM, SNOMED CT, LOINC, RxNorm, CVX, and CPT, representing condition-specific diagnoses, resulted lab tests names, lab results, lab orders for conditions reportable upon suspicion, and medications for select conditions. Given that the contents of the RCTC value set update frequently, we propose to recognize the RCTC value set as a minimum standard code set in § 170.205(t)(4), and we propose that the reference standard for the RCTC value set be established as RCTC OID: 2.16.840.1.114222.4.11.7508, Release March 29, 2022, IBR approved (incorporated by reference in § 170.299) (available at:
The eCR FHIR IG is a relatively new standard with standard for trial use (STU1) status published on January 29, 2020, STU2 published on January 18, 2022, and an updated STU2 published on August 31, 2022. While we propose to adopt the eICR, RR, and eRSD profiles of the FHIR eCR IG as described in this section, we are also interested in receiving specific comments from the public regarding their experiences with implementation and use of the FHIR eCR IG.
We note that requiring standards in the proposed § 170.315(f)(5)(ii)(A), (B), and (C) for Health IT Modules certified to § 170.315(f)(5) will enable ONC to approve newer versions of these standards through SVAP per existing provisions at 45 CFR 170.405(b)(8) and 170.405(b)(9), which will enable health IT developers to voluntarily keep pace with the latest improvements in standards outside the timeframes dictated by the rulemaking process. We invite comment on the proposed adoption of these HL7 standards and IGs, including whether we should finalize only the FHIR-based standards and IGs or only the CDA-based standards and IGs, or both as proposed.
Finally, we propose in § 170.315(f)(5)(ii)(D) to require Health IT Modules certified to § 170.315(f)(5) to be capable of electronically reporting to a system that is capable of receiving case reports electronically. This proposed reporting function would be agnostic to a specific standard or reporting mechanism or platform. We note that all currently balloted HL7 standards directly reference optional use of a centralized decision support solution called the Reportable Condition Knowledge Management System
At this time, ONC is not proposing to require Health IT Modules certified to § 170.315(f)(5) to specifically connect to AIMS or support RCKMS to meet the proposed requirements in § 170.315(f)(5)(ii)(D). While we understand the role AIMS and RCKMS play in a centralized, hub-and-spoke model for electronic case reporting, we propose that the functional requirements for § 170.315(f)(5)(ii)(D) remain agnostic as to which reporting platform and which decision support tool are used. However, we note that different PHAs are likely to have different reporting requirements, including specific systems, decision support logic, or both. While we are not requiring the use of a specific reporting platform, the certified functionality in § 170.315(f)(5)(ii)(D) requires that the Health IT Module be capable of transmitting electronic case reports consistent with the reporting requirement(s) established by a PHA. We know that some states and jurisdictions have implemented separate electronic reporting requirements that do not involve the use of the AIMS platform, RCKMS, or both, and we believe that reporting requirements should be determined by PHAs at this time. Therefore, developers of certified health IT can meet the requirements in § 170.315(f)(5)(ii)(D) by demonstrating that their Health IT Modules possess the capability to send a case report electronically to any system capable of receiving a case report. A developer of certified health IT could also elect to support more than one reporting option in a Health IT Module.
As stated previously, the primary motivation for proposing standards for electronic case reporting in § 170.315(f)(5) is to enable the use of SVAP to allow industry to leverage improved versions of standards on an expedited timeline, as the standards continue to evolve and mature. We encourage members of the standards development community to iterate and improve these HL7®-balloted standards for electronic case reporting so that the benefits of this technology may be widely shared.
Since 2010, the Program has maintained a CDS certification criterion, consistent with the “qualified electronic health record” definition in section 3000(13) of the PHSA, which defines a qualified EHR as an electronic record of health-related information on an individual that has the capacity to “provide clinical decision support” (42 U.S.C. 300jj(13)(B)(i)). The initial requirements for the CDS certification criterion were intended to ensure that Health IT Modules support broad categories of CDS while being agnostic toward the intended use of the CDS beyond drug-drug and drug-allergy interaction checks. The initial CDS criterion required that a Health IT Module could: (1) implement rules, “according to specialty or clinical priorities;” (2) “automatically and electronically generate and indicate in real-time, alerts and care suggestions based upon clinical decision support rules and evidence grade;” and (3) track, record, and generate reports on the number of alerts responded to by a user (75 FR 2046).
In 2012, largely based on recommendations made by ONC's Health Information Technology Policy Committee (HITPC),
Since the adoption of the CDS criterion in § 170.315(a)(9), health IT implementation and technology resources used to support clinical decision-making have continued to evolve. Within healthcare today, predictive models are increasingly being used and relied upon to inform an array of decision-makers, including clinicians, payers, researchers, and individuals, and to aid decision-making through CDS.
The National Academy of Medicine (NAM) described in a 2019 report how predictive models and other forms of artificial intelligence (AI) have the potential to represent the “payback” of using health IT “by facilitating tasks that every clinician, patient, and family would want, but are impossible without electronic assistance.”
As the evolution of technology has continued, there has been a bi-partisan effort to ensure the Department and the Federal Government optimize the use of AI while working to address potential risks in the development and use of predictive models and AI, including efforts to promote transparency and notice, ensure fairness and non-discriminatory practices, and protect the privacy and security of health information.
In November of 2020, the Office of the Management and Budget released a Memorandum for the Heads of Executive Departments and Agencies on
In June of 2021, the Government Accountability Office (GAO) published
In September of 2022, the Biden-Harris Administration published
Finally, in February of 2023, E.O. 14901:
A growing body of peer-reviewed evidence, technical and socio-technical expert analyses, and government activities and reports
We believe that the continued evolution of decision support software, especially as it relates to AI- and ML-driven predictive DSIs, necessitates new requirements for the Program's CDS criterion. These include proposed requirements for new sets of information that are necessary to guide decision-making based on recommendations (outputs) from predictive DSIs, such as an expanded set of “source attributes” and information related to how intervention risk is managed by developers of certified health IT with Health IT Modules that enable or interface with predictive DSIs. We believe that these new sets of information would provide appropriate information to help guide decisions at the time and place of care, consistent with 42 U.S.C. 300jj-11(b)(4).
We consider AI to encompass a broad and varied set of technologies that generally incorporate algorithms or statistical models. Early examples of AI in healthcare, sometimes referred to as “expert systems,” were based on codified expert knowledge, logic models, and deterministic rules to recommend treatment for individuals, and systems of this type are widely used today to provide clinical decision support (CDS).
Within healthcare today, predictive models are increasingly being used to inform an array of key decision-makers, including clinicians, payers, researchers, and individuals, and to aid decision-making through CDS.
Increasingly, predictive DSIs are embedded into health IT systems including certified health IT, within a medical device, or as a standalone medical device.
The expanding use of and reliance on predictive models in healthcare are demonstrating value in many circumstances.
In this proposed rule, model risk refers to the potential that an entity is negatively influenced by a potential circumstance or event based on incorrect, misused, or otherwise harmful model outputs and reports, the likelihood of those adverse consequences, and their magnitude.
One of the most consequential adverse events resulting from the use of predictive models relates to bias in the predictions of such models. While the use of AI has the potential to reduce unlawful discrimination caused by systemic biases,
For example, a widely used algorithm designed to identify patients with high needs for healthcare systematically assigned lower scores to Black patients than to White patients, even when those individuals had similar numbers of chronic conditions and other markers of health.
Model risk—and resulting harmful bias—may be driven by a number of potential factors, which we seek to address in this proposed rule. For instance, there may be additional bias introduced, either unintentionally or deliberately, by the developer of a DSI based on their vested interest in the outcome, clinical intervention, or recommendation. Developers of predictive models and decision support modules sometimes include pharmaceutical manufacturers, pharmacies, clinical laboratories, and other entities that have a financial interest in the treatment selected by health care providers. We note the Federal anti-kickback statute makes it a criminal offense to knowingly and willfully offer, pay, solicit, or receive any remuneration to induce, or in return for, the referral of an individual to a person for the furnishing of, or arranging for the furnishing of, any item or service reimbursable under a Federal health care program. The statute's prohibition also extends to remuneration to induce, or in return for, the purchasing, leasing, or ordering of, or arranging for or recommending the purchasing, leasing, or ordering of, any good, facility, service, or item reimbursable by a Federal health care program. Accordingly, if any individual or entity offers or provides remuneration to health IT developers, their customers, or others (including patients) to arrange for the furnishing of any item or service or arrange for or recommend purchasing, leasing, or ordering any good, facility, service, or item payable in whole or in part under a Federal health care program may implicate and potentially violate the Federal Anti-Kickback Statute for both those who offer or pay and those who solicit or receive remuneration. This may include, for example, remuneration by third parties to developers of certified health IT for integrating or enabling DSI where one purpose is to increase sales of the third-party's products or services. Our existing certification criterion for clinical decision support in § 170.315(a)(9) includes a source attribute to describe the funding source of any evidence-based DSIs. In this proposed rule, we include the same transparency on funding source requirements within the proposed source attributes for the new DSI criterion in § 170.315(b)(11) as well as additional requirements described further in the summary of proposals in this section with the intent of support users in fully understanding the model risk in predictive DSI their Health IT Module enables or interfaces with.
Model risk occurs primarily for two reasons. First, the model may have fundamental errors and may produce inaccurate outputs when viewed against the design objective and intended uses. The mathematical calculation and quantification exercise underlying any model generally involves application of
Second, the model may be used incorrectly or inappropriately. Even a fundamentally sound model producing accurate outputs consistent with the design objective of the model may exhibit high model risk if it is misapplied or misused. Models by their nature are simplifications of reality, and real-world events may prove those simplifications inappropriate. This is even more of a concern if a model is used outside the environment for which it was designed. Decision makers need to understand the limitations of a model to avoid using it in ways that are not consistent with the original intent. Limitations come in part from weaknesses in the model due to its various shortcomings, approximations, and uncertainties. Limitations are also a consequence of assumptions underlying a model that may restrict the scope to a limited set of specific circumstances and situations.
Greater transparency in model theory, assumptions, design, and evaluation could allow users of certified health IT to review model design and evaluation and determine whether a particular model is appropriate for their purposes. Despite the need for information about predictive model development processes, evaluations of performance, and risk management, this information is often unavailable to users and purchasers of certified health IT. This may be because such information does not exist, because it is not made available to those outside the organization that developed the model, or because there is a lack of industry consensus around what information should be available and to whom, among other potential reasons. In turn, complex predictive models are often referred to as `black boxes' because it can be difficult or impossible to determine why the model arrives at a specific prediction.
In contrast to the U.S. financial services industry,
We are aware of existing and emerging efforts to establish guidelines, frameworks, and principles to encourage optimization of predictive models in healthcare, including recent industry recognition for evaluation, monitoring, and guardrails.
We believe predictive DSIs can promote positive outcomes and avoid harm when those DSIs are FAVES. We refer to DSIs that are fair, appropriate, valid, effective, and safe as FAVES. Fair DSIs do not exhibit biased performance, prejudice, or favoritism toward an individual or group based on their inherent or acquired characteristics.
Our proposals in § 170.315(b)(11) are intended to introduce much-needed information transparency to address uncertainty regarding the quality of predictive DSIs that certified Health IT Modules enable or interface with, so that potential users have sufficient information about how a predictive DSI was designed, developed, trained, and evaluated to determine whether it is trustworthy. We propose a dual emphasis for transparency on (1) the technical and performance aspects of predictive DSIs and (2) the organizational competencies employed to manage risks for predictive DSIs. Together, this information would support potential users to make more informed decisions about whether and how to use predictive DSIs in their decision-making given the specifics of their context, patients and needs. We consider the information included in these proposed transparency requirements as a prerequisite to determine the quality of predictive models. In addition, such transparency would provide essential information needed to determine whether and how to use the predictive model's outputs. Our proposals are not aimed at approving or guaranteeing the quality of predictive DSIs or the models they are based on. Instead, our proposals are intended to provide users and the public greater information, available in a consistent manner, on whether predictive DSIs are fair, appropriate, valid, effective, and safe. We believe that the resulting transparency from the proposed requirements for the certification criterion in § 170.315(b)(11) described in this section would promote the design, development, and deployment of high-quality predictive models in that they adhere to FAVES principles.
We do not propose to establish or define regulatory baselines, measures, or thresholds of FAVES for predictive DSIs. Instead, we propose, as part of the proposed certification criterion in § 170.315(b)(11), to establish requirements for information that would enable users, based on their own judgment, to determine if a predictive DSI that is enabled by or interfaced with a Health IT Module is acceptably fair, appropriate, valid, effective, and safe. We understand that numerous and parallel efforts led by industry groups are developing methods to evaluate predictive DSIs for fairness, appropriateness, validity, effectiveness, and safety, among other kinds of evaluations. These efforts are also devising means to communicate measures of FAVES through model cards,
While we believe that transparency regarding the technical and performance dimensions of the predictive DSI is needed, we also believe that transparency regarding the organizational and socio-technical competencies employed by those who develop predictive DSIs is foundational for users to determine whether their predictive DSI is FAVES. Therefore, in addition to the proposed requirements for predictive DSI-specific source attributes, we also propose that developers of certified health IT with Health IT Modules that enable or interface with predictive DSIs and that are certified to § 170.315(b)(11), employ or engage in intervention risk management practices, subsequently making summary information about these practices available publicly. We propose three intervention risk management practices: (1) risk analysis, (2) risk mitigation, and (3) governance. Overall, we identify these practices to promote transparency regarding how the developer of certified health IT analyzes and mitigates risks, at the organization level, including proposals that would have such developers establish policies and implement controls for governance, including how data are acquired, managed, and used in predictive DSIs.
Whereas our proposals for source attributes in § 170.315(b)(11)(vi)(C) are intended to bring transparency into the technical and performance dimensions of the predictive DSI, such as underlying details of the predictive model, how the model was trained, and how its outputs were validated, the proposals for intervention risk management in § 170.315(b)(11)(vii) would focus on the developer of certified health IT's organizational competencies employed, and would bring transparency into the socio-technical dimensions of the predictive DSI. Together, transparency regarding the technical and performance details of a predictive DSI, as well as the organizational competencies of the developer of certified health IT to manage risks for a predictive DSI are intended to contribute to the trustworthiness of these emerging and important technologies.
The proposed requirements for the certification criterion in § 170.315(b)(11) would also support health equity by design
We believe the existing scope and structure of the Program are fit for these purposes because the Program has existing requirements to make transparent information regarding the authorship, bibliography, and other kinds of “source attribute” information for evidence-based decision support and linked referential intervention types. By requiring developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) to display additional source attributes on evidence-based DSIs, to display source attribute information on the predictive DSI(s) within their certified products, and to disclose approach(es) to intervention risk management in a publicly accessible manner, these proposals would have an important impact on the Department's efforts to address disparities and bias that may be propagated through DSIs. Consequently, we hope to enhance market transparency and encourage trust across the software development life cycle (SDLC) of DSIs in healthcare. This transparency would serve as a foundation for establishing consistency in information availability, improving overall data stewardship, and guiding the appropriate use of data derived from health information about individuals.
We are being intentional with the level of prescriptiveness in our proposals because these are nascent technologies with enormous potential benefit. Thus, we seek to establish appropriate guardrails for information transparency about predictive DSIs that do not undercut the value that could be offered to patients and clinicians from such promising technologies.
We propose the certification criterion, “decision support interventions (DSI)” in § 170.315(b)(11). The DSI criterion is a revised certification criterion as it serves as both an iterative and replacement criterion for the “clinical decision support (CDS)” criterion in § 170.315(a)(9). We believe that the continued evolution of decision support software, especially as it relates to AI- and ML-driven predictive models, necessitates new requirements and a new name for the Program's CDS criterion. We propose to revise the name of the CDS criterion to “decision support interventions” to reflect the various and expanding forms of decision support that certified Health IT Modules enable or interface with. Increasingly, DSIs include use cases or are intended to support decision-making across all areas of healthcare, including early detection of disease, automating billing procedures, facilitating scheduling, supporting public health disease surveillance, and other uses beyond traditional CDS. We intend for the DSI criterion to be inclusive of the wide variety of use cases that Health IT Modules may support moving forward.
As part of the DSI criterion, we propose to add in § 170.315(b)(11)(v) “predictive decision support interventions” and propose to add a corresponding definition for that term to § 170.102. In addition to predictive DSIs, we propose to include in § 170.315(b)(11) the list of current intervention types in § 170.315(a)(9), including evidence-based decision support in § 170.315(b)(11)(iii) and linked referential DSI in § 170.315(b)(11)(iv). Together, we believe these intervention types reflect the variety of DSIs increasingly enabled by or interfaced with, certified Health IT Modules.
In addition to proposing to adopt all source attributes listed in § 170.315(a)(9)(v) in § 170.315(b)(11), we also propose in § 170.315(b)(11)(vi)(A)(
We propose that the new evidence-based DSI source attributes in § 170.315(b)(11)(vi)(A)(
We believe that these additional source attributes would better support the transparency of predictive DSIs and that such information is necessary for
Given the potential of a growing market of third-party developed predictive DSIs and development of predictive DSI by customers of developers of certified health IT, we expect that Health IT Modules certified to § 170.315(b)(11) would provide users with source attribute information from these other parties. In circumstances where the developer of certified health IT does not receive source attribute information, we propose in § 170.315(b)(11)(vi)(D) that Health IT Modules clearly indicate when source attributes related to DSIs developed by others are not available for the user to review. We believe it is important that users be made aware when source attribute information is missing or unknown. We propose in § 170.315(b)(11)(vi)(E) that Health IT Modules enable users to author attributes and revise attributes beyond what is proposed in § 170.315(b)(11)(vi)(A) and § 170.315(b)(11)(vi)(C) to support the ongoing evolution of what source attributes are important to users to make informed decisions regarding the DSI's recommendation(s).
We propose in § 170.315(b)(11)(vii) to require developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) that enable or interface with predictive DSIs (
Additionally, we propose in § 170.315(a)(9)(vi) that the adoption of the CDS criterion, for purposes of the Program, expires on January 1, 2025. This timeline would support our proposal that developers of certified health IT must certify their Health IT Modules to § 170.315(b)(11) by December 31, 2024, if they wish such Health IT Modules to meet the newly proposed Base EHR definition and ensure continuity for customers using Health IT Modules currently certified to § 170.315(a)(9).
Finally, we propose in § 170.405(a) to require health IT developers of certified health IT with a Health IT Module certified to § 170.315(a)(9) to submit real world testing plans and results consistent with § 170.405 for the period until the CDS criterion is no longer part of the Program. We note that developers of certified health IT with a Health IT Module certified to any of the criteria in § 170.315(b) are already subject to requirements in § 170.405, thus Health IT Modules certified to § 170.315(b)(11) would be subject to the requirements in § 170.405.
We propose to adopt the certification criterion “decision support interventions,” (DSI) in § 170.315(b)(11) as a “revised certification criterion” according to the proposed definition in § 170.102. The proposed new criterion in 170.315(b)(11) is a revised version of 45 CFR 170.315(a)(9), “clinical decision support (CDS).” We propose to adopt in § 170.315(b)(11) the structural paragraphs currently in § 170.315(a)(9) with modifications that reflect an array of contemporary functionalities, data elements, and software applications that certified Health IT Modules enable or interface with to aid decision-making in healthcare. We propose that the policies established in § 170.315(a)(9)(i) through (iv) will be included as § 170.315(b)(11)(i) through (iv) with modifications described later in this preamble. We propose to introduce a new intervention type in § 170.315(b)(11), predictive decision support interventions, with a corresponding definition in § 170.102 for predictive decision support interventions.
We believe that these modifications to § 170.315(a)(9), proposed in § 170.315(b)(11), reflect a functionality that is better categorized as part of the “care coordination certification criteria,” as opposed to the “clinical certification criteria,” supported by the Program. Hence, we propose to adopt the decision support intervention certification criterion in the “care coordination criteria” section adopted within § 170.315(b). The capabilities included within the certification criterion in § 170.315(a)(9) are unlike other certification criteria currently adopted in the “clinical” section in that
We propose modifications to the “Base EHR” definition in § 170.102 to identify the dates when § 170.315(b)(11) replaces § 170.315(a)(9) in the Base EHR definition. In keeping with the proposal to modify the Base EHR definition in § 170.102, we propose that the adoption of § 170.315(a)(9) as part of the Program would expire January 1, 2025. We note that if we finalize these proposals, developers of certified health IT with Health IT Modules certified to § 170.315(a)(9) who wish for those Health IT Modules to continue to meet the Base EHR definition would need to certify those Health IT Modules to § 170.315(b)(11) by December 31, 2024, which is the effective date we propose elsewhere in this preamble to modify the Base EHR definition to include § 170.315(b)(11).
As a consequence of proposing to adopt this criterion in § 170.315(b), we note that developers of certified health IT with Health IT Module(s) certified to § 170.315(b)(11) would be required to submit real world testing plans and corresponding real world testing results, consistent with § 170.405, demonstrating the real world use of each DSI type the developer of certified health IT supports in § 170.315(b)(11), including evidence-based decision support (§ 170.315(b)(11)(iii)), linked referential (§ 170.315(b)(11)(iv)), and predictive DSI (§ 170.315(b)(11)(v)) as applicable. We refer readers to 85 FR 25766 for further explanation and discussion regarding real world testing. We also note that we propose in a separate section to include § 170.315(a)(9) as part of the applicable certification criteria for real world testing in § 170.405(a). We invite comment on these proposals.
We propose in § 170.315(b)(11)(ii) to establish “decision support configuration,” requirements based on what is currently in § 170.315(a)(9)(ii) with modifications and additional requirements. To reflect ONC's focus on the USCDI and to acknowledge the varied data for which DSIs may be enabled, we propose that data elements listed in § 170.315(b)(11)(ii)(B)(
Additionally, we propose to include two USCDI data classes not currently found in § 170.315(a)(9)(ii)(B)(
We note that in our 2015 Edition Proposed Rule, we proposed to adopt new functionality that would require a Health IT Module certified to § 170.315(a)(9) to be able to record at least one action taken, and by whom it was taken, when a CDS intervention is provided to a user (
Research indicates that simple “feedback loops” on the performance of DSIs implemented at the point of care
While we are aware that some health care providers have implemented functionalities to enable “feedback loops,” we understand through conversations with interested parties that such functionality is far from commonplace or that information regarding the use of CDS interventions is standard across industry. Subsequent to the 2015 Edition Final Rule, additional evidence has confirmed the effectiveness of this functionality. Consequently, we propose to adopt in § 170.315(b)(11)(ii)(C) a new functionality to enable users to provide electronic feedback data based on the information displayed through the DSI. We propose that a Health IT Module certified to § 170.315(b)(11) must be able to export such feedback data, including but not limited to the intervention, action taken, user feedback provided (if applicable), user, date, and location, so that the exported data can be associated with other relevant data. We believe the proposed feedback data identified for export represents a minimum set that users would find valuable for evaluation of DSIs they use. However, we welcome comment on the proposed scope of these feedback data, utility for evaluation of their DSIs, and the potential for such data to be used in conjunction with quality metrics.
We propose that such feedback data be available for export by users for analysis in a computable format, so that it can be associated with other relevant data, such as diagnosis, other inputs into the DSI, and the outputs of the DSI for a particular patient, to evaluate and improve DSI performance. We note that “computable format,” is consistent with current requirements in § 170.315(b)(10)(i)(D) for EHI Export, and we clarify that “computable format” is also referred to as “machine readable,” in other contexts, which is not synonymous with “digitally accessible.”
We propose in § 170.315(b)(11)(iii) to establish “evidence-based decision support interventions,” with a minor revision to current requirements that are part of the CDS criterion in § 170.315(a)(9)(iii). This proposal would replace the current construct in § 170.315(a)(9)(iii), which states a Health IT Module must enable evidence-based decision support interventions “based on each one and at least one combination of” the data referenced in paragraphs § 170.315(a)(9)(ii)(B)(
This proposal would not prescribe the intended use of the evidence-based DSI. Rather, this subparagraph, in combination with the data referenced in § 170.315(b)(11)(ii)(B)(
We propose to replicate what is currently in § 170.315(a)(9)(iv) as § 170.315(b)(11)(iv) with a modification to reference the criterion in § 170.315(b)(11) wherever the current reference is to § 170.315(a)(9). We propose no further changes at this time. This proposal therefore reflects the capabilities included in the CDS criterion for which health IT developers of certified health IT have years of familiarity and can find, for comparison purposes in 45 CFR 170.315(a)(9). However, we welcome comment regarding the functionalities and standards listed in § 170.315(a)(9)(iv), the HL7 Context Aware Knowledge Retrieval Application (“Infobutton”) standards, including whether linked referential CDS are commonly used with, or without, the named standards in § 170.315(a)(9)(iv)(A)(
We propose to reference a new intervention type, “predictive decision support intervention,” in § 170.315(b)(11)(v), and we propose a corresponding definition in § 170.102. We also propose in § 170.315(b)(11)(v)(A) that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) attest “yes” or “no” as to whether their Health IT Module enables or interfaces with one or more predictive DSIs based on any of the data expressed in the standards in § 170.213, including USCDI v3 as proposed elsewhere in this preamble. Below we discuss our proposal in § 170.102 for a definition of predictive DSIs to provide necessary context for our proposals for attestation in § 170.315(b)(11)(v).
We propose a definition of “predictive decision support
Such predictive DSIs are based on the use of predictive model(s). In this proposed rule, “model” refers to a quantitative method, system, or approach that applies statistical, economic, bioinformatic, mathematical, or other techniques (
We intend for our use of the phrase “intended to support decision-making” to be interpreted broadly and to encompass technologies that require users' interpretation and action as well as those that initiate management and require action to contest. Our use of predictive DSI is not tied to the level of risk or degree to which the predictive DSI informs or drives treatment, is relied upon by the user, relates to time sensitive action, or whether the predictive DSI is augmentative or autonomous.
We intentionally use the term “predictive decision support intervention” in addition to the Program's existing and parallel use of the term “evidence-based decision support intervention,” for example as used in § 170.315(a)(9)(iii). We differentiate predictive DSIs as those that support decision-making by learning or deriving relationships to produce an output, rather than those that rely on pre-defined rules based on expert consensus, such as computable clinical guidelines, to support decision-making. This distinction is not meant to convey that predictive DSIs are without evidence or that such interventions have not demonstrated clinical effectiveness. We expect that predictive DSIs will be supported by a robust evidence base, which may include prospective clinical trials, observational studies, and other evidence published as peer-reviewed literature describing the intervention's purpose, intended use, and performance. We seek comment on whether this definition effectively delineates between DSIs that would be considered predictive versus those that are evidence-based DSIs, to use existing terminology.
We propose a definition of predictive DSI that would cover a wide variety of techniques from algebraic equations to machine learning and natural language processing (NLP). For example, the proposed definition would include the Acute Physiology and Chronic Health Evaluation IV (APACHE IV) model. That model, which predicts in-hospital mortality for patients in intensive care units, was initially trained and validated in data from 45 hospitals including over one hundred thousand individuals in 2006.
Our proposed definition would also include more complex predictive models leveraging machine learning. For example, readmission models developed by combining multiple Naïve Bayes algorithms or deep unified networks trained and validated on over ten thousand individuals and resulting in models that can be applied to patients in operational contexts would meet the proposed definition of a predictive DSI.
Predictive models represent one widely used form of AI, but do not include all AI. Our proposed definition would not include the computer readable implementation of clinical guidelines or similar types of knowledge except when those guidelines—and the interventions implemented based on them—incorporate a predicted value, such as a predicted risk, in guiding clinical decision-making. We note that, in this proposed rule, the term “intervention” in “prediction decision support intervention” is not intended to mean an intervention (medicine, medical procedure, or medical treatment) as the term is used in the practice of medicine,
As proposed in § 170.102, the definition of a predictive decision support intervention would not include simulation models that use modeler-provided parameters rather than training data or unsupervised machine learning techniques that do not predict an unknown value (
In § 170.315(b)(11)(v)(A), we propose that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) attest “yes” or “no” to whether their Health IT Module enables or interfaces with predictive DSIs based on any of the data expressed in the standards in § 170.213. This attestation requirement would have the effect of permitting developers of certified health IT to certify to § 170.315(b)(11) without requiring their Health IT Modules to enable or interface with predictive DSIs. However, for those developers of certified health IT that attest “yes” as described in § 170.315(b)(11)(v)(A), we describe further in this section applicable requirements related to such developers and their Health IT Modules.
By way of example, we expect that developers of certified health IT should attest “yes,” if any of the following are true: (1) the developer develops (self-develops) predictive DSIs for use in their certified Health IT Module; (2) the developer's Health IT Module enables or interfaces with predictive DSIs developed by its end users or customers, such as a healthcare organization or medical center; or (3) the developer's Health IT Module enables or interfaces with predictive DSIs developed by a third-party content provider or developer, such as a technology firm that specializes in predictive model development.
We clarify that “enables” means that the developer of certified health IT has the technical capability to support a predictive model or DSI within the developer's Health IT Module. We understand that predictive DSIs can be configured in various ways, including as user-developed or third party-developed applications for use within or as a part of a Health IT Module. We also understand that predictive DSIs can be developed by a developer of certified health IT for use within or as a part of their own Health IT Module. We clarify that applications developed by other parties and self-developed applications that are used within or as a part of a Health IT Module would mean that the Health IT Module is considered to “enable” predictive DSIs. For example, if the calculations or processing for a predictive DSI occur within the Health IT Module, either through a standalone application developed by other parties or an application self-developed by a developer of certified health IT for use within a Health IT Module, we would consider this “enabling.” We clarify that this technical capability to support a predictive model or DSI includes instances where predictive DSIs are enabled by default and instances where they can be enabled by users. We propose that if a developer's Health IT Module enables predictive DSIs, based on any of the data expressed in the standards in § 170.213, then a developer of certified health IT must attest “yes,” in § 170.315(b)(11)(v)(A).
In contrast, we clarify that “interfaces with” means that the Health IT Module facilitates either (1) the launch of a predictive model or DSI or (2) the delivery of a predictive model or DSI output(s) to users when such a predictive model or DSI resides outside of the Health IT Module. For example, scenarios where the calculations for a predictive DSI occur outside the Health IT Module, and the predicted value or output gets sent to or through a Health IT Module, or to or through an application used within or as part of a Health IT Module, would be considered to “interface with.” We would also consider a Health IT Module to “interface with,” a predictive DSI in scenarios where an application is launched from a certified Health IT Module, including through the use of a single sign-on functionality. If a developer of certified health IT's Health IT Module interfaces with predictive DSIs based on any of the data expressed in § 170.213, then a developer of certified health IT must attest “yes,” to § 170.315(b)(11)(v).
We are aware that some organizations may use USCDI data exported or sourced from a certified Health IT Module to develop data-driven advanced analytics leveraging predictive models or technologies to provide insights for healthcare. In such circumstances, our proposed requirements would only pertain if the output of the predictive model subsequently interfaced with a Health IT Module. The proposed requirement would not establish requirements for predictive technologies that are not enabled or do not interface with a Health IT Module.
We note that developers of certified health IT with a Health IT Module that enables or interfaces with predictive DSIs that use any of the data expressed in the proposed standards in § 170.213 must attest “yes” in § 170.315(b)(11)(v) if their Health IT Module(s) is certified to § 170.315(b)(11). We also propose as part of this attestation requirement in
Finally, we note that developers of certified health IT that attest “no” in § 170.315(b)(11)(v) would still be required to conform to the full scope of this criterion, including the provision of source attribute information as described in § 170.315(b)(11)(vi)(A) and (B) through their Health IT Module. The attestation requirement in § 170.315(b)(11)(v) is constructed to make support of predictive DSIs optional for a Health IT Module certifying to § 170.315(b)(11) and to establish conditional requirements if the developer of certified health IT with a Health IT Module attests “yes.” Developers of certified health IT that attest “yes” in § 170.315(b)(11)(v) would be required to provide source attribute information through their Health IT Module in § 170.315(b)(11)(vi)(C), which includes by reference those source attributes listed in § 170.315(b)(11)(vi)(A) and employ or engage in intervention risk management practices as discussed in § 170.315(b)(11)(vii). We invite comment on these proposals.
We propose in § 170.315(b)(11)(vi) that Health IT Module certified to § 170.315(b)(11) enable a user to review a plain language description of source attribute information as indicated at a minimum via direct display, drill down, or link out from a Health IT Module. This requirement would be for source attribute information pertinent to each DSI type: evidence-based DSIs in (b)(11)(iii), linked referential DSIs in (b)(11)(iv), and source attributes required for Health IT Modules that enable or interface with predictive DSIs as defined in § 170.102 when a certified health IT developer attests “yes” to the “predictive decision support interventions attestation” in § 170.315(b)(11)(v). We note that § 170.315(g)(3) “safety-enhanced design,” applies to the existing § 170.315(a)(9) criterion and in keeping with that applicability, we propose that safety-enhanced and user-centered design processes described in § 170.315(g)(3) would apply to the new certification criterion proposed in § 170.315(b)(11) as well. We propose to update § 170.315(g)(3) accordingly to reference the proposed § 170.315(b)(11). We believe that requiring developers of certified health IT to make available the source attributes information referenced at those sections via direct display, drill down, or link out from their certified Health IT Modules would have an important impact in enabling informed and appropriate selection of DSIs for implementation and use. Addressing quality uncertainty similarly underlies the rationale for certification of all Health IT Modules. We discuss proposed revisions and additions to source attributes later in this section. We invite comment on this proposal.
We propose to include as source attributes in § 170.315(b)(11)(vi)(A)(
We propose in § 170.315(b)(11)(vi)(A)(
We propose in § 170.315(b)(11)(vi)(A)(
We propose in § 170.315(b)(11)(vi)(A)(
Including the use of REL, Sexual Orientation, Gender Information, SDOH, and Health Status Assessment data elements as part of source attributes for each DSI, so that information about them can be provided to users, as proposed in § 170.315(b)(11)(vi), would greatly improve the possibility of identifying and mitigating the risks of employing both evidence-based and predictive DSIs for patient care, including those related to exacerbating racial disparities and promoting bias. We encourage readers to review the Background of this section, III.C.5, for more discussion and evidence for relevant examples of such risks. We invite comment on these additions to source attributes in § 170.315(b)(11)(vi)(A), and we invite
We propose in § 170.315(b)(11)(vi) that all source attribute information must be available, as applicable, for user review via direct display, drill down, or link out from the Health IT Module when the intervention is developed by the developer of the Health IT Module. The intent of this proposed requirement is to enable users to make a more informed decision regarding whether and how a DSI should be used. For example, an evidence-based DSI that is based on Joint National Committee (JNC) Hypertension guidelines should indicate for the user of the certified Health IT Module that the DSI output (recommendation) for the first-line hypertension therapy incorporates Race so that the user is aware that the DSI's recommendation for Black patients and non-Black patients differs. Historically, we have not made the expectation that source attribute information be available via drill down or link out an explicit requirement, but we required that such information be available to end-users for CDS interventions (77 FR 54215). We understand that source attribute information may be presented in varied ways at various points of workflow and contain varying levels of detail and do not intend to limit the options by which this information can be made available. However, through conversations with interested parties, we learned that source attribute information is not routinely available to users at the point of care, so we propose to require source attribute information be available at a minimum, via direct display, drill down, or link out now to better ensure consistency in source attributes information availability.
We encourage developers of certified health IT to consider a hierarchy of users' needs when making these attributes available for users. Consistent with prior ONC discussion related to existing § 170.315(a)(9)(v) requirements for source attributes (77 FR 54215), the proposal would not require the automatic display of source attributes information when a recommendation, alert, or decision support output is presented that resulted from a DSI. We invite comment on this proposal.
As stated in the previous section, we propose in § 170.315(b)(11)(vi) to establish “source attributes” requirements. In this section we discuss proposals to include additional source attributes for predictive DSIs as we propose to define them in § 170.102. Specifically, we propose to add new source attributes in § 170.315(b)(11)(vi)(C) for all predictive DSIs that are enabled by or interface with certified Health IT Modules certified to § 170.315(b)(11). These source attributes are intended to provide users with greater insight into the model incorporated into a particular predictive DSI and will provide information for an array of uses, including in support of so-called “model cards” or algorithm “nutrition labels” that have been described by others.
We believe additional transparency for predictive DSIs that enable or interface with Health IT Modules is appropriate because these DSIs often involve relatively opaque computational processes to arrive at the predictions on which such DSIs are based and rely on specific data and populations to learn relationships between features of the data. While the use of such models has enormous potential to improve many aspects of the healthcare delivery system including treatment, payment, health care operations (TPO); research; and public health activities, it can also result in harm, bias, or unlawful discrimination, as discussed earlier in this preamble in section III.C.5.a. This can be especially true in instances where the user is not fully informed of the potential limitations of the model, where there is potential misalignment between the user's application of the model and its intended use, where known inappropriate uses of the model are not communicated, or when the model is specified to accomplish known tasks without meeting the intended outcome.
In developing proposed source attributes for predictive DSIs, we sought to balance prescriptiveness and flexibility. Our selection of proposed attributes was guided by review of existing model reporting guidelines, including fourteen different sets of recommendations for information to be reported on models and related standards.
The proposals in § 170.315(b)(11)(vi)(C) would not require disclosing or sharing intellectual property (IP) existing in the developer's health IT (including other parties' intellectual property). For example, the proposed requirement would not require developers of certified health IT (or any other model developers, for example, models developed by third parties or customers of the developer of certified health IT) to provide information about or report any details of the specific code, pipeline, statistical processes, or algorithms used to generate model predictions, which might be considered the developer's intellectual property. Instead, the proposed requirement would have developers of certified health IT report source attribute information related to data that was used to train the model, the proper (intended) use of the model, and the performance of the model as assessed through validation and fairness metrics. In this regard, the proposed source attributes are intended to establish consistent categories of minimum information availability that potential users need to make informed decisions regarding their use of a predictive DSI. We view this proposal as complementary to transparency efforts in other areas for product users such as nutrition labels, medication fact labels, and clinical trial results, which also focus on inputs, demonstrated value, and proper use.
We propose to add fourteen new source attributes for predictive DSIs that enable or interface with Health IT Modules. These include attributes that describe the models (sources) on which predictive DSIs are based in four broad categories: in § 170.315(b)(11)(vi)(C)(
Consistent with our proposals in § 170.315(b)(11)(vi), we propose that these new source attributes listed in § 170.315(b)(11)(vi)(C) would be in plain language and available for user review via direct display, drill down, or link out from a Health IT Module certified to § 170.315(b)(11) and for which the developer attested “yes” in § 170.315(b)(11)(v)(A).
For six of the listed source attributes, we propose to include a phrase noting that information must be provided “if available.” These include source attributes we propose in § 170.315(b)(11)(vi)(C)(
We propose to require that information be provided for the remaining eight attributes that do not include the “if available” phrase, except as described in § 170.315(b)(11)(vi)(D). We note that developers of certified health IT that develop predictive DSIs for use in their Health IT Modules must provide this information and, if necessary, establish processes and protocols to generate or gather the eight attributes that do not include the “if available” phrase. We note that the eight attributes that do not include the “if available” phrase reflect information that is routinely generated during model planning, development, and testing. These attributes are often commonly reported in academic validation studies of predictive models in healthcare and relate to information readily available for model creators, developers, or owners to report to users or customers. However, we clarify that we are establishing two affirmative actions: (1) developers of certified health IT that develop their own predictive DSIs, that are enabled by or interface with a Health IT Module, must generate or gather the proposed source attribute information in § 170.315(b)(11)(vi)(C); and (2) report the proposed source attribute information.
We propose three source attributes related to details of predictive models and their proper use in § 170.315(b)(11)(vi)(C)(
• § 170.315(b)(11)(vi)(C)(
The output of the model is the predicted value of the `label' (outcome) that the model is trained on to make a prediction. An example would be to describe that the model is trained on patients labeled as either experiencing or not experiencing a readmission for heart failure within 30-days of initial discharge in training data where that event is known. The trained model would then produce as its output the likelihood that an individual will be readmitted among individuals recently discharged (for whom the event is not yet known). The absence of this information could greatly increase the risk that the model is misused or that its output is assumed to relate to something other than the label the model was trained to predict. Specifying the output allows users to determine if the output is appropriate or may inherently reflect low validity or bias because of concerns about the process that produces an output in the training data.
• § 170.315(b)(11)(vi)(C)(
A description of how the model should be used can inform how the model is deployed in healthcare settings and help assure users that the model is fit for the purpose they are using it for. The absence of this information could greatly increase the risk that the model is deployed or used in situations that the model developers did not intend and that may result in invalid predictions or harm to the intended beneficiaries (model subjects,
• § 170.315(b)(11)(vi)(C)(
We propose three source attributes related to model development in § 170.315(b)(11)(vi)(C)(
• § 170.315(b)(11)(vi)(C)(
The information listed above is similar to requirements for clinical trials to report information on the baseline data of the sample included in the trial. Beyond the information above, the description of this source attribute should include what data is expected to be present for the model to generate accurate predictions. This description should allow users to evaluate whether sufficient data is available for the model to make valid predictions.
Descriptions of training and test data could allow model users to ensure that the development data the model was trained on had sufficient patients similar to those for whom the model would be used to inform effective model predictions. Predictive models developed using datasets that are not broadly representative may learn relationships applicable only to some groups. Those models are then likely to perform well only within those groups. For example, models predicting heart attack onset trained on data containing few women may perform poorly because diagnostic patterns are different for women.
• § 170.315(b)(11)(vi)(C)(
This description should include approaches to manage, reduce, or eliminate bias in models and could be similar to a brief synopsis of risk mitigation practices and outcomes related to fairness for this DSI, as described further in the intervention risk management practices proposed in § 170.315(b)(11)(vii)(A)(
• § 170.315(b)(11)(vi)(C)(
A description of the external validation process undertaken can allow users to consider how well the model has been shown to perform, and in particular, how well it performs in similar settings as presented by independent parties.
We propose five source attributes relevant to validation or evaluation of the performance (including accuracy, validity, and fairness) of the predictive model and evaluation of its effectiveness in § 170.315(b)(11)(vi)(C)(
• § 170.315(b)(11)(vi)(C)(
Selection of measures should be guided by the model developer's consideration of what measures might be most meaningful and relevant to users of the model according to the expected use of the model and the technical knowledge of expected users and implementation teams. For example, sensitivity, specificity, and positive predictive values—which are generally familiar to clinicians through experience with diagnostic tests—might be preferred versus area under the receiver operator curve and area under the precision-recall curve for binary classifiers, which less directly relate to the performance of models as implemented at specific thresholds.
This proposal would not prescribe the specific performance or validation measures to be used or included as part of the source attributes requirements but would require that some performance or validation measure(s) be used and included in the source attribute. Numerous measures exist to measure validity and performance because of the variety of types of predictive models, their outputs, and intended uses. It is likely that selection of informative performance measures would depend on model type and task (
Information on the model's measured performance is important to users for determining how much weight to apply to its prediction, given that predictive DSIs are based on models and data that they have learned from and generally do not rely on clinical guidelines to support the model's decision-making, as discussed earlier in this section and in the definition of predictive DSI proposed in § 170.102.
• § 170.315(b)(11)(vi)(C)(
Evaluation of the fairness of models is one essential component in ensuring that models are not producing biased predictions or resulting in biased impacts to individuals. Numerous approaches and related measures exist to measure the fairness of model outputs. Examples of potential fairness measures include positive predictive parity, false positive error rate balance and false negative error rate balance, equivalent calibration within groups, and mean residual difference. The relevant groups or factors across which fairness should be established are also likely to vary from one model to the next, and model developers would need to determine which factor their model's performance should be evaluated or stratified by. Likely candidates include but are not limited to race, ethnicity, preferred language, sex, gender information, sexual orientation, religion, age, national origin, disability, veteran status, and genetic information or additional information related to care that has historically been stigmatized such as reproductive or behavioral health information.
• § 170.315(b)(11)(vi)(C)(
• § 170.315(b)(11)(vi)(C)(
• § 170.315(b)(11)(vi)(C)(
Although it is important to assess a model's performance and fairness, the best indicator of whether and how the model should be used will come from evidence of its impact on health outcomes and other goals (
We propose three source attributes related to the “ongoing maintenance of intervention implementation and use,” in § 170.315(b)(11)(vi)(C)(
• § 170.315(b)(11)(vi)(C)(
• § 170.315(b)(11)(vi)(C)(
• § 170.315(b)(11)(vi)(C)(
We believe these proposed additional source attributes are necessary to enhance information transparency about the fairness, appropriateness, validity, effectiveness, and safety of predictive DSIs, so that users can make informed decisions about their application and use. As noted above, we have sought a balance between limited prescriptiveness and sufficient detail to enable robust and broadly applicable reporting of information on source attributes to users. We request comment on whether there are items contained within the proposals described above that we should explicitly require as elements of source attributes information. In particular, we request comment on whether to divide the proposed “intended use” source attribute in § 170.315(b)(11)(vi)(C)(
Because the proposed source attributes described here and the intervention risk analysis and mitigation practices proposed in § 170.315(b)(11)(vii)(A) cover closely related topics, such as processes and measures related to fairness and validity, it is likely that some of the information used to provide descriptions of source attributes, would be substantially similar or identical to information the developer of certified health IT uses to describe their IRM practices as described later in § 170.315(b)(11)(vii). In particular, this may be the case with information related to the “Process used to ensure fairness in development of the intervention” proposed in § 170.315(b)(11)(vi)(C)(
In this proposed rulemaking, we are also considering requirements that would enable a user to review via direct display, drill down, or link out from the Health IT Module additional source attributes beyond the fourteen attributes proposed and discussed above. Some of these additional attributes relate to facets of intervention risk management practices in § 170.315(b)(11)(vii), as discussed in section III.C.5.c.x. There are many voluntary reporting guidelines developed by industry, academia, and other interested parties designed to facilitate evaluation of predictive models, their output, and in some cases their impact, and the relevance of results of those evaluations to specific contexts, patients, and clinical decisions. However, these reporting guidelines do not uniformly highlight the same type of information to make available about a model. Based on our review of available literature and documentation, interested party input, and in consultation with the Agency for Healthcare Research and Quality (AHRQ) and Food and Drug Administration (FDA), we believe that the following additional source attributes could help achieve our stated objectives, and we are considering requiring certified Health IT Modules to enable a user to review information about these additional source attributes via direct display, drill down, or link out from the certified Health IT Module, consistent with proposed requirements in § 170.315(b)(11)(vi):
• Information on the explainability (defined as the ability to explain a `black box' model, often through the use of a second model),
• Information on whether a DSI meets the definition of a medical device under the FDA definition according to an internal review or because it has been reviewed by FDA in a premarket submission;
• Any known ethical considerations related to data acquisition and use (
• Specifics on the source of the output or information presented through the DSI, including whether it was derived from meta-analysis, other synthesis of clinical studies, statistical modeling, AI/ML techniques, or some other method, and details on the type of model used, and model-building procedures;
• Details on how model prediction and classification cut-points were selected relative to defined outcomes (
• Security and privacy-preserving approaches included in model development (
• List of data elements or data classes used in the model and how they were used in the model in terms of categories or transformation;
• Model verification, usually associated with simulation models and defined as the process of confirming through the provision of objective evidence that specified requirements have been fulfilled and that model implementation accurately represents the developer's conceptual description of the model (which may reflect information in the intended use of the intervention and output of the intervention source attributes) and its solution;
• Model calibration or calibration curve, which represent the relationship between predicted values generated by the model and observed probabilities;
• Confidence intervals or other measures of uncertainty related to measures of performance, fairness, and effectiveness, which would provide more information on the precision of evaluations and assure users that reported performance was unlikely to have been achieved by chance;
• Model reliability, using reliability to mean the “ability of an item to perform as required, without failure, for a given time interval, under given conditions.”
• Prediction intervals or other measures of uncertainty around the prediction generated, which would help inform users of the precision of a given prediction and whether the true value may vary widely or narrowly from the predicted estimate;
• Information on data quality and completeness,
• Whether the model incorporates data generated from the setting it has been deployed in and uses it to update the model in real-time, sometimes referred to as a model being `online' or `unlocked'.
• For online or unlocked models, any additional organizational or technical controls in place to evaluate the impact of the online or unlocked updating and results of that evaluation.
• For online or unlocked models, the controls in place to update the descriptions of source data to reflect the changing composition of the data.
We are soliciting comments in this proposed rulemaking on whether we should require developers of certified health IT with Health IT Modules certified to proposed § 170.315(b)(11) to make all source attributes information in the proposed § 170.315(b)(11)(vi) publicly available or accessible, for example, on a website, similar to the existing API documentation requirement in § 170.315(g)(10)(viii)(B). We are considering whether the public availability of this information is necessary to effectively improve the emerging market for predictive DSIs, or is necessary to ensure public confidence in predictive DSIs by enabling research use of source attribute information. For example, without this information, certified health IT purchasers (
We welcome comment on whether we should require a certain format or order in which these attributes must appear to users. We note that we are presenting these source attributes here in preamble and in proposed regulation text according to how a developer may encounter them as part of the software or product development life cycle. We are not aware of widely agreed upon best practices for the format in which these elements or source attributes information should be displayed. However, we are aware of industry efforts to standardize a format to display information about technology in the form of a “model card” or “nutritional label” for healthcare.
We solicit feedback on additional opportunities to help bring algorithmic transparency and improved trustworthiness in health IT design, development, and implementation as well as user needs for the procurement, implementation, and use of such technology. We are aware of a growing trend in industry and academia aiming to identify and address various algorithmic biases through audits.
We understand that any data used by developers of certified health IT and other parties in the development of DSIs should be used in ways that balance data use interests with patients' interests. For example, model developers should use data for training and testing consistent with applicable law, patients' expectations, and any patient consent or preference given. We invite the public to read section III.C.5.c.xi of this proposed rule for the discussion about data collection and use. We are aware that digital and algorithmic literacy is important, including to help detect and mitigate bias. In turn, potential subjects (patients) of automated decisions could benefit from information about how these technologies function and are used in healthcare.
Patients want to know if AI is being used in their care, and understand how and why it is being used in their care.
We believe that source attributes proposed in § 170.315(b)(11)(vi)(A), (B), and (C) are foundational for users' understanding of the DSI regardless of whether the intervention developer is a developer of certified health IT, a customer of the developer of certified health IT, an academic health system, integrated delivery network, a third-party software developer, or other party. This belief underpins our proposed requirements in § 170.315(b)(11)(vi) that certified Health IT Modules enable a user to review a plain language description of all source attribute information in § 170.315(b)(11)(vi)(A) through (C) via direct display, drill down, or link out. However, as discussed previously, we understand there may be circumstances where a developer of certified health IT may not have information pertaining to a source attribute for a Health IT Module to enable such user review. We, therefore, propose in § 170.315(b)(11)(vi)(D) that a certified Health IT Module must clearly indicate when a source attribute listed in § 170.315(b)(11)(vi)(A), (B), and (C), as applicable, is not available for the user to review, including two specific circumstances. First, we propose in § 170.315(b)(11)(vi)(D)(
We clarify that “other parties,” in § 170.315(b)(11)(vi)(D)(
We reiterate that while we do not prescribe how a certified Health IT Module must indicate that an attribute is missing, we clarify that the certified Health IT Module must communicate an attribute is missing unambiguously and in a conspicuous manner to a user. We note that these “other parties” may or may not have a contractual relationship with the developer of certified health IT. However, we seek comment on whether we should require developers of certified health IT with Health IT Modules that enable or interface with predictive DSIs to display source attributes for other parties with which the developer of certified health IT has a contractual relationship.
When predictive DSIs are developed by other parties, rather than the developer of the certified Health IT Module, we recognize that it may not be feasible for developers of certified health IT to have access to or possess information about each source attribute required in § 170.315(b)(11)(vi)(C), available for user review. Therefore, we propose to allow developers of certified health IT with Health IT Modules that enable or interface with predictive DSIs that are developed by other parties to clearly indicate when any source attribute information is not available for user review. Consistent with prior discussion regarding third-party developed evidence-based DSIs (77 FR 54215), we anticipate that developers of certified health IT would obtain information on the predictive DSI from the model developers, owners, or creators in most instances. This is consistent with what we have historically expected, noting in the 2014 Edition Proposed Rule that it would be the third party from which the developer of certified health IT would get this information (77 FR 54215). We also noted in the 2014 Edition Proposed Rule that “The absence of [bibliographic] information is . . . valuable information and may (or may not) cause the [user] to heed or ignore the guidance. Note that our goal here is not to assess the quality or evidence basis of decision support, but to enable the [user] to do so.” We also stated, “In cases where [funding source] information is unknown, then the [user] should have access to the fact that this information is unknown” (77 FR 54215).
We believe that indicating the absence of information on source attributes would provide an important signal to users that the model may not have been rigorously developed and evaluated. This signal would provide motivation to developers to perform the tasks necessary to generate information relevant to each source attribute and to provide that information to health IT developers of certified health IT or their customers for incorporation into the source attributes information about the model to be made available for user review as discussed earlier in the section and proposed in § 170.315(b)(11)(vi). We invite comment on these proposals.
We are aware of some standards related to DSIs, such as CDS Hooks v1.0, that could invoke decision support from within a clinician's workflow, and that include a source attribute field designed to include URLs to relevant supporting documentation.
We propose in § 170.315(b)(11)(vi)(E) that Health IT Modules certified to § 170.315(b)(11) support the ability for a limited set of identified users to author (
As previously noted, multiple reporting guidelines exist for predictive
In the previous sections, we propose that developers of certified health IT would make source attributes available for DSIs their Health IT Modules enable or interface with. We are aware that several technical architectures exist to provide outputs of predictive and evidence-based models to certified health IT or otherwise use these models as the back-end of DSIs that are subsequently delivered through a certified product.
We request comment on whether developers of certified health IT would be able to differentiate clearly between other-party DSIs that they implement into their Health IT Modules and make available to their customers versus those other-party products that their customers purchase, develop, or otherwise integrate without direct involvement of the developer of certified health IT.
We propose in § 170.315(b)(11)(vii) to establish “intervention risk management” requirements. We propose to require in § 170.315(b)(11)(vii) that by December 31, 2024, a developer of certified health IT that attests “yes” in § 170.315(b)(11)(v)(A) employs or engages in the following IRM practices for all predictive decision support interventions, as defined in § 170.102, that the developer's certified Health IT Module enables or interfaces with:
• In § 170.315(b)(11)(vii)(A)(
• In § 170.315(b)(11)(vii)(A)(
• In § 170.315(b)(11)(vi)(A)(
We propose in § 170.315(b)(11)(vii)(B) that developers of certified health IT compile detailed documentation of intervention risk management practices listed in § 170.315(b)(11)(vii)(A) and upon request from ONC make available such detailed documentation for any predictive DSI that their certified Health IT Module enables or interfaces with. We also propose in § 170.315(b)(11)(vii)(C) to require developers of certified health IT to submit summary information to their ONC-ACB regarding IRM practices listed in proposed § 170.315(b)(11)(vii)(A) via publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps. Consistent with Program implementation for similar documentation requirements (84 FR 7484), we clarify that for this proposed summary information in § 170.315(b)(11)(vii)(C), the required documentation would need to be submitted to ONC-ACBs for review prior to issuing a certification.
Finally, we propose in § 170.315(b)(11)(vii)(D) to require that developers of certified health IT review annually and, as necessary, update both detailed documentation and summary information. We propose in § 170.315(b)(11)(vii) to establish a deadline of December 31, 2024, for developers of certified health IT with Health IT Modules to which the proposed requirements in that section apply to engage in intervention risk management practices and develop both detailed documentation and summary information. This proposed deadline corresponds with our proposal in § 170.315(a)(9)(vi) and supports our proposal to update the Base EHR definition in § 170.102, as discussed in section III.C.5.c.xii.
Model development is not a straightforward or routine technical process. The experience and judgment of developers, as much as their technical knowledge, greatly influence the appropriate selection of inputs and processing components. The training and experience of developers exercising such judgment affects the extent of model risk. In addition, even with skilled modeling and robust validation, model risk cannot be eliminated, so other tools should be used to manage model risk effectively. Among these are establishing limits on model use, monitoring model performance, adjusting or revising models over time, and supplementing model results with
Overall, the proposals in § 170.315(b)(11)(vii)(A) are intended to promote the management of risks in pursuit of predictive DSI trustworthiness. Trustworthy predictive DSIs, models that are FAVES, mitigate risks and contribute to benefits for people, organizations, and systems. Trustworthy predictive DSIs should achieve a high degree of control over risk while retaining a high level of performance quality. Achieving this goal requires a comprehensive approach to intervention risk management. Risk management can drive developers and users to understand and account for the inherent uncertainties and inaccuracies in their models and systems, which in turn can improve their overall performance and trustworthiness.
We note that a central component of effective risk management lies in a clear acknowledgment that risk mitigation, rather than risk avoidance, is often the most effective factor in managing such risks.
Given a lack of healthcare sector-specific guidance and the nascency of several emerging efforts for risk management of predictive software, our proposals in § 170.315(b)(11)(vii)(A) would not require a specific framework, guideline, or approach that such developers of certified health IT must use—only that they employ or engage in IRM practices in accordance with proposed requirements in § 170.315(b)(11)(vii)(A) through (D). In the proposals and related preamble, we have sought a balance between prescriptiveness and sufficient description to enable robust reporting of information on IRM practices. Within this preamble, we have described several items that we believe are best practices. We request comment on whether there are best practices or other items contained within the proposals in § 170.315(b)(11)(vii)(A) that should be explicitly required. We invite comment on the proposals in § 170.315(b)(11)(vii)(A) to require developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) and that attest “Yes” in accordance with our proposal in § 170.315(b)(11)(v)(A) to employ or engage in IRM practices for all predictive DSIs that their certified Health IT Modules enable or interface with, without being prescriptive as to how such practices must be carried out.
We view our proposals for risk management of predictive DSIs in § 170.315(b)(11)(vii) as complementary to our proposals for predictive DSI source attributes in § 170.315(b)(11)(vi)(C). The proposed source attributes information requirement is meant to provide users and implementers with sufficient information to understand how the model was designed, developed, and tested, including the model's purpose, known limitations, and intended use(s). Correspondingly, the proposals for intervention risk management would provide users, implementers, and the wider public, including patients, with information to understand how developers of certified health IT with Health IT Modules that enable or interface with predictive DSIs analyze, mitigate, and govern risks throughout the technology's life cycle. We anticipate that these actions would dramatically increase the likelihood that a predictive DSI, enabled by or interfaced with a certified Health IT Module, is FAVES by providing information transparency regarding how risks to individuals, groups, communities, organizations, and society would be managed more effectively, consistent with best practices.
Together, our proposals for predictive DSI-specific source attributes and IRM practices information are intended to help guide medical decisions at the time and place of care, consistent with 42 U.S.C. 300jj-11(b)(4). Beyond the application of predictive DSI-specific source attributes and IRM practices information to an episode of care, for example, we believe such transparency would also foster confidence and trust among interested parties that the technical and organization processes used in designing and developing the predictive DSI were FAVES and high-quality. Finally, we anticipate these proposed requirements would help developers of certified health IT, themselves, know if a predictive DSI that their certified Health IT Module enables or interfaces with is FAVES, and then show to their customers and the wider public that they support high-quality predictive DSIs, thus improving user and public trust in the technology.
In § 170.315(b)(11)(vii)(A), we propose that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) employ or engage in “risk analysis,” “risk mitigation,” and “governance,” IRM practices for all predictive DSIs, as proposed to be defined in § 170.102, that the certified Health IT Module enables or interfaces with.
For purposes of proposed § 170.315(b)(11)(vii), we define “risk” as a measure of the extent to which an
We believe that many such developers of certified health IT already employ or engage in IRM practices, thus, the proposed requirement to provide information on these practices in (b)(11)(vi)(B) and (C) represent a low-level of burden. However, we propose to make explicit our expectations that to provide the proposed information, such developers of certified health IT must “employ or engage” in IRM practices in § 170.315(b)(11)(vi)(A). We view the proposal in § 170.315(b)(11)(vii)(A) as similar to existing Program requirements in § 170.315(g)(3) safety-enhanced design (SED) and § 170.315(g)(4) Quality management systems (QMS), and we propose the requirements in § 170.315(b)(11)(vii) for similar reasons that we adopted the SED and QMS criteria (77 FR 13843). First, all developers of certified health IT that seek certification to § 170.315(b)(11) and have certified Health IT Modules that enable or interface with predictive DSIs would become familiar with foundational IRM practices if not already familiar; second, the public disclosure of the summary information of IRM practices employed or engaged by the developer of certified health IT, as described further below, would provide transparency to purchasers (potential users), users, and other interested parties, and contribute to appropriate information to help guide medical decisions; and lastly, our proposals in § 170.315(b)(11)(vii)(A) would encourage development of healthcare-specific, consensus and industry-based best practices for risk management.
In § 170.315(b)(11)(vii)(A)(
We have adapted these emphasis areas, and we propose that such developers of certified health IT analyze risks related to the lack or failure of validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy. Consistent with the NIST AI RMF, we encourage developers of certified health IT to include the following in their analysis: (1) estimates of the likelihood and magnitude of the negative impact (harm), or consequences, of each risk; (2) to whom each risk applies (including, for example, individual, group, and societal harm); and (3) the source of each risk. In addition to assessing and measuring the magnitude of the risk, we encourage developers of certified health IT to identify who is accountable for any negative impact potentially resulting from the outcome of the risk if it is realized.
It is likely that some of the information used to identify risk would be substantially similar or identical to the information provided as source attributes proposed in § 170.315(b)(11)(vi). As examples, analysis of validity, fairness, and safety may be important processes in development of source attributes and risk analysis such that the two proposals are closely aligned. Developers of certified health IT should consider risk from individual predictive DSIs and in the aggregate. Aggregate risk is affected by interaction and dependencies among models; reliance on common assumptions, data, or methodologies; and any other factors that could adversely affect several DSIs and their outputs at the same time.
Analyzing risk is a continual process that should begin in the initial concept and design phase of the predictive DSI and continue through its development, deployment and full period of use, as the technology should be responsive to new risks as they occur. Health IT developers may use model risk assessments to help determine the types, frequency, and extent of evaluation activities necessary to assess risk. Information on these evaluation activities may be useful in presenting proposed source attributes information describing the “process used to ensure fairness in development of the intervention” in § 170.315(b)(11)(vi)(C)(
We do not propose or describe risk tolerance associated with the eight characteristics, as we believe these should be decisions made by those involved with the design, development, deployment, and use of the technology. We propose that developers of certified health IT must analyze the potential risks and adverse impacts, associated with a predictive DSI that their certified Health IT Modules enable or interface with, related to lack or failure in the following characteristics:
• “Validity,” as discussed earlier in section III.C.5.b of this proposed rule in the proposal for source attributes in § 170.315(b)(11)(vi)(C), of models used as sources for predictive DSIs can be assessed using technical characteristics. “Validity” for deployed predictive DSIs is often assessed with ongoing testing or monitoring that confirms a system is performing as intended (similar to the description of the source attributes related to “Ongoing Maintenance of Intervention Implementation and Use,” in section III.C.5.b of this proposed rule).
○ Validation of the accuracy and completeness of data used in development and testing of the predictive DSI;
○ Evaluation plans and results for validation in testing environments and ongoing evaluation in deployment;
○ Both technical validity and clinical validity, which is closely related to measurement of effectiveness such as those discussed in the proposed source attribute “References to evaluation of use of the model on outcomes” in § 170.315(b)(11)(vi)(C)(
• “Reliability” indicates whether a model used in a predictive DSI consistently performs as required, without failure, for a given time interval, under given conditions.
• “Robustness” or generalizability is the ability of a model used in a predictive DSI to maintain its level of performance under a variety of circumstances.
• “Fairness,” as noted above in this section, is defined by a lack of bias against certain groups, and fairness enhancing (or bias managing) processes seek to ensure that models are fair. This includes addressing concerns for equality and equity by addressing issues such as bias and unlawful discrimination. NIST has identified three major categories of AI bias that should be addressed and managed to enhance fairness of models: systemic, computational and statistical, and human-cognitive. In the analysis of potential risks, an approach should consider all three categories of bias and report results of evaluations of those categories in both testing and deployed environments.
• “Intelligibility” refers to the extent to which the predictive DSI can be understood, often through a representation of the mechanisms underlying an algorithm's operation and through the meaning of AI systems' output in the context of its designed functional purpose. Generally, perceptions of risk related to intelligibility stem from concerns that unintelligible models, which produce output that is difficult to make sense of or contextualize, may lead to inappropriate interpretation or use of the decision support. Risks from ambiguity on the mechanisms underlying operation can be managed by clear descriptions of how models work. Risks from an ambiguity in output in the context of functional purpose can often be addressed by communicating a description of why the predictive DSI or other systems made a particular prediction or recommendation.
• “Safety” as a concept is highly correlated with risk and generally denotes that the product is free from any unacceptable risks and the probable benefits outweigh any probable risk.
• “Security” (and relatedly resilience) is a predictive DSI's and model's ability to withstand adversarial attacks, or more generally, unexpected changes in its environment or use, including not only those related to the provenance of the
• “Privacy” refers generally to the norms and practices that help to safeguard human autonomy, identity, and dignity,
Consistent with our proposed requirement in § 170.315(b)(11)(vii), summary information of the risk analysis IRM practices, as proposed in § 170.315(b)(11)(vii)(C), must be made available by December 31, 2024.
We seek comments on these proposals and on related tools and frameworks to support this area in healthcare, including those tools that help identify observable indicators of risks.
We propose in § 170.315(b)(11)(vii)(A)(
Risk mitigation practices implemented by developers of certified health IT should cover the following:
•
•
•
•
•
We seek comments on these proposals.
We propose in § 170.315(b)(11)(vii)(A)(
We believe that governance sets an effective framework for risk management, with defined roles and responsibilities for clear communication of a predictive DSI's limitations and assumptions.
Our use of the term “policies” means statements of management intent regarding the objectives and required components of intervention risk management. Our use of the term “controls” means a system of internal controls that the developer has in place to implement the associated risk management policies, including those at the organizational and technology level (
Developers of certified health IT would have the flexibility to choose an approach to meeting this proposed requirement that addresses their own unique circumstances for their predictive DSIs. However, we encourage developers to implement policies and controls to evaluate whether risk analysis and risk mitigation practices are being carried out as specified; to consider how policies and controls are monitored and updated; and to plan a schedule for updating those policies and controls. Policies and controls should include details on roles, responsibilities, staff expertise, authority, reporting lines, and continuity. We further encourage developers to have accountability and escalation policies and controls related to how management oversees the development, deployment, and management of predictive DSIs. These policies should describe the developer of certified health IT's decision-making parameters and include how management is held accountable for the impact of predictive DSIs.
We propose to require that the governance policies and controls developers of certified health IT implement relate to how they acquire, manage, and use data in predictive DSIs.
We strive to create systemic improvements in health and care through access, exchange, and use of data to have better health enabled by data. There are risks associated with data use across the predictive DSI life cycle. Our use of the terms “acquired,” “managed,” and “used” are intended to describe the stages of data governance. As data is acquired, there should be rigorous assessment of data quality and relevance, and appropriate documentation. Developers of certified health IT should be able to demonstrate that such data and information are suitable for the predictive DSI, and that they are consistent with the theory behind the approach and with the chosen methodology. As part of data management, the use of data proxies should be carefully identified, justified, and documented. If data and information are not representative of the developer's customer base or other characteristics, or if assumptions are made to adjust the data and information, these factors should be properly tracked and analyzed. This is particularly important for external data and information (from a vendor or outside party), especially as they relate to new products or activities.
Developers of certified health IT have the flexibility to choose an approach to meeting this proposed requirement that addresses their own unique circumstances and risks for their predictive DSIs but may wish to examine industry data governance, data management, data stewardship, data ethics, or responsible use of data resources to determine if they are relevant and useful in their own implementation efforts.
In such circumstances, the proposed requirement for developers of certified health IT to employ or engage in intervention risk management practices in § 170.315(b)(11)(vii) includes determining whether or not the other party has engaged in risk management practices, such as through review of risk analysis, risk mitigation, and governance information from the other party. Consistent with previous discussions in this proposed rule regarding the availability of source attribute information for predictive DSIs developed by other parties, we expect those other parties to also provide the developer of certified health IT with relevant intervention risk management information so that such information may be available for both detailed and summary documentation in § 170.315(b)(11)(vii)(B) and § 170.315(b)(11)(vii)(C), respectively. We invite comments on this proposal and ways in which developers of certified health IT can best determine that intervention risk management practices have been conducted for all predictive DSIs that their Health IT Module enables or interfaces with, including those predictive DSIs developed by other parties.
We believe requiring the proposed IRM practices in § 170.315(b)(11)(vii) are necessary to enhance the transparency of predictive DSIs, and thus improve their capacity to be evaluated and their utility to healthcare professionals and patients. We have sought a balance between limited prescriptiveness and sufficient detail to enable robust and broadly applicable reporting of information on risk management practices to users. We request comment on whether there are items contained within the proposals described above that we should explicitly require as elements of the overall IRM practices in these proposals. We invite comments on this proposal, and we seek comment on whether these proposed requirements should include more specificity, and what actions developers of certified health IT should take to mitigate potential discriminatory outcomes of predictive DSIs.
In § 170.315(b)(11)(vii)(B), we propose that a health IT developer that attests “yes” in § 170.315(b)(11)(v)(A) must compile detailed documentation regarding IRM practices listed in § 170.315(b)(11)(vii)(A) and upon request from ONC make available such detailed documentation to ONC for any predictive decision support intervention, as defined in § 170.102, that the certified Health IT Module enables or interfaces with. We believe that a developer of certified health IT subject to this proposed requirement should be able to provide detailed documentation of their IRM practices, if ONC requests such information, without much effort because this information should be a byproduct of employing or engaging in IRM practices in § 170.315(b)(11)(vii)(A). While ONC has the authority to conduct Direct Review consistent with § 170.580(a)(2), for any known non-conformity or where it has a reasonable belief that a non-conformity exists, this proposal would
We clarify that “detailed documentation” is documentation that is specific to an individual predictive DSI enabled by or interfaced with a developer of certified health IT's Health IT Module, and we clarify that this documentation should be sufficiently detailed so that we are able to review, minimally, the IRM practices enumerated in § 170.315(b)(11)(vii)(A)(
As discussed below, our proposals in § 170.315(b)(vii)(C) describe what summary information we would require a health IT developer that attests “yes” in § 170.315(b)(11)(v)(A) must make publicly accessible. With respect to the detailed documentation regarding IRM practices that we propose to require be submitted to ONC upon request in § 170.315(b)(11)(vii)(B), we understand that health IT developers may have concerns regarding the disclosure of proprietary, trade secret, competitively sensitive, or other confidential information. ONC would implement appropriate safeguards to ensure, to the extent permitted by federal law, that any proprietary business information or trade secrets ONC may encounter by accessing the health IT developer's detailed documentation, other information, or technology, would be kept confidential by ONC or any third parties working on behalf of ONC in its performance of oversight responsibilities to determine compliance under the Program. However, a health IT developer would not be able to avoid providing ONC access to relevant, detailed documentation by asserting that such access would require it to disclose trade secrets or other proprietary or confidential information. Therefore, similar to our statements in the ONC Cures Act Proposed Rule (84 FR 7504), ONC Cures Act Final Rule (85 FR 25785), and the EOA Final Rule (81 FR 72431), we recommend health IT developers clearly mark, as described in HHS Freedom of Information Act regulations at 45 CFR part 5, subparts C and D, any information they regard as trade secret or confidential prior to disclosing the information to ONC. We solicit comment on this proposal.
Further, we solicit comment on whether existing Program requirements as part of the Communications condition and maintenance of certification requirements in § 170.403 are sufficient to enable open and transparent discussion, including between developers of certified health IT and users (customers) regarding IRM practices related to predictive DSIs.
We propose in § 170.315(b)(11)(vii)(C) that a health IT developer that attests “yes” in § 170.315(b)(11)(v)(A) must submit summary information of the IRM practices listed in § 170.315(b)(11)(vii)(A)(
We reiterate our proposal in § 170.315(b)(11)(vii) which would require that this summary information be made available to ONC-ACBs via publicly accessible hyperlink prior to the deadline of December 31, 2024, if finalized as proposed.
We believe that multiple interested parties, including clinicians, health systems, patients, academia, policymakers, the public, and the health IT industry would benefit from having generalized information regarding how developers of certified health IT manage risk related to the predictive DSIs that are enabled by or interfaced with their certified Health IT Modules. Clinicians, patients, health systems, and the public could use this information to bolster their trust in the developers of certified health IT and those certified Health IT Modules that enable or interface with predictive DSIs.
“Summary information” should describe risk management practices, enumerated in § 170.315(b)(11)(vii)(A)(
We note that “summary information,” is not specific to any single predictive DSI, like the availability of detailed documentation proposed in § 170.315(b)(11)(vii)(B). Rather, the information would pertain to the suite or portfolio of predictive DSIs enabled by or interfaced with the certified Health IT Module. We note that the summary information would likely encompass variation in risk management practices for different kinds of predictive DSIs. For instance, we expect that some risk management practices would be different for predictive DSIs developed by the developer of certified health IT; predictive DSIs developed by other parties with whom the developer of certified health IT has contracted or otherwise formally engaged with to provide predictive DSIs that are enabled by or interfaced with the Health IT Module; and for predictive DSIs developed or created by the developer of certified health IT's customers and interfaced with the Health IT Module, potentially without the developer of certified health IT's formal involvement. Summary information must encompass this variation, to the extent it is present.
We clarify that summary information should be easily understood by interested parties. By easily understandable, we mean the following. The information describes, in general terms, how the developer of certified health IT manages various kinds of risk related to predictive DSIs that their Health IT Module enables or interfaces with. In deciding on the level of detail to include in the summary information, developers of certified health IT should include plain language descriptions of the developer's IRM practices that are sufficient for potential customers or users of the predictive DSIs to understand the goals of the health IT developer's risk management practices as proposed in § 170.315(b)(11)(vii)(A)(
Similar to our policy associated with the API-focused certification criteria in § 170.315(g)(10)(viii)(B), we propose that all IRM documentation in § 170.315(b)(11)(vii)(C) be available via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps. For example, the developer of certified health IT may not impose any access requirements, including, without limitation, any form of registration, account creation, “click-through” agreements, or requirements to provide contact details or other information prior to accessing the documentation. We clarify that for the proposed IRM documentation in § 170.315(b)(11)(vii)(C), summary information would need to be submitted to the developer of certified health IT's ONC-ACB for review prior to issuing a certification. The availability of documentation as part of the certification process is also consistent with existing requirements for API documentation in § 170.315(g)(10)(viii)(B) (84 FR 7484).
To support submission of documentation, and consistent with other Principles of Proper Conduct in § 170.523(f)(1), we propose a new Principle of Proper Conduct for documentation in § 170.315(b)(11)(vii)(C). We propose in § 170.523(f)(1)(xxi) that ONC-ACBs report the information required in § 170.315(b)(11)(vii)(C) on the CHPL for the applicable certified Health IT Modules. We believe this new Principle of Proper Conduct will assist in promoting greater transparency for the Program and will strengthen ONC-ACB oversight regarding IRM documentation.
We invite comments on this proposal, and we seek comment on whether the requirement for summary information should include more specificity and detail.
Finally, we propose in § 170.315(b)(11)(vi)(D) to require developers of certified health IT that attest “yes” in § 170.315(b)(11)(v)(A) to review annually and, as necessary, update the documentation described in § 170.315(b)(11)(vii)(B) and § 170.315(b)(11)(vii)(C). This provision would apply to both detailed documentation compiled as part of proposed § 170.315(b)(11)(vii)(B) and summary information submitted to ONC-ACBs via publicly accessible hyperlink as part of proposed § 170.315(b)(11)(vii)(C). As stated previously, we view the detailed documentation required in § 170.315(b)(11)(vii)(B) as being a by-product of the proposed requirement for the developer of certified health IT to engage or employ in IRM practices. Thus, we expect that developers of certified health IT subject to this proposed requirement would review documentation associated with their IRM practices annually and, as necessary, update their documentation. Further, we believe that developers of certified health IT that attest “yes” in § 170.315(b)(11)(v)(A) should consider risk as part of ongoing development cycles, and these risks should be assessed in a timely manner so that risk analysis documentation is up to date. Similar to the HIPAA Security Rule,
We believe an annual review establishes a minimum expectation for updating IRM documentation, and we believe it is good practice that predictive DSIs undergo a full validation process at some fixed interval, including updated documentation of all related activities. While we are not proposing more frequent reviews, those may be appropriate for developers of certified health IT that have Health IT Modules that enable or interface with numerous or complex predictive DSIs. We invite comment on this proposal.
We are aware that, in addition to developers of certified health IT, users, such as healthcare organizations and clinicians, have responsibilities related to FAVES DSIs, including intervention or model risk management during implementation and use, as well as model validation. For example, we believe it is important that users maintain strong governance and controls to help manage model risk and how they will use outputs from interventions in decision-making, including monitoring any potential impacts of model use. Users of a predictive DSI are also best able to report on how the predictive DSI performs in real-world and local settings (which can differ from their performance during testing). We have observed emerging frameworks for the oversight of predictive DSIs.
We seek input on any information that the Department can use or action the Department should consider taking to ensure that implementation and use of FAVES DSIs are seen as a shared responsibility across developers of certified health IT and their customers. By shared responsibility, we mean that determination that a predictive DSI is FAVES requires an ongoing process beginning during initial model development and continuing through deployment, active use of the predictive DSI in practice and continued monitoring throughout that use.
We also seek input on any information the Department should consider or action the Department should consider taking to facilitate healthcare organizations and clinicians having the necessary competencies or expertise to assess whether a predictive DSI is trustworthy, in that the model is FAVES. This would be in addition to the information transparency (disclosures) that the proposed requirements would provide users, should those proposals be finalized. We seek input on any information commenters can offer on these topics. We understand that some aspects of predictive DSI should be familiar to clinicians and healthcare organizations because they parallel diagnostic tests and long-used risk calculators, but that other competencies may be novel and challenging. We seek input on activities, such as support for, establishment of, and dissemination of learning collaboratives, best practices, `playbooks,' or other approaches that the Department might pursue to facilitate users of certified health IT being well-equipped to determine whether predictive DSIs applied in their settings and to their patients are trustworthy.
We are aware of concerns about ELSI considerations regarding the initial or underlying data collection (sharing), data use (processing, analysis), and future (downstream) use or reuse of data,
The HIPAA Privacy Rule identifies the purposes for which PHI may be used and disclosed by covered entities and their business associates without an individual's authorization, including for treatment, payment, health care operations, research, and public health activities.
We are aware the use of data related to a person's health raises consumer privacy concerns with these emerging technologies,
We are also aware of the increased interest within the healthcare community in using data and AI-and ML-driven technologies for population-based activities related to improving health or reducing healthcare costs, as well as for continuity of care purposes and overall case management, care planning, and care coordination, both within and outside of the health care setting, including with community-based organizations.
HIPAA covered entities, such as health care providers, are generally among the customers of health IT developers, and in many cases, health IT developers serve as HIPAA business associates to their covered entity customers. Additionally, as discussed above, persons who provide cloud computing services to covered entities may also be business associates.
However, not all entities that collect, share, and use health data are regulated by the HIPAA Rules.
We are aware of potential intersections with the application and use of privacy engineering or privacy by design approaches and techniques (
We seek comment on issues the public believes the Department should consider addressing: health equity, information privacy, information security, patient safety, and data stewardship concerns while enabling trusted development and uses of health data to advance individuals' well-being and overall technology innovation, including AI, ML, and algorithms in healthcare. In particular, there are concerns pertaining to appropriate data de-identification (including managing re-identification risk), data use (processing and application), and data governance in healthcare. We seek comment on the desirability of federal guidance or education materials to help the public better understand and navigate the implications of existing federal protections with respect to the development and application of AI and ML-driven technologies to healthcare. We also welcome comment on how ONC can help developers of certified health IT further support users or provide additional technical capabilities to enhance and support health equity, data privacy and security with the use of algorithmic-based technology in healthcare. This request for comment
As we discuss in our proposals related to risk management above, we understand and are aware of concerns about historical, systemic issues in source (or input) data collection, capture and use of routinely collected data, including data quality (
We understand the importance of appropriate electronic collection, standardized capture, and use of standardized data in healthcare, including when that data serves as inputs to algorithms, DSIs, and other advanced technologies in healthcare. ONC supports the use of technology to improve the standardized capture of a set of health data classes to support the healthcare industry's need to electronically capture the underlying data they collect for treatment, payment, health care operations, research, and public health purposes.
We propose modifications to the “Base EHR” definition in § 170.102 to identify that a Health IT Module can be certified to either § 170.315(a)(9) or § 170.315(b)(11) to satisfy the definition for the period up to and including December 31, 2024. We also propose that § 170.315(a)(9) would no longer be included as part of the Base EHR definition after December 31, 2024. Rather, only § 170.315(b)(11) and not § 170.315(a)(9) would be available as a certification criterion to satisfy the definition of “Base EHR” beginning January 1, 2025.
Additionally, in § 170.315(a)(9)(vi) we propose that the adoption of § 170.315(a)(9) would expire on January 1, 2025, for purposes of the Program. Together, these proposals identify the dates when § 170.315(b)(11) replaces § 170.315(a)(9) in the Base EHR definition, and they indicate when Health IT Modules certified to § 170.315(a)(9) would need to be certified to § 170.315(b)(11) to maintain compliance with the Base EHR definition.
We propose to revise § 170.405(a) to include § 170.315(a)(9) within the list of certification criteria for which a developer of certified health IT with Health IT Module(s) certified to such criteria must successfully test the real world use of those Health IT Module(s) for interoperability in the type of setting in which such Health IT Module(s) would be or are marketed. This would mean that a developer of certified health IT with a Health IT Module certified to § 170.315(a)(9) would be subject to the requirements set forth in § 170.405(a). This proposal would require developers of certified health IT with Health IT Modules certified to § 170.315(a)(9) to submit real world test plans and results, among other requirements, as part of the real world testing Condition and Maintenance of Certification requirements. Further, in proposing the new “Decision Support Interventions” certification criterion in § 170.315(b)(11), we recognize and intend that the developers of Health IT Modules certified to § 170.315(b)(11) would be required to conduct real world testing consistent with the existing requirements in § 170.405(a). We note this is because all criteria in § 170.315(b) are already subject to those real world testing requirements.
We believe that requiring developers of certified health IT with Health IT Modules certified to § 170.315(a)(9) to participate in real world testing is consistent with our existing approach to implementing the real world testing Condition and Maintenance of Certification requirements by focusing on interoperability-related criteria. The capabilities included within the certification criterion in § 170.315(a)(9) are interoperability focused, and § 170.315(a)(9) is unlike other certification criteria currently adopted in the “clinical” section in § 170.315(a). The functionality expressed in § 170.315(a)(9) does not result in enabling a user to “record,” “change,” and “access” specific data types; rather, the functionality in § 170.315(a)(9) is more complex and multi-faceted. The primary functionality of both § 170.315(a)(9) and the proposed § 170.315(b)(11) is to ensure that multiple decision support intervention types are (1) supported through interaction with certified health IT and (2) configurable based on a specified set of data types (including data listed in the § 170.315(a)(5) demographics criterion). Additionally, the existing criterion in § 170.315(a)(9) specifies, and proposed criterion in § 170.315(b)(11) would specify, that certified Health IT Modules must support the availability of an intervention's source attributes for users to review. In this regard, ONC's existing CDS criterion and the proposed criterion in § 170.315(b)(11) are more like the care coordination criteria in § 170.315(b)(1) “Transitions of Care” and § 170.315(b)(2) “Clinical Information Reconciliation and Incorporation.” Further, to be enabled, interventions in § 170.315(a)(9) must rely on a wide array of problems, medications, demographics, laboratory tests and vital signs—both generated in the source system and received through a transition of care or referral. In this regard, the functionality required by § 170.315(a)(9) represents an important culmination of ONC's interoperability efforts, fitting appropriately in with other criteria listed in § 170.405(a).
We believe there are other important reasons to include § 170.315(a)(9) in § 170.405(a). First, this requirement will provide developers with an opportunity to demonstrate how their support of evidence-based CDS and linked referential CDS positively impacts patient care through real world testing plans and results. We know that developers of certified health IT support numerous kinds of CDS, many of which are foundational to improving patient care or support other important outcomes in healthcare. Second, requiring Health IT Modules certified to § 170.315(a)(9) to be subject to real world testing will provide the public at large with information on how different certified Health IT Modules are implementing and supporting the CDS certification criterion. For example, we would expect developers to establish a range of measures as part of their real world testing plans, described in § 170.405(b)(1), because developers have flexibility to craft real world testing measures specific to their products and customers. We would also expect developers of certified health IT with Health IT Modules certified to § 170.315(a)(9) to report on those measures as part of real world testing results, per requirements in § 170.405(b)(2), which would have the potential to provide the public with new insights on the market for CDS. Finally, we believe that requiring developers with Health IT Modules certified to § 170.315(a)(9) to participate in real world testing will be a helpful bridge to compliance for similar requirements proposed for the Decision Support Interventions certification criterion.
We note that the effect of proposing to include Health IT Modules certified to § 170.315(a)(9) in § 170.405(a) and the effect of proposing a revised version of the CDS criterion in § 170.315(b)(11), would require developers of certified health IT certified to § 170.315(a)(9) and § 170.315(b)(11) to follow the testing plans, methods, and results reporting; submission dates; and August 31 deployment deadline requirements in § 170.405(b) similar to the requirements of other applicable certification criteria listed in § 170.405(a). We anticipate that if finalized as proposed this would mean that Health IT Modules certified to § 170.315(a)(9) would be subject to the real world testing Condition and Maintenance of Certification requirements beginning with the 2023 real world testing cycle. This means that Health IT Modules certified to § 170.315(a)(9) prior to August 31, 2023, would need to, among other requirements, address each of the elements in § 170.405(b)(1)(iii)(A) through (G) in their real world testing plans by December 15, 2023, and submit results based on those plans no later than March 15, 2025. We invite comment on this proposal.
There is broad interest across the Department in the development, implementation, and use of algorithms and AI in healthcare.
Outside of the Department, multiple federal agencies are also exploring policies to prevent and mitigate bias in AI and ML and the intersection with privacy, equity, and civil rights.
We note that ONC regulates developers of certified health IT and their Health IT Modules, ensuring that both conform to technical standards, certification criteria, implementation specifications, and adhere to Conditions and Maintenance of Certification requirements. As it relates to the current CDS criterion in § 170.315(a)(9), ONC's regulatory oversight of developers of certified health IT includes requirements that their Health IT Modules certified to that criterion can enable two types of decision support interventions, evidence-based and linked referential, which must be (1) configurable based on data specified in § 170.315(a)(9)(ii) and (2) include source attributes in § 170.315(a)(9)(v) relevant to the individual decision support
We note that the questions of whether DSIs enabled by or interfaced with certified health IT are subject to FDA regulations, under the Federal Food, Drug, & Cosmetic Act, or are used by entities subject to the HIPAA Rules,
Given the intersecting nature and interest across the Department to address the use of AI for purposes of health, we consulted extensively with our HHS partners. Specifically, we worked with counterparts at AHRQ, FDA, and OCR in developing proposals to advance our shared goals of promoting predictive DSIs in healthcare that are valid, fair, appropriate, effective, and safe to deliver patient care. We plan to continue to coordinate with these and other federal agencies so that to the extent practicable, federal requirements that may apply to certified health IT and developers of certified health IT are aligned and not duplicative.
In this proposal, we are taking an approach that is both reflective of our authorities and aligned with others in the Department and Federal Government. We are not establishing requirements for technology not certified under the Program.
We anticipate that our collaboration with our federal partners on these proposed requirements would assist AHRQ, CMS, FDA, FTC, NIST, OCR, Veterans Health Administration, and other federal partners as they work within the bounds of their respective legal authorities with the goal of having greater consistency across federal agencies and the entire health IT ecosystem.
We propose to remove from 45 CFR 170.210(g) the current named specification for clock synchronization, which is Network Time Protocol (NTP v4 of RFC 5905). However, we propose to amend 45 CFR 170.210(g) so that Health IT Modules certified to applicable certification criteria continue to utilize any network time protocol (NTP) standard that can ensure a system clock has been synchronized and meets time accuracy requirements. The applicable certification criteria that either reference our proposed, revised in § 170.210(g), or cross-reference a provision that references § 170.210(g), include § 170.315(d)(2), § 170.315(d)(3), § 170.315(d)(10), and § 170.315(e)(1).
In the 2014 Edition Proposed Rule, we noted that having correctly synchronized clocks is an information security best practice and the NTP has been widely used and implemented since its publication in 1992 (77 FR 13840). We proposed to finalize a requirement for Health IT Modules to use a “synchronized clocks” standard, and we proposed to permit either NTPv3 or NTPv4. In response to the 2014 Edition Proposed Rule, commenters expressed support for our proposed “synchronized clocks” standard and our proposal to permit either NTPv3 or NTPv4. Commenters noted that the use of these synchronization technologies is very common and supported in all major operating systems (77 FR 54184). They stated that it was unclear why this would be a requirement for EHR technology certification because it is unlikely that the EHR technology itself will be directly implementing this type of synchronization and more likely that it will be relying on the lower-level systems' clock functionality (
In response to this comment, we reiterated our expectation that EHR technology will likely obtain a system time from a system clock that has been synchronized following the NTPv3 or NTPv4 standard (77 FR 54184). We expressly worded the standard to acknowledge this likely scenario by stating “[t]he date and time recorded
Feedback from industry has indicated that some developers rely on Microsoft-based operating systems to synchronize network time, which is a different standard than NTP v4. Subsequent to this feedback, we provided sub-regulatory flexibility to health IT developers to permit the use of
We propose to remove from § 170.210(g) a named standard to which a system clock has been synchronized when date and time are recorded. This would have the effect of modifying the requirement that Health IT Modules certified to § 170.315(d)(2), § 170.315(d)(3), § 170.315(d)(10), or § 170.315(e)(1) record date and time utilizing a system clock synchronized to a particular named standard. However, we propose to modify § 170.210(g) such that Health IT Modules certified to any of the certification criteria listed above would still be required to utilize a network time protocol standard that can ensure a system clock has been synchronized and meets the time accuracy requirements as defined in the applicable certification criteria.
We understand that beyond NTP and MS-SNTP, there are other network time protocol standards, some of which are more appropriate than others in specific contexts. We also understand that various operating and server systems, such as systems developed and published by Microsoft, employ a Simple Network Time Protocol (SNTP) extension to NTP. We considered proposing to add only the use of MS-SNTP as an alternative to Network Time Protocol Version 4 (NTP v4) of RFC 5905 (currently specified in § 170.210(g)), but decided against proposing this addition given the various standards that exist. We believe that requiring Health IT Modules to support a network time protocol standard of their choosing allows maximum flexibility for both health IT developers of certified health IT and end users of certified Health IT Modules while still ensuring that the time accuracy requirements in the above-listed certification criteria will be fully supported. We welcome comment on these proposals.
In the ONC Cures Act Final Rule, we adopted multiple standards and implementation specifications in § 170.215 to support the certification criterion in § 170.315(g)(10). At that time, CMS included references to these standards and implementation specifications for the purposes of aligning standards requirements across HHS in the Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, and Health Care Providers Final Rule (CMS Interoperability and Patient Access Final Rule (85 FR 25510-25640)). Subsequently, we have identified a need to improve the descriptions and categorization of these standards and implementation specifications based on public input. The healthcare and health IT communities have indicated that as HHS continues to advance standards alignment for different use cases, greater clarity in the purpose of each standard and the associated IG may support ease of understanding for organizations with less prior experience with certification criteria and the Program. In addition, public input suggested ONC should provide more clarity to differentiate distinct update timelines for each type of standard or implementation specification, for example when related standards may include different version identifiers (
(a)
(b)
(c)
(d)
(e)
We believe this approach will help to provide greater clarity and more specific identification of a standard or implementation specification for a precise purpose or as applicable for a given point in time.
In the ONC Cures Act Final Rule, we required Health IT Modules certified to § 170.315(g)(10) to issue refresh tokens to “confidential applications” that could securely receive and store refresh tokens. Specifically, we established in § 170.315(g)(10)(v)(A)(
After the publication of the ONC Cures Act Final Rule, health IT developers preparing for testing and certification to the § 170.315(g)(10) certification criterion, as well as third-party application developers, requested that we clarify this requirement. Health IT developers identified that we had not fully explained how our policy would apply to “native applications,” which, according to internet Engineering Task Force (IETF) RFC 6749, are “clients installed and executed on the device used by the resource owner (
We agreed with these concerns and determined that timely additional clarification was necessary. On November 4, 2020, we published an interim final rule (IFR) with request for comment that corrected this ambiguity and provided clarification (85 FR 70064). In the IFR, we clarified and made the regulation text consistent by adding a new paragraph in § 170.315(g)(10)(v)(A)(
We clarified in the IFR preamble that health IT developers must publish the method(s) by which their Health IT Module(s) support the secure issuance of an initial refresh token to “native applications” according to the API technical documentation and transparency requirements in § 170.404. In addition, we clarified that application developer attestations to health IT developers regarding the ability of their applications to secure a refresh token, a client secret, or both, must be treated in a good faith manner consistent with the provisions established in the API openness and pro-competitive conditions in § 170.404(a)(4) (85 FR 70077). Finally, we clarified in the IFR that health IT developers can determine the method(s) they use to support interactions with “native applications” and that health IT developers are not required to support all methods that third-party application developers seek to use (85 FR 70077).
In response to the IFR, we received comments expressing concern that the ability to “secure a refresh token” rather than meet a “confidential app profile” makes the refresh token a single point of failure and is a major security risk, and that it undermines the control patients exercise when they reauthenticate an app. Commenters suggested that ONC should only require long-term EHR access for native apps that meet the SMART App Launch Guide definition of “confidential app profile.” Other commenters argued that ONC's policy creates confusion by creating disparate rules around different application architectures and is not being based in established security standards. They argued that this would result in limiting patient choice without improving security, while also potentially introducing more security concerns. They suggested that ONC should require long-term EHR access to any patient selected application.
In response to public feedback in the IFR, and subsequent interaction with industry, we propose to remove mention of “applications capable of storing a client secret,” in § 170.315(g)(10)(v)(A)(
We will continue to monitor implementation of § 170.315(g)(10), engage with the standards development community, and provide information through existing ONC Certification Companion Guides (CCGs), the ONC API Resource Guide, and other educational materials. We invite comment on these proposals.
In the ONC Cures Act Final Rule, ONC adopted the FHIR US Core Implementation Guide (IG) STU3 version 3.1.0 implementation specification in § 170.215(a)(2) (85 FR 25740). At the time of the ONC Cures Act Final Rule's publication, the US Core IG STU 3.1.0 was the latest version available. ONC later adopted the FHIR US Core IG v3.1.1 in an interim final rule with comment period published by ONC on November 4, 2020, and titled “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency” (85 FR 70073-74). The US Core v3.1.1 resolved several technical issues, editorial copy/paste errors, omissions, and places in need of minor clarification in v3.1.0. Both versions define the minimum conformance requirements for accessing patient data using FHIR Release 4 and included profiled resources, operations, and search parameters for the Data Elements required in the USCDI standard (adopted in § 170.213).
Since the publication of the ONC Cures Act Final Rule, the US Core IG has evolved. Yearly US Core IG updates reflect changes to USCDI versions and requests from the HL7 US Realm FHIR community. Notable updates to the US Core IG include v4.0.0, which supports USCDI v1 and clarifies the definition of “must support” elements, and v5.0.1, which supports USCDI v2. As of publication of this NPRM, the National Coordinator has approved both USCDI v2 and the US Core IG v5.0.1 under the Standards Version Adoption Process (SVAP). Health IT developers taking advantage of SVAP flexibility can incorporate these standards into their Health IT Modules as permitted by 45 CFR 170.405(b)(9).
The US Core IG v6.0.0 is anticipated to include support for the data elements and classes added to USCDI v3. At the time of publication of this NPRM, the US Core IG v6.0.0 has not been finalized. Based on the annual US Core release cycle, we believe US Core IG v6.0.0 will be published before ONC issues a final rule.
The ONC Cures Act Final Rule established the API Conditions and Maintenance of Certification requirements in 45 CFR 170.404(b)(2), which contain a specific provision that, for Health IT Modules certified to the certification criterion in § 170.315(g)(10), certain “service base URLs”—otherwise known as “endpoints”—must be publicly published for all customers in a machine-readable format at no charge (85 FR 25764-25765). These electronic endpoints are the specific locations on the internet that make it possible for apps to access EHI at the patient's request.
In the ONC Cures Act Proposed Rule, we indicated that we “strongly encourage API Technology Suppliers, health care providers, HINs and patient advocacy organizations to coalesce around the development of a public resource or service from which all stakeholders could benefit” (84 FR 7494). However, we decided against naming specific standards in the ONC Cures Act Final Rule and did not establish requirements for the content or format of the endpoint lists to provide industry an opportunity to coalesce on specifications. We finalized § 170.404(b)(2) to require that Certified API Developers must make their service base URLs freely accessible and in a machine-readable format at no charge.
Since the ONC Cures Act Final Rule was published, we have found that developers with publicly discoverable endpoint lists have defined their own, bespoke publication approaches and unique formats. There is variability across developers of certified health IT in the format they are using to publish their service base URLs, indicating that the industry has not coalesced around a common framework or approach. Research conducted through ONC's Lantern Project confirms that this variability among developers of certified health IT is hindering maturation of a vibrant app ecosystem for patients and the healthcare community, which is a primary goal of ONC policy and regulations in this area.
The inconsistent implementation of this requirement has rendered important data meant to facilitate connections to endpoints difficult to access.
Additionally, it is difficult to map multiple, unique organizations to endpoints. Experience to-date indicates that the name of the organization associated is typically formatted as free text (
Even more complicated is the possibility of a single endpoint representing all six of the “Acme Children's Hospital” organizations in the example above. A single String is unable to represent the complexity of healthcare systems, where a system can contain many subsystems, or where a FHIR API URL can support a set of systems. Including all organizations that are serviced by an endpoint is important for discovery of which endpoint serves a particular health care provider, which in turn would allow the user to access the relevant EHI through that endpoint. Having all healthcare organizations serviced by the endpoint accessible and in a standardized format would help app developers easily fetch information to enable patients and other users to access, exchange, and use information.
We propose to revise the requirement in § 170.404(b)(2) to include new data format requirements. We anticipate that these new specifications would establish standards for industry adoption and better facilitate patient access to their health information. In the revised § 170.404(b)(2), we also propose to incorporate the following existing requirements in § 170.404(b)(2)(i) and (ii): a Certified API Developer must publish service base URLs “For all of its customers regardless of whether the Health IT Modules certified to § 170.315(g)(10) are centrally managed by the Certified API Developer or locally deployed by an API Information Source;” and publish these service base URLs “at no charge” as part of proposed § 170.404(b)(2).
In the “Service base URL publication” requirements in § 170.404(b)(2)(i), we propose to require that service base URLs must be formatted in FHIR “Endpoint” resource format according to the standard adopted in § 170.215(a). Additionally, in § 170.404(b)(2)(ii), we propose to require that organization details such as name, location, and provider identifiers (
We propose these formats because they are based on the FHIR Release 4 and US Core IG industry standards that are already adopted for use in the Program in § 170.315(g)(10). We are specifically proposing the FHIR “Endpoint” resource because it is used for representing technical endpoint details and contains a required “address” element that, according to the FHIR R4 standard, contains “the technical base address for connecting to this endpoint.” Certified API Developers would be able to populate this element, in each of their published “Endpoint” resources, with a service base URL that can be used by patients to access their electronic health information.
We additionally propose the US Core “Organization” resource because it can be used to represent important contextual information around a service base URL. The US Core “Organization” resource contains an optional “endpoint” element that can be used to reference “technical endpoints
Additionally, the US Core “Organization” resource contains a “mandatory” element called “name” that contains a “name used for the organization.” In addition to this required element, we propose in § 170.404(b)(2)(ii)(B) to require Certified API Developers to make available “must support” elements of organization location and provider identifier(s) using the US Core “Organization” resource. An organization's location could be an address that is populated in the “address” element of the US Core “Organization” resource; and a provider identifier could be a National Provider Identifier (NPI), Clinical Laboratory Improvement Amendments (CLIA) number, or other health system ID populated in the “identifier” element. Altogether, this information helps contextualize service base URLs and enables application developers to more easily and consistently provide patient access to their electronic health information. We welcome comment on this proposal and whether additional data should be required as part of organizational details.
Finally, we propose, in § 170.404(b)(2)(iii)(A), to require that these resources be collected in a FHIR “Bundle” resource that the Certified API Developer would publicly publish. According to the FHIR specification, a “Bundle” acts as “a container for a collection of resources” and is widely used in use cases like returning search results and grouping resources as part of a message exchange.
We also propose, in § 170.404(b)(2)(iii)(B), that Certified API Developers ensure Endpoint and Organization resources remain current by reviewing this information quarterly and, as necessary, update the information. We recognize that as customers upgrade and install new health IT, data provided in the Endpoint and Organization resources will change. To serve its intended purpose, we believe this information should be updated regularly. We believe these resources must remain up to date to ensure application developers can easily and consistently provide patients access to their EHI. We note that a one-time publication of the developer's current list of endpoints for active customers upon certification to the § 170.315(g)(10) criterion will only meet initial certification requirements, and we propose to establish in § 170.404(b)(2)(iii)(B) a requirement that Certified API Developers maintain this information over time. We also note that failure to maintain the service base URLs and ensure the associated organization information remains up to date and free of errors or defects on a quarterly basis would be considered a violation of this Condition and Maintenance of Certification requirement and may result in corrective action. We clarify that any endpoint or organization information that is out of date, incomplete, or otherwise unusable for more than 90-days would be considered in violation of this proposed requirement. However, we request comment whether we should shorten this period of time to 60 or 30 days.
We believe that further standardization will better enable individuals to connect to their EHI, and we believe that this requirement will also support other industry efforts to leverage and scale endpoint directories. For example, the FHIR community, through the Argonaut Project, recently developed the “Patient-access Brands” conceptual model that specifies standardized formats for publishing endpoints and related organizational information.
In the ONC Cures Act Final Rule, we established a requirement in § 170.315(g)(10)(vi) for Health IT Modules certified to § 170.315(g)(10) to be able to revoke an authorized application's access at a patient's direction (85 FR 25945). This required capability is intended to enable patients to “definitively revoke an application's authorization to receive their EHI until reauthorized, if ever, by the patient” (85 FR 25747). We noted in the ONC Cures Act Final Rule that we finalized § 170.315(g)(10)(vi) as a functional requirement to allow health IT developers the ability to implement it in a way that best suits their existing infrastructure and allows for innovative models for authorization revocation to
As part of health IT developers' implementation of these requirements, we have received feedback regarding the implementation of authorization revocation, specifically around the revocation of access tokens. Health IT developers have requested clarification regarding letting access tokens expire in lieu of immediate access token revocation for the purposes of certification testing. The OAuth 2.0 Token Revocation specification, RFC 7009, describes expiration of short-lived access tokens as a design option for authorization servers to revoke an application's access. This design option conforms with industry standard practice and may reduce health IT developer burden as the Health IT Module would not have to perform token introspection for each resource request nor maintain a database of valid access tokens.
We propose to revise the requirement in § 170.315(g)(10)(vi) to specify that a Health IT Module's authorization server must be able to revoke and must revoke an authorized application's access at a patient's direction within 1 hour of the request. This requirement aligns with industry standard practice of short-lived access tokens as specified in internet Engineering Task Force (IETF) Request for Comments (RFC) 6819,
We considered a shorter timeframe, but we concluded that 1 hour would be both an appropriate expectation for developers to meet and would be consistent with industry standards for revocation of an application's access. We also expect that many or most developers would institute a process that results in revocation of access in a timeframe much less than 1 hour. Investigation into industry best practice leads ONC to believe that a 1-hour requirement to revoke an authorized application's access at a patient's direction is an appropriate baseline requirement. We invite comment on this proposal.
In the ONC Cures Act Final Rule, we adopted the HL7 FHIR SMART Application Launch Framework (SMART v1) Implementation Guide Release 1.0.0 implementation specification, a profile of the OAuth 2.0 specification, in § 170.215(a)(3) (85 FR 25741). SMART v1 provides reliable, secure authorization for a variety of app architectures through the use of the OAuth 2.0 standard. This Implementation Guide (IG) supports both required and optional requirements, known as the “SMART on FHIR Core Capabilities” (85 FR 25741). This profile includes required support for “refresh tokens,” “Standalone Launch,” and “EHR Launch” capabilities from the SMART IG. Additionally, as part of adopting the implementation specification in § 170.215(a)(3), the ONC Cures Act Final Rule required support for optional capabilities including, “launch-ehr,” “launch-standalone,” “client-public,” “client-confidentialsymmetric,” “sso-openid-connect,” “context-banner,” “context-style,” “context-ehr-patient,” “context-ehr-encounter,” “context-standalone-patient,” “context-standalone-encounter,” “permission-offline,” “permission-patient,” and “permission-user.”
As part of the adopted implementation specification, we explicitly required mandatory support of the “SMART on FHIR Core Capabilities” for Program testing and certification, and we stated that by requiring the “permission-patient” “SMART on FHIR Core Capability” in § 170.215(a)(3), Health IT Modules presented for testing and certification to § 170.315(g)(10), via cross-references to § 170.215(a)(3), must include the ability for patients to authorize an application to receive their electronic health information (EHI) based on FHIR resource-level scopes (85 FR 25741, 25746). Practically, this means that patients would need to have the ability to authorize access to their EHI at the individual FHIR resource-level, from one specific FHIR resource (
The SMART Application Launch Framework Implementation Guide Release 2.0.0 (SMART v2) Guide is the next major release of the SMART Application Launch Framework IG.
As part of this proposal, we propose to adopt several sections specified as “optional” in the SMART v2 Guide as “required” for purposes of the Program for certification criteria that reference § 170.215(c). Specifically, we propose to adopt all Capabilities as defined in “8.1.2 Capabilities,” which include but are not limited to (1) backward compatibility mapping for SMART v1 scopes as defined in “3.0.2 Scopes for requesting clinical data;” (2) asymmetric client authentication as defined in “5 Client Authentication: Asymmetric (public key);” and granular scopes as defined in (3) “3.0.2.3 Finer-grained resource constraints using search parameters.” Additionally, we propose to require support for the “Patient
Further, we note that the SMART v2 Guide includes section 3.0.2.3 “Finer-grained resource constraints using search parameters,” and associated “3.0.2.4 requirement for support” and “3.0.2.5 experimental features,” which present concepts for further development within the SMART v2 Guide. Together, these optional functionalities will enable more granular control for individuals, clinicians, and other users to share information with apps of their choice in more explicit ways. The granular scope functionality would empower patients and providers to share health data in a more granular fashion, which will improve confidence in the use of third-party apps by allowing app users to decide which specific type of EHI they share with the app. These functionalities would help address privacy and security concerns of third-party app access to health data and further patient empowerment by providing the ability to limit an app's access to a granular, minimum set of health data, as determined by the app user. We propose these sections for adoption as part of SMART v2 Guide with the understanding that either the SMART v2 Guide or another implementation guide such as the US Core Implementation Guide will define more specific requirements for finer-grained resource constraints using search parameters.
The SMART v2 Guide introduces new or revised requirements to the previous version of the implementation guide, SMART Guide v1. Major requirements new to the SMART v2 Guide include support for the OAuth 2.0 security extension Proof Key for Code Exchange (PKCE), as well as a revision of the scope syntax. The SMART v2 Guide includes requirements that both the EHR and all apps support the OAuth 2.0 security extension PKCE. PKCE is an industry standard security extension for OAuth 2.0 to mitigate the known security vulnerability of authorization code interception attacks.
Another major change included in the SMART v2 Guide is revision of the syntax of scopes provided to apps. To align with the FHIR interactions of “Create”, “Read”, “Update”, “Delete”, “Search”, collectively known as “CRUDS,” scopes are constructed to consist of combinations of five types of permissions corresponding to the CRUDS interactions. The use of this CRUDS scope syntax permits improved patient choice for persistent access as more specific combinations of permissions can be granted to apps as opposed to the scope syntax used in the SMART v1 Guide, which only used two permission types of “read” and “write.”
One of the major security improvements in the SMART v2 Guide is the requirement that all apps support the OAuth 2.0 security extension Proof Key for Code Exchange (PKCE). PKCE is designed to mitigate the known security vulnerability of authorization code interception attacks, with native apps especially targeted. According to IETF RFC 7636, the request for comment which defines the PKCE extension, this attack can be used to illegitimately obtain an access token from the authorization server and thus obtain server data in an unauthorized manner. PKCE mitigates this vulnerability by creating cryptographically random keys for every authorization request. The authorization server performs proof of possession of the secret key by the client. This mitigates the vulnerability as an attacker who intercepts the authorization code cannot redeem it for an access token as they do not possess the secret key associated with the authorization request.
Support for PKCE is important because PKCE makes health app access of patient health information more secure in a standardized manner. ONC recognizes healthcare participants and patients are interested in the secure use of health apps, including native apps, to access health information. PKCE support makes the granting of access to health information via health apps more secure by mitigating the known vulnerability of authorization code interception attacks. We believe the support of PKCE would further our goal of secure access of health information without special effort by further securing health app access, especially for native apps. Therefore, we propose to require the support of PKCE as specified in the SMART v2 Guide. We invite comment on this proposal.
Another major update in the SMART v2 Guide is the revision of the scope syntax to align with the FHIR REST API interactions for FHIR resources. Previously in the SMART v1 Guide, scope syntax for FHIR resources was delineated in terms of combinations of “read” and “write” permissions. The SMART v2 Guide revises this scope syntax by splitting “read” permissions into two types of permissions which correspond to FHIR REST API interactions, “Read” and “Search.” Similarly, the “write” permissions from the SMART v1 Guide are split into “Create,” “Update,” and “Delete.” This alignment of scope syntax to the FHIR REST API interactions permits Health IT Module authorization servers to provide greater specificity regarding which permissions are granted in scopes to apps and has the benefit of improved technical clarity to health IT and application developers. This additional specificity for scopes also improves a patient's control over how an app accesses their health data by clarifying for the patient what specific type of API interactions are permitted to the app. For example, under this new syntax the patient could specifically permit an app “read” access to a FHIR resource but deny “search” access for the same FHIR resource.
Currently, as stated in 85 FR 25742, the § 170.315(g)(10) certification criterion only requires health IT developers to support “read” capabilities according to the standard and implementation specifications adopted in § 170.215(a) and in § 170.215(b)(1), including the mandatory capabilities described in “US Core Server CapabilityStatement.” We will continue this policy for § 170.315(g)(10), as specified in the SMART v2 Guide, which would include “Read” and “Search” permissions to be supported for certification to the § 170.315(g)(10) criterion. We welcome comment on these scopes and are interested in the public's experience with other aspects of CRUDS.
We propose to require all Capabilities as defined in “8.1.2 Capabilities” and the “Patient Access for Standalone Apps” and “Clinician Access for EHR Launch” Capability Sets from “8.1.1 Capability Sets.” The following section identifies optional component pieces of 8.1.2 Capabilities and optional profiles
First, the SMART v2 Guide introduces functionality specified as optional in the implementation guide. We propose to make several of these optional functionalities required as part of the proposed implementation specification, and therefore required for certification criteria that reference proposed § 170.215(c)(2). First, one such optional functionality is the mapping between SMART v1 Guide and SMART v2 Guide scopes for the purpose of backward compatibility. We propose to require support of this mapping for the purposes of interoperability between implementations of the SMART v1 Guide and the SMART v2 Guide. As part of the current “Authentication and authorization” requirements in § 170.315(g)(10)(v) for the certification criterion in § 170.315(g)(10), Health IT Modules must support authentication and authorization during the process of granting access to patient data. Part of the authorization process involves an application requesting permission to access patient data in the form of OAuth 2.0 scopes as specified in the SMART v1 Guide. The SMART v2 Guide changes the format of these scopes, making SMART v2 scopes not directly compatible with SMART v1 scopes. The SMART v2 Guide provides a mapping of SMART v1 scopes to SMART v2 scopes for the purposes of backward compatibility. For the purposes of interoperability with existing API deployments implementing the SMART v1 Guide, we propose to require that servers advertise the “permission-v1” capability in their “well-known/smart-configuration” discovery document, return SMART v1 scopes when SMART v1 scopes are requested and granted, and process SMART v1 scopes according to the backward compatibility mapping specified in SMART v2 Guide “3.0.2 Scopes for requesting clinical data.”
Second, the SMART v2 Guide introduces an optional profile for authorization servers to support asymmetric client authentication for confidential clients. We propose to require Health IT Modules support asymmetric client authentication as an option for confidential clients during the process of authentication and authorization when granting access to patient data. This proposed requirement would align with the security practices of industry as evidenced by the SMART v2 Guide's recommendation that asymmetric client authentication be used when available and improves interoperability for clients by making this API security feature consistently available across § 170.315(g)(10)-certified APIs. Client authentication is the process by which the authorization server verifies the identity of the client requesting authorization. The SMART v1 Guide specifies client authentication in terms of symmetric client authentication, in which authentication is based on a secret key shared by both the authorization server and the client. The SMART v2 Guide introduces a new profile for client authentication, asymmetric client authentication. Asymmetric client authentication relies upon public key cryptography for authentication, with the client having public and private keys. The SMART v2 Guide specifies asymmetric client authentication as an optional profile but recommends clients use asymmetric client authentication when available. Given this recommendation of the SMART v2 Guide, we believe there would be a security benefit for servers to provide clients the option to use asymmetric client authentication over symmetric client authentication. Additionally, clients would benefit from having asymmetric client authentication supported by authorization servers consistently in a standardized way. Therefore, we propose to require Health IT Modules support asymmetric client authentication as defined in “5 Client Authentication: Asymmetric (public key)” as an option for confidential clients during the process of authentication and authorization when granting access to patient data. We also propose to require Health IT Modules advertise the “client-confidential-asymmetric” capability in their “well-known/smart-configuration” discovery document.
Third, the SMART v2 Guide also introduces a new optional feature of granular scope constraints using search parameters. This feature uses the FHIR REST API search parameter syntax to specify permissions more granular than the FHIR resource level, which was the maximum granularity of scopes in the SMART v1 Guide. By using search parameters associated with a FHIR resource, a scope can be made to apply only to a specific subset of a FHIR resource and therefore the permissions granted to the client via such a scope would be limited to this subset. For example, the SMART v2 Guide mentions how an authorization server can provide a scope for laboratory Observations using the “category” search parameter instead of all Observation resources. This granular scope functionality would empower patients with greater control over what types of information applications of their choice receive from a Health IT Module. This would also improve patients' ability to select granular permissions to grant persistent access to applications. However, the SMART v2 Guide leaves this new functionality as optional and does not specify specific search parameter requirements for finer-grained scope constraints. We propose to require “3.0.2.3 Finer-grained resource constraints using search parameters” with the clarification that Health IT Modules certified to § 170.315(g)(10) must minimally be capable of handling finer-grained scopes using the “category” parameter for (1) the Condition resource with Condition sub-resources Encounter Diagnosis, Problem List, and Health Concern and (2) the Observation resource with Observation sub-resources Clinical Test, Laboratory, Social History, SDOH, Survey, and Vital Signs. We anticipate that the US Core IG will provide guidance for developers to support a minimum number of search parameters and this minimum list will be consistent with the optional scopes described in section “3.8 Future of US Core” of the US Core IG v6.0.0. We invite comment on this proposal, and we seek comment on whether we should expand the minimum search parameters for Health IT Modules certified to § 170.315(g)(10).
Fourth, the SMART v2 Guide revises how capabilities are categorized. The “SMART Core Capabilities” in the SMART v1 Guide define capabilities supported by the server and are made available to inform clients of supported functionality. “Capabilities” are grouped into “Capability Sets” to define the functionalities required for a specific use case. The SMART v2 guide restructures how “Capabilities” are organized, and no longer includes “SMART Core Capabilities.” Instead, the SMART v2 Guide includes a list of “Capabilities” and “Capability Sets.” To align with the capabilities proposed for adoption and the current § 170.315(g)(10) requirement, via cross-reference to the existing § 170.215(a)(3), for Health IT Modules to support “SMART Core Capabilities” as specified in the SMART v1 Guide, we propose to require the following “Capability Sets” from the SMART v2 Guide of “Patient Access for Standalone Apps” and “Clinician Access for EHR Launch” in addition to the “8.1.2 Capabilities,” enumerated in the SMART v2 Guide, including the capabilities of: “launch-ehr,” “launch-standalone,” “authorize post,” “client-public,” “client-confidential-symmetric,” “client-confidential-asymmetric,” “sso-openid-connect,” “context-banner,” “context-
Additionally, the SMART v2 Guide introduces a new requirement to support POST-based authorization for the client authorization request. This new requirement in the SMART v2 Guide is adapted from the OpenID Connect Core specification and is related to the requirement in § 170.315(g)(10)(v)(A)(
We propose to require the following optional capabilities as required: “permission-v1”; “permission-v2”; “client-confidential-asymmetric;” and “authorize-post” from section “8.1.2 Capabilities” to support new technical requirement for backward compatibility with SMART v1 Guide scopes, SMART v2 Guide granular scopes, asymmetric client authentication, and support for authorization via HTTP POST respectively. In sum, we propose to require all Capabilities as defined in “8.1.2 Capabilities” and the “Patient Access for Standalone Apps” and “Clinician Access for EHR Launch” Capability Sets from “8.1.1 Capability Sets.”
The SMART v2 Guide also defines a profile for OAuth 2.0 token introspection. As described in the ONC Cures Act Final Rule (85 FR 25748), commenters on the ONC Cures Act Proposed Rule requested a requirement in the § 170.315(g)(10) criterion for token introspection, a process which defines how an authorization server can be queried for information about a token. In response to this feedback, ONC subsequently finalized a token introspection requirement in § 170.315(g)(10)(vii) but did not specify a standard and encouraged industry to coalesce around a common standard, such as OAuth 2.0 Token Introspection (RFC 7662). The SMART v2 Guide introduces a profile for OAuth 2.0 Token Introspection in “7 Token Introspection.” We believe a standardized process for token introspection would improve interoperability for FHIR clients and resource servers by defining specific expectations around what information a Health IT Module's authorization server returns about a token when queried by a client or resource server. To facilitate such interoperability, we propose to revise the token introspection requirement in § 170.315(g)(10)(vii) to state, “A Health IT Module's authorization server must be able to receive and validate tokens it has issued in accordance with an implementation specification in § 170.215(c).” This requirement would ensure that a Health IT Module's authorization server must be able to receive and validate tokens it has issued in accordance with SMART v2 Guide “7 Token Introspection.”
Finally, we again note that we propose to restructure the standards listed in § 170.215 to better categorize API standards and to enable simultaneous use of different versions of IGs for a set period of time. We propose to categorize the SMART v1 Guide in § 170.215(c)(1) as part of a group of standards that enable client applications to access and integrate with data systems, and we propose that the adoption of this standard expires on January 1, 2025. In so doing, we propose to move the implementation specification currently found in § 170.215(a)(3) to § 170.215(c)(1). We propose the SMART v2 Guide in this same group in § 170.215(c)(2). Together, this recategorization and establishment of an expiration date for § 170.215(c)(1) would give health IT developers of certified health IT the option to use either SMART Guide version for a period of time, and it would establish a concrete date for when they would need to implement and support the newer version in their Health IT Modules certified to certification criteria that reference § 170.215(c).
In the 2015 Edition Final Rule (80 FR 62601), ONC required the recording, capture, and access to a patient's sex, sexual orientation, and gender identity for Health IT Modules certified to the “Demographics” certification criterion (§ 170.315(a)(5)) (80 FR 62747). This rule also defined a required set of standardized terminology to represent each of these data elements (80 FR 62618-62620). Since then, ONC has received recommendations through the Health Information Technology Advisory Committee (HITAC) and public feedback that the current terms and terminologies used to represent sex, gender identity, and sexual orientation are limited and need to be updated.
Meanwhile, the healthcare industry had similarly taken note of the need for precision for ideas encompassed in terms such as “sex” and “gender” and launched the Gender Harmony Project
In this section, we outline our proposals to modify the
We propose to add the data elements “Sex for Clinical Use” in § 170.315(a)(5)(i)(F), “Name to Use” in § 170.315(a)(5)(i)(G), and “Pronouns” in § 170.315(a)(5)(i)(H) to the “Patient Demographics and Observations” certification criterion (§ 170.315(a)(5)). This addition reflects concepts developed by the HL7 Gender Harmony Project and help promote inclusivity in care delivery.
We propose to revise the terminology standards specified for “Sex” in § 170.315(a)(5)(i)(C). ONC has received significant feedback reflecting the need to be more inclusive in the terminology representing the data element. As such, ONC proposes to revise the fixed list of terms for “Sex” in § 170.315(a)(5)(i)(C), which are represented by HL7® Value Sets for AdministrativeGender and NullFlavor in § 170.207(n)(1). We propose to ultimately replace § 170.207(n)(1) with the SNOMED CT code set proposed in § 170.207(n)(2). We refer the readers to section III.C.1 of the rule for additional information about the proposed change to the terminology standard. In order to be less disruptive to developers of certified health IT, we propose to provide flexibility and allow recording the element using the specific codes represented in § 170.207(n)(1) for the time period up to and including December 31, 2025, to provide enough time to transition their health IT systems to SNOMED CT® by January 1, 2026. By having § 170.207(n)(1) expire at the end of 2025 and adding (n)(2) as a requirement for Health IT Modules certified to § 170.315(a)(5) beginning January 1, 2026, we propose to enable health IT developers to specify any appropriate value from the SNOMED CT® code set with the standard specified in § 170.207(n)(2).
Additionally, we propose to replace the terminology standards specified for Sexual Orientation in § 170.315(a)(5)(i)(D), and Gender Identity in § 170.315(a)(5)(i)(E). ONC has received significant feedback reflecting the need to be more inclusive in the terminology representing each of these data elements. As such, ONC proposes to revise the fixed list of terms for Sexual Orientation in § 170.315(a)(5)(i)(D), and Gender Identity in § 170.315(a)(5)(i)(E), which are represented by SNOMED CT and HL7® Value Set for NullFlavor in § 170.207(o)(1) and (2), and ultimately replace it with the SNOMED CT code set specified in § 170.207(o)(3). We refer the readers to section III.C.1 (USCDI) of the rule for additional information about the proposed change to the terminology standard.
We further propose to set an expiration date of January 1, 2026, for the adoption of the values sets referenced in § 170.207(o)(1) and (o)(2). This will allow the use of either the value sets in § 170.207(o)(1) and (o)(2) or the standard proposed in § 170.207(o)(3) beginning on the effective date of a final rule and transitioning to allow only the use of the proposed standard in § 170.207(o)(3) after December 31, 2025. Consistent with our proposals in sections III.A and III.C.11, developers of certified health IT with Health IT Modules certified to criteria that reference § 170.207(o)(1) or (o)(2) would have to update those Health IT Modules to § 170.207(o)(3) and provide them to customers by January 1, 2026.
We also propose to add Sex for Clinical Use (SFCU) as a new data element in § 170.315(a)(5)(i)(F). SFCU is a category based upon clinical observations typically associated with the designation of male and female. It supports context specificity, is derived from observable information, and is preferably directly linked to the information this element summarizes. SFCU represents a patient's sex relevant to a specific clinical setting. This is valuable when providing care for a patient whose condition or treatment is dependent on their sex as determined by observing and evaluating, for example, a patient's hormonal values, organ inventory, genetic observations, or external genital morphology. SFCU may differ from a patient's sex as recorded on a birth certificate or driver's license. We further clarify, that while there may be multiple values of Sex for Clinical Use tied to different events, such as requesting a laboratory test or imaging study, we propose to require health IT developer be able to record at least one value of SFCU. Additionally, in order to align with current industry practice and to provide flexibility to health IT developers, we propose that health IT be capable of recording SFCU using the LOINC® terminology code set standard specified in proposed § 170.207(n)(3).
We propose to add new data elements Name to Use in § 170.315(a)(5)(i)(G) and Pronouns in § 170.315(a)(5)(i)(H), respectively, to advance the culturally competent care for lesbian, gay, bisexual, transgender, queer, intersex, asexual, and all sexual and gender minority (LGBTQIA+) people. Multiple values for a given patient may be valid over time. For the purposes of this proposal, we require at least one value for Pronouns and Name to Use be recorded. Additionally, in order to align with current industry practice and to provide flexibility to health IT developers, we propose that health IT be capable of recording Pronouns using the LOINC® terminology code set standard specified in proposed § 170.207(o)(4).
In addition to the other data elements proposed in this section, the HL7 Gender Harmony Project created an element named Recorded Sex or Gender (RSG). RSG documents a specific instance of sex and/or gender information. RSG is considered a complex data element that includes provision for a sex or gender value, as well as reference to the source document where the value was found, whereas Sex is a simple data element. RSG provides an opportunity for health IT developers to differentiate between sex or gender information that exists in a document or record, from Sex for Clinical Use (SFCU) which is designed to be used for clinical decision-making.
Given the work undertaken by the Gender Harmony Project to develop an implementation guide that would work with all HL7 product families, we request comment on the following options we could pursue for a final rule.
In preparing comments, we encourage commenters to fully review our proposed certification criterion in § 170.315(a)(5) and USCDI v3. Notably,
We propose to revise and update the “demographics” certification criterion (§ 170.315(a)(5)), which we propose to rename “patient demographics and observations,” and which is included in the Base EHR definition in § 170.102. This means Health IT Modules would need to be updated to accommodate the additional requirements in the “Patient Demographics and Observations” certification criterion in order to meet the Base EHR definition.
In addition, because December 31, 2022, has passed, we propose to revise the Base EHR definition by removing the reference to § 170.315(g)(8) in § 170.102(3)(ii) and replacing the references to § 170.315(g)(10) in § 170.102(3)(ii) and (iii) with a single reference to § 170.315(g)(10) in § 170.102(3)(i).
In this section, we outline our proposals to update the Transitions of Care certification criterion (§ 170.315(b)(1)) to align it with changes made in USCDI v3, which we propose to adopt in § 170.213(b).
We propose to replace the fixed value set for the USCDI data element “Sex” and instead enable health IT developers to specify any appropriate value from the SNOMED CT code set with the standard specified in § 170.207(n)(2). Health IT developers can continue using the specific codes for Sex represented in § 170.207(n)(1) for the time period up to and including December 31, 2025. We note that these dates are proposed for the adoption of the associated standards in § 170.207(n), including the expiration of the adoption of the standard in § 170.207(n)(1) on January 1, 2026. Consistent with our proposals in sections III.A and III.C.11, developers of certified health IT with Health IT Modules certified to criteria that reference § 170.207(n)(1) would have to update those Health IT Modules to § 170.207(n)(2) and provide them to customers by January 1, 2026.
Finally, we propose a conforming update to § 170.315(b)(1) to update the listed minimum standard code sets for Problems in § 170.315(b)(1)(iii)(B)(
Through our efforts to advance interoperability across a nationwide health IT infrastructure, ONC has specifically focused on how health IT can support efforts to reduce healthcare disparities and provide both insights and tools for the purposes of measuring and advancing health equity. This includes specific steps to expand the capabilities of health IT to capture and exchange data that is essential to supporting patient-centered clinical care that is targeted to supporting a patient's unique needs. However, as ONC pursues policies intended to improve the interoperability and sharing of data through adoption of standards-based certification criteria and implementation specifications, we are aware of the imperative to protect health data privacy. This need is compounded by the inclusion of new data elements in the USCDI that are intended to support advancement in health equity, but which also may increase data sensitivity because of the potential for bias or stigmatized care. We believe the need to protect sensitive health information is foundational to a health equity by design principle not only to protect patient privacy, but also to mitigate the risk of any unintended negative impact on an individual resulting from the disclosure of sensitive health information.
We are also cognizant that identifying which health data are defined as “sensitive” may vary across federal or state laws, and may further vary based on an individual patient's perspective. Thus, the concept of “sensitive data” is dynamic and specific to the individual. Patient populations that have historically been subject to discrimination may identify a wide range of demographic information as sensitive, including race, ethnicity, preferred language, sex, sexual orientation, gender identity, and disability status. Efforts to support whole patient care and expand the capture of social, psychological, and behavioral health information have led to advancements in standards for representation of social determinants of health (SDOH). We must also keep in mind that the capture and exchange of SDOH data includes the potential risk for discrimination or misuse.
Advances in genetic testing and genomic research offer opportunities for early intervention and preventative care, but again, they represent a potential risk that may not be fully addressed by current privacy laws. Finally, there are types of clinical information that could impact the patient if disclosed, such as reproductive health, behavioral health, and substance abuse information.
The HIPAA Privacy Rule provides individuals with several rights intended to empower them to be more active participants in managing their health information. These include the right to access certain health information maintained about the individual; the right to have certain health information amended; the right to receive an accounting of certain disclosures; the right to receive adequate notice of a covered entity's privacy practices; the right to agree or object to, or authorize, certain disclosures; the right to request restrictions of certain uses and disclosures; and provisions allowing a covered entity to obtain consent for certain uses and disclosures.
Under the HIPAA Privacy Rule, covered entities as defined in 45 CFR 164.530(i) are required to allow individuals to request a restriction on the use or disclosure of their PHI for treatment, payment, or health care operations and to have policies in place by which to accept or deny such requests (See 45 CFR 164.522(a)(1)(i)(A)). The HIPAA Privacy Rule does not specify a particular process to be used by individuals to make such requests or for the entity to accept or deny the request. However, we believe that certified health IT should—to the extent feasible—support covered entities so they can execute these processes to protect individuals' privacy and to provide patients an opportunity to exercise this right.
Patient-directed privacy of data the patient deems sensitive requires attention to specific challenges from both a technology and a policy perspective, which we recognize cannot be easily solved. However, as we intended with the ONC Cures Act Final Rule, we believe there may be approaches that could, at a minimum, support the advancement of health IT tools to support discrete parts of these privacy workflows.
We are therefore proposing a new certification criterion, an addition to ONC's Privacy and Security Framework under the Program, and a revision to an existing certification criterion to support
We propose to adopt a new certification criterion specifically in support of the HIPAA Privacy Rule's “right to request a restriction” on certain uses and disclosures (See also 45 CFR 164.522(a)). We propose to add the new certification criterion “patient requested restrictions” in § 170.315(d)(14) to enable a user to implement a process to restrict uses or disclosures of data in response to a patient request when such restriction is agreed to by the covered entity. We propose that this new criterion in § 170.315(d)(14) would be standards-agnostic, allowing health IT developers seeking to certify a Health IT Module to the criterion flexibility in how they design these capabilities so long as they meet the functional requirements described for certification. We specifically intend the proposed § 170.315(d)(14) to advance the technological means to support clinicians and other covered entities when honoring patient requests for the restriction of uses or disclosure of PHI through certified health IT.
We propose to add the following in § 170.315(d)(14) for this new criterion “patient requested restrictions”:
• For any data expressed in the standards in § 170.213, enable a user to flag whether such data needs to be restricted from being subsequently used or disclosed; as set forth in 45 CFR 164.522; and
• prevent any data flagged pursuant to paragraph (d)(14)(i) of this section from being included in a subsequent use or disclosure for the restricted purpose.
We propose that “enabl[ing] a user to flag” means enabling the user of the Health IT Module to indicate that a request for restriction was made by the patient and that the user intends to honor the request. In the case of integration with a Health IT Module certified to the revised criterion in § 170.315(e)(1) discussed in this section, that request made by the patient could be in part automated for requests made through an internet-based method. However, the functionality under the proposed new criterion in § 170.315(d)(14) must include the ability for the user to indicate a request made via other means. We note that such “flags” may leverage use of security labels like those included in the HL7 data segmentation for privacy (DS4P) implementation guides discussed in section III.C.10.b, or other data standards such as provenance or digital signature specifications.
We propose that the developer of a certified Health IT Module, under this standards-agnostic approach, would have the flexibility to implement the restriction on the inclusion in a subsequent use or disclosure via a wide range of potential means dependent on their specific development and implementation constraints (
We welcome public comment on this proposal. We also direct readers to section III.C.10.b of this section in which we propose and seek comment on an alternative to leverage security label standards as a source taxonomy for the “flag” applied to the data for the new criterion in § 170.315(d)(14).
We also propose to modify the Privacy and Security Framework in § 170.550(h) to add the proposed new criterion. Specifically, we propose to modify § 170.550(h)(iii) in reference to the certain of “care coordination” certification criteria in § 170.315(b); § 170.550(h)(v) in reference to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1); and to § 170.550(h)(viii) in reference to the § “application access” certification criteria at § 170.315(g)(7) through (g)(9) and the “standardized API for patient and population services” certification criterion at § 170.315(g)(10).
We propose that the new “patient requested restrictions” certification criterion in § 170.315(d)(14) would be required for the Privacy and Security Framework by January 1, 2026.
We welcome public comment on this proposal.
Finally, we propose a modification to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1) in order to support patients' ability to leverage technology to exercise their right to request a restriction under the HIPAA Privacy Rule. We propose that a Health IT Module certified to the criterion in § 170.315(e)(1) must also enable an internet-based approach for patients to request a restriction of use or disclosure of their EHI for any data expressed in the USCDI standards in § 170.213. Specifically, we propose to modify § 170.315(e)(1) to add a paragraph (iii) stating patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213.
The current version of the § 170.315(e)(1) “view, download, and transmit to 3rd party” certification criterion uses the concept of “internet-based” to convey, at § 170.315(e)(1)(i), that “[p]atients (and their authorized representatives) must be able to use
We propose that conformance with this update to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1)(iii) would be required by January 1, 2026, for Health IT Modules certified to § 170.315(e)(1). Consistent with our proposals in sections III.A and III.C.11, developers of certified health IT with Health IT Modules certified to § 170.315(e)(1) would have to update those Health IT Modules to § 170.315(e)(1)(iii) and provide them to customers by January 1, 2026.
We welcome public comment on this proposal.
We do not propose any changes to the current certification criteria for “security tags—summary of care—send” and “security tags—summary of care—receive” in § 170.315(b)(7) and § 170.315(b)(8) respectively; however, we note that the inclusion of the proposed new certification criterion in § 170.315(d)(14) into the Privacy and Security Framework in § 170.550(h) would mean that the proposed new certification criterion would be applicable for Health IT Modules certified to the security tags—send and security tags—receive certification
We seek comment on the capabilities we have proposed for the new criterion in relation to the HIPAA Privacy Rule right to request a restriction. We specifically seek comment on whether the proposed new criterion should include additional functions to better support compliance with the HIPAA Privacy Rule right to request a restriction. We also seek comment on whether the proposed new criterion should, for example, include capabilities to support HIPAA Privacy Rule provisions for emergency disclosures in § 164.522(a)(1)(iii) and (iv) or termination of a restriction under § 164.522(a)(2). We direct readers to section III.C.10.c for further discussion and specific questions for consideration.
Finally, we seek public comment on each part of this proposal—the new criterion in § 170.315(d)(14), the inclusion of the request capability for patients in § 170.315(e)(1), and the requirements with the Privacy and Security Framework in § 170.550(h)—both separately and as a whole. We specifically seek comment on the feasibility of each part in terms of technical implementation and usefulness for patients and covered entities using these capabilities. We also seek comment on the health IT development burden associated with implementation of the capabilities including for the individual certification criterion referenced in the Privacy and Security Framework in § 170.550(h).
In addition, we seek comment on any unintended consequences that the new criterion in § 170.315(d)(14) or the addition to the Privacy and Security Framework in § 170.550(h) might place on patients, clinicians, or other covered entities using certified health IT. We seek comment on whether, and by how much, the use of this criterion as part of broader privacy workflows might represent a reduction in manual effort for covered entities, a positive impact on uptake by patients, or other benefits such as supporting documentation of restrictions as required under the HIPAA Privacy Rule in § 164.522(a)(3).
Finally, we seek comment on methods by which we might quantify the development burden and costs as well as the potential benefits or future cost savings for the new criterion in § 170.315(d)(14), the new functionality in the existing criterion in § 170.315(e)(1), and the addition to the Privacy and Security Framework in § 170.550(h).
In addition to the primary proposal above, we also propose a set of alternatives for the new certification criterion proposed in § 170.315(d)(14), and we seek comment on various options related to the potential use of standards and the scope of both the applicable data and the use cases. Our primary proposal described in section III.C.10.a above for the new criterion in § 170.315(d)(14) does not specify any required standard or implementation specification for the criterion; rather, it describes the desired functionality absent standards.
In the alternative proposals below, we seek comment on the potential use of data segmentation for privacy standards and implementation specifications, the number and types of applicable use cases supported by the implementation specifications that should be certified, and the data elements that could be tagged with security labels that must be supported for each criterion. This set of alternatives contrasts with our primary proposal by naming specific standards and implementation specifications for the new criterion in § 170.315(d)(14) to achieve patient-requested restrictions.
In the 2015 Edition Final Rule, we adopted and incorporated by reference the HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 (HL7 CDA DS4P IG) in § 170.205(o)(1) and § 170.299 respectively. In the ONC Cures Act Final Rule, we updated certification criteria supporting the application of security labels at a granular level for sending in (in § 170.315(b)(7)) and receiving (in § 170.315(b)(8)), which reference the HL7 CDA DS4P IG (85 FR 25707). The HL7 CDA DS4P IG was balloted in 2014 and reaffirmed by HL7 in 2019.
The HL7 CDA DS4P IG establishes four types of reusable and platform neutral structures referred to as “Privacy Annotation Building Blocks.” These include Confidentiality Level, Purpose of Use, Obligation Policy, and Refrain Policy. In the HL7 FHIR DS4P IG, these categories are described as “Tag Sets” and expanded slightly to include a “General Purpose of Use,” category and associated value set. Each of these building blocks provide metadata regarding sensitivity levels, handling instructions, and permitted uses of data, and they are represented as a security label. Both of these IGs (collectively referred to hereafter as the HL7 DS4P IGs) leverage the HL7 Privacy and Security Healthcare Classification System (HCS) Security Label Vocabulary, which provides a common syntax and semantics for interoperable security labels in health care. The HCS Security Label Vocabulary and HL7 DS4P IGs' Privacy Annotation Building Blocks and Tag Sets are meant to support several computable “actions,” to segment data in different contexts. We understand that the combination of different actions in different contexts creates significant optionality and may be difficult to implement, even with the assistance of HL7 DS4P IGs. As such, we propose and seek comment on a standards agnostic approach and several alternative approaches that would reference a standard and constrain optionality of these standards in specific ways.
As described in section III.C.10.a, we propose a new criterion “patient requested restrictions” in § 170.315(d)(14) that is standards agnostic, rather than require use of a specific standard for the Security Label vocabulary or application of security labels. We believe this approach would provide flexibility for developers of certified health IT to provide this functionality in ways that are convenient for their underlying system structures and in support of existing workflows for patient requested restrictions under the HIPAA Privacy Rule. However, we seek comment on a set of alternate proposals which would instead reference the HL7 CDA DS4P IG and the HL7 FHIR DS4P IG and which consider the potential to adopt these standards with constraints.
This alternative approach—proposing that § 170.314(d)(14) reference specific standards rather than proposing it be standards agnostic—would remove ambiguities inherent in the standards agnostic proposal by establishing a basis for the “flag” on the data using consensus standards for security labeling. The use of these standards may also facilitate implementation of capabilities to support patient requested
Specifically, the alternative proposals are as follows:
• In section III.C.10.b.i, we seek comment on a set of alternate proposals adopting each of the HL7 DS4P IGs, the HCS Security Label Vocabulary, or both for the new criterion in § 170.315(d)(14).
• In section III.C.10.b.ii, we seek comment on alternate proposals adopting the HL7 DS4P IGs and/or the HCS Security Label Vocabularies with constraints beyond those described in the IGs, that, if finalized, would constrain the requirements within the IGs to only certain use cases.
• In section III.C.10.b.iii, we seek comment on an additional alternate proposal that, if finalized, would limit the specified scope of USCDI data that the proposed new criterion in § 170.315(d)(14) and the proposed revised criterion in § 170.315(e)(1) would be required to support.
We additionally seek comment on the technical feasibility of each alternative, including the potential development burden and any associated burden on patients, clinicians, or other covered entity using certified health IT, as well as the positive impact on uptake by patients, or other benefits such as supporting documentation of restrictions as required under the HIPAA Privacy Rule in § 164.522(a)(3).
We propose and seek comment on three alternatives that would adopt and apply standards and implementation specifications to the proposed new criterion in § 170.315(d)(14).
•
•
•
We welcome public comment on these three alternate proposals, including which approach would be most effective or feasible in terms of implementation of the standards options described for the proposed criterion in § 170.315(d)(14). We direct readers to section V of this proposed rule for more detail and request for comment on the HL7 FHIR DS4P IG proposed for incorporation by reference for the purposes of the alternate proposal for the criterion in § 170.315(d)(14).
We also specifically seek public comment on whether these alternate proposals for the proposed criterion in § 170.315(d)(14) would help to define the requirements for the criterion in a manner that would be more beneficial or more burdensome than a standards agnostic approach, and if so, which alternate proposal would be most beneficial. We seek comment on the health IT development burden and cost associated with implementation of the IGs described. We seek comment on any unintended consequences that the use of these standards might place on health IT developers, patients, clinicians, or other covered entities using certified heath IT. We seek comment on whether, and by how much, the use of these standards might represent a reduction in the burden of manual privacy workflows otherwise still necessary under a standards agnostic approach. We seek comment on the potential benefits to patients, or other benefits such as supporting documentation of restrictions as required under the
We note that the HL7 DS4P IGs specify security labels for a wide range of use cases, privacy policies, applicable actions and segmentation of data beyond the scope of the patient right to request a restriction under the HIPAA Privacy Rule. We, therefore, also propose and seek comment on an alternative that would reference these standards as described in section III.C.10.b.i, but would specify the scope of use to only require support for the privacy workflows associated with the HIPAA Privacy Rule patient right to request a restriction on disclosure or use rather than on the full range of privacy and security workflows that the standards may support. This alternative proposal for the proposed criterion in § 170.315(d)(14) would reference the HL7 DS4P IGs or the HCS Security Label Vocabulary but would not require the implementation of all applicable security labels or actions described in these specifications. We seek comment on whether, for the purposes of certification, we should adopt the HL7 DS4P IGs or reference the HCS Security Label Vocabulary as described in the alternate proposals in sub-section i. but with additional constraints to narrow the scope. We seek comment on whether we should adopt specific constraints to allow health IT developers to demonstrate the capability to filter, redact, or implement another defined action only for certain use cases supported by the security labels in the HCS Security Label Vocabulary, Privacy Annotation Building Blocks, and Tag Sets. For example:
• Should we constrain the requirements to apply the IGs for only certain general purposes or purposes of use? Specifically, should we limit requirements described in the applicable IGs for actions defined by PurposeofUse and GeneralPurposeofUse values associated with purposes allowed for patient requested restriction under the HIPAA Privacy Rule? These value sets include a range of references that could be used to limit the scope. For example, one value describes a label based on a patient choice to participate, or not, in clinical trials (CLINTRCH). In addition, which values in the PurposeofUse and GeneralPurposeofUse value sets would be most appropriate for the purpose of the patient requested restriction under the HIPAA Privacy Rule?
• Should we constrain the requirements to apply the IGs for only certain actions described for the restrictions? Specifically, should we limit requirements described in the applicable IGs for actions described under the RefrainPolicy ValueSet to only those defined actions relating to the patient request for restriction use case? Which values would be most appropriate for that purpose? For example, should we focus on actions to support the value NOATH, NOCOLLECT, NOINTEGRATE, or NOLIST? What other values in the RefrainPolicy ValueSet define actions that would also be appropriate for the use case?
• Should we limit requirements described in the applicable IGs for actions defined under the ObligationPolicy ValueSet that are necessary to implement the patient request for restriction or individual choice use case? For example, should we focus on support for the value REDACT? What other values would also be appropriate for the use case? Would either or both of these proposed alternatives to constrain the scope of the HL7 DS4P IGs reduce complexity and support feasibility for implementation of the new criterion in § 170.315(d)(14)?
• Are there health IT development burden considerations associated with implementation of these alternatives, including for the certification criteria in § 170.315(b) and (g) referenced in the Privacy and Security Framework in § 170.550(h)(3)(iii) and (viii)? Are there unintended consequences that these constraints on the proposed criterion in § 170.315(d)(14) might place on health IT developers, patients, clinicians, or other covered entities using certified health IT? Are there clear methods by which we might quantify the development burden and costs as well as the potential benefits or future cost savings for this proposed alternative constrained version of the proposed criterion in § 170.315(d)(14)?
We propose and seek comment on an additional alternative beyond those referenced above in sections III.C.10.b.i and III.C.10.b.ii. This additional alternative would limit the total scope of data required for certification to the proposed new criterion in § 170.315(d)(14) and the proposed revisions to the existing criterion in § 170.315(e)(1). Under this alternate proposal, instead of the full scope of data expressed in the USCDI standards in § 170.213, as referenced in proposed § 170.315(d)(14)(i) and the proposed revisions to the existing criterion in § 170.315(e)(1), certification for these criteria would apply for only the Patient Demographics/Information, Clinical Notes, Medications, and Health Status Assessments data classes within the USCDI. We additionally seek comment on whether some other scope of certain data classes or data elements would be most appropriate.
We welcome public comment on these alternate proposals both individually and in combination. We seek comment on whether these proposed constraints on the scope of the applicable data would reduce complexity and support feasibility for implementation of the new proposed criterion in § 170.315(d)(14) and the proposed revisions to the existing criterion in § 170.315(e)(1). We seek comment on the health IT development burden associated with implementation of the constrained capabilities in relation to the individual certification criteria in § 170.315(b) and (g) referenced in the Privacy and Security Framework in § 170.550(h)(3)(iii) and (viii).
We also seek comment on any unintended consequences that these constraints on the data in the new criterion in § 170.315(d)(14) and the proposed revisions to the existing criterion in § 170.315(e)(1) might place on health IT developers, patients, clinicians, or other covered entities using certified health IT.
Finally, we seek comment on clear methods by which we might quantify the development burden and costs as well as the potential benefits or future cost savings for this proposed alternative to constrain the USCDI referenced in the proposed criterion in § 170.315(d)(14) and the proposed revisions to the existing criterion in § 170.315(e)(1).
ONC certifies capabilities of Health IT Modules to perform specific functions, in many circumstances using specific standards. These are generally restricted to technical standards and capabilities. The user of the technology may also need to comply with certain requirements established by federal, state, territory, local or tribal law. Our intent for proposing a technical means for patients to request a restriction on their data is to advance tools that
We seek comment on whether there are modifications, adjustments, additions, or restrictions we should consider for our proposal to better support privacy workflows under the HIPAA Privacy Rule:
• Are there modifications, adjustments, additions, or restrictions that could support the termination of a restriction request as described under § 164.522(a)(2)? Should such a capability be a requirement for the proposed new criterion in § 170.315(d)(14)?
• Are there modifications, adjustments, additions, or restrictions that could support emergency use or disclosure of otherwise restricted information as described under § 164.522(a)(1)? Should such a capability be a requirement for the proposed new criterion in § 170.315(d)(14)? In such instances, how would the original restriction request be documented and persisted to prevent redisclosure or use subsequent to emergency use or disclosure as described under § 164.522(a)(1)(iv)?
• Are there modifications that would better support the documentation of restrictions as described under § 164.522(a)(3)? Are there modifications, adjustments, additions, or restrictions we should consider for our proposal to better support privacy workflows under other HIPAA Privacy Rule provisions? For example, are there modifications that would specifically support covered entities in implementing protections based on patient preferences for the prevention of harm for patients as allowable under § 164.524(a)(3)? Are there modifications, adjustments, additions, or restrictions we should consider for our proposal to better support privacy workflows under other applicable law? For example, are there modifications that would specifically support patient preferences for the privacy of EHI under state laws restricting disclosure of health information of minors? Are there modifications, adjustments, additions, or restrictions that would specifically support patient preferences for applicable laws related to disclosure and use of EHI related behavioral health or substance abuse? Are there modifications, adjustments, additions, or restrictions that would specifically support patient preferences for restrictions on disclosure or use related to stigmatized care under other state laws?
In section IV.C.3 of this proposed rule, we outline a range of questions for public comment and request information to specifically consider the policy implications related to supporting health IT users' ability to segment and selectively display, delay, or withhold EHI consistent with patient preferences for information sharing, applicable law, and other considerations such as when a delay or other interference with particular EHI access, exchange, or use may be reasonable and necessary under the conditions of an information blocking exception. We direct readers to section IV.C.3 for discussion and questions related to an illustrative sampling of use cases for data segmentation and user/patient access management functionalities. We also welcome public comment on this proposal to support patients' right to request a restriction of disclosure in the context of information sharing requirements under the ONC Cures Act Final Rule.
Section 3001(b) of the PHSA directs the National Coordinator to conduct the duties defined in section 3001(c), including the implementation of a certification program in section 3001(c)(5) of the PHSA, “in a manner consistent with the development of a nationwide health information technology infrastructure that allows for the electronic use and exchange of information.” This includes considerations for health IT to reduce costs resulting from inefficiency and incomplete information, to provide appropriate information to help guide medical decisions at the time and place of care, to improve the coordination of care, to facilitate a rapid response to public health threats and emergencies, and to promote greater efficiencies in the marketplace. As ONC administers the Program and adopts new or updated standards, implementation specifications, and certification criteria on behalf of the Secretary under section 3004 of the PHSA, we must also seek to address these requirements. When the healthcare industry and healthcare standards community update or develop new clinical guidelines, address emerging public health challenges, implement new state or local laws targeting high priority health issues, or develop new interoperability standards for enhanced care coordination, ONC often must also adopt aligned updates to the standards, implementation specifications, and certification criteria applicable in the Program. This is essential to ensure that certified capabilities of health IT continue to support the development of a nationwide health IT infrastructure.
Previously, such updates were implemented via an entirely new “edition” of certification criteria. As described in section III.A of this proposed rule, while this approach supported clarity for Program requirements at a given time, we believe the burden and rigidity of the “edition” approach render it unsustainable over the long term. A more modular approach that can accommodate changes for specific use cases without disrupting the entirety of the marketplace through a wholesale “edition” update is more appropriate to support an interoperable health IT infrastructure across a wide range of use cases (
In the 2015 Edition Proposed Rule, we clarified our expectation that ONC-
Subsequently, the Cures Act added to section 3000 of the PHSA a definition of “interoperability” (at 42 U.S.C. 300jj(9)) with respect to health information technology (also defined in the PHSA (42 U.S.C. 300jj(5)) as such health information technology that: (1) enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user; and (2) allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable State or Federal law.
In this proposed rule, as we move away from the use of editions to define timeframes for updating to new and revised certification criteria (
We propose to make explicit in the introductory text in § 170.315 that health IT developers voluntarily participating in the Program must update their certified Health IT Modules—including when new standards and functionality are adopted—and provide that updated certified health IT to customers in accordance with the timelines defined for a specific criterion or standard where included, such as via cross-reference, in § 170.315. We propose that health IT developers with health IT certified to any of the certification criteria in § 170.315 would need to update their previously certified Health IT Modules to be compliant with any revised certification criterion adopted in § 170.315 (please see section III.A of this proposed rule for the proposed definition of revised certification criterion (or criteria)), including any certification criteria to which their Health IT Modules are certified that reference new standards adopted in 45 CFR part 170 subpart B, and capabilities included in the revised certification criterion. Health IT developers would also need to provide the updated heath IT to customers of the previously certified health IT according to the timelines established for that criterion and any applicable standards. In addition to supporting the goals of the Program, we believe this approach will help to advance interoperability. Requiring health IT developers who voluntarily participate in the Program to update Health IT Modules to revised certification criteria (including new and revised standards) can help to advance capabilities for access, exchange, and use of EHI for authorized use under applicable State or Federal law. In addition, ensuring health IT developers voluntarily participating in the Program provide such updates to customers will help to enable the secure exchange of EHI with, and use of EHI from, other health information technology without special effort on the part of the user. We believe these proposed timelines also serve to support clear and transparent benchmarks for furthering interoperability throughout the health IT infrastructure.
As noted previously, the updates to criteria may include technical capabilities such as security enhancements or additional transactions not previously supported for a criterion. These updates may also include an expansion of the data supported by content, vocabulary, and format standards to increase the scope of interoperable EHI. For example, as new data elements are standardized, updates to criteria may help to incorporate these data elements into clinical systems in an interoperable manner. Such advancement could be in response to an emergent need such as a public health response, but it may also be for commonly used information that is essential to care but for which representation via standard vocabularies has lagged behind. One such example is the inclusion of functional status, disability status, and mental or cognitive status in the USCDI v3.
In the ONC Cures Act Final Rule, we discussed how we expected developers to make technology updates available to their customers (see, for example, 85 FR 25665) in relation to the 2015 Edition Cures Update. We stated that health IT developers would have until the applicable deadline to make technology certified to these updated criteria available to their customers, and during this time developers may continue supporting technology certified to the
We also included a requirement to “provide” customers with updated Health IT Modules as a Maintenance of Certification requirement (
Consistent with section 3006 of the PHSA, we note that under this proposed rule, a developer of certified health IT would not be required to provide updated technology to any customer that elected to decline the update for any reason. Such reasons might include a customer choosing to discontinue use of a specific Health IT Module or product, or to no longer participate in HHS programs that require the use of certified health IT. We note that in such cases, while the Health IT Module may still operate, it would no longer be certified and may no longer meet program requirements for HHS programs requiring the use of certified health IT. Specifically, we propose that for all revised certification criteria in § 170.315, a developer of certified health IT shall update their certified health IT to such criteria and provide these updates to their customers in accordance with the dates identified for each revised certification criterion, including for standards referenced by the criteria in accordance with the dates identified for each applicable standard in 45 CFR part 170 subpart B.
As mentioned above, in section III.D of this proposed rule, we describe our proposal for Condition and Maintenance of Certification requirements under the Assurances Condition of Certification for health IT developers of certified health IT. By doing so, we propose both the technical requirements for conformance to the certification criterion and the behavioral requirements for conformance to the condition in the Program. As described in section III.D, this Condition of Certification provides specified periods of time to “update and provide” certified health IT. We note that in some cases the timelines and expiration dates for applicable capabilities and standards defined for a certification criterion in § 170.315 may be longer or shorter than the standard period of time defined in the proposed condition of certification. This difference is due to our analysis of the urgency of the use case, the readiness for the capability or standard, and the current use of such capability or standard by the healthcare industry, including consideration of dependent requirements across HHS programs.
We welcome comments on this proposal.
Section 4002(a) of the Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification under the Program, provide assurances satisfactory to the Secretary that such developer, unless for legitimate purpose(s) as specified by the Secretary, will not take any action that constitutes information blocking as defined in section 3022(a) of the PHSA or any other action that may inhibit the appropriate exchange, access, and use of EHI. In the ONC Cures Act Final Rule, we adopted specific Conditions and Maintenance of Certification requirements for health IT developers of certified health IT consistent with this authority (
The Conditions of Certification that were codified focused on health IT developers providing assurances that: their health IT certified under the Program conforms to the full scope of the certification criteria; they would not take any action that could interfere with a user's ability to access or use certified capabilities for any purpose within the full scope of the technology's certification; and, for those with a certified Health IT Module that is part of a health IT product that electronically stores EHI, they would certify to the EHI Export certification criterion. These Conditions of Certification, and in some instances accompanying Maintenance of Certification requirements, provide assurances to the Secretary, and by default to customers and users of certified health IT, that health IT developers are not taking actions that could potentially constitute information blocking, or at the least, inhibit the appropriate exchange, access, and use of EHI.
In this proposed rule, we propose to establish a new Condition of Certification and accompanying Maintenance of Certification requirements under the Assurances Condition of Certification. These new requirements would serve to provide the assurances to the Secretary that Congress sought and further clarify Program requirements that are established under the authority provided in section 3001(c)(5) of the PHSA and discussed in detail above in section III.C.11 (“Requirement for Health IT Developers to Update their Previously Certified Health IT”).
We propose in § 170.402(a)(5), that, as a Condition of Certification, a health IT developer must provide an assurance that it will not inhibit a customer's timely access to interoperable health IT certified under the Program. To support this assurance, we propose accompanying Maintenance of Certification requirements, which are discussed in detail below. The Maintenance of Certification requirements define the scope of this proposed Condition of Certification and provide clarity in terms of what it would mean to take the action of “inhibiting,” what constitutes “timely access,” and what is “interoperable health IT certified under the Program.”
Interoperable health IT is an underpinning of the Program and particularly the conditions of certification found in the Cures Act and implemented in 45 CFR part 170 subpart D. Congress established support for health IT interoperability beginning with the authority provided in the HITECH Act to adopt standards (including implementation specifications and certification criteria) and establish the Program. It continued to emphasize health IT interoperability through requiring the establishment of metrics to determine the extent of “widespread interoperability” in the Medicare Access and CHIP Reauthorization Act (MACRA) (section 106(b)(1)). Ultimately, Congress went on to define interoperability with respect to health IT in the Cures Act, including incorporating the information blocking definition within the interoperability definition. Congress further incorporated or specifically referenced the interoperability definition where it required, in 42 U.S.C. 300jj-11(c)(5)(D), the Secretary to establish certain Conditions of Certification, including the “Communications,” “Real World Testing,” and “Insights” Conditions of Certification.
With this proposed rule, we propose that, for purposes of certification and the maintenance of such certification under the Program, a health IT developer would need to provide an assurance that its health IT is certified to the most recently adopted certification criteria and such certified health IT is made available to its customers in a timely manner (see below and section III.C.11). These actions are essential because certification criteria, and in particular revised certification criteria (as defined in this proposed rule), include standards, implementation specifications, and capabilities that support and improve interoperability as that term is defined by the Cures Act and incorporated in 45 CFR part 170. Since the inception of the Program, ONC has updated certification criteria to include the most recent versions of standards and implementation specifications that most appropriately support and improve interoperability at the time of adoption. This is because as standards and implementation specifications evolve, they, by their very nature, improve interoperability by allowing for more complete access, exchange, and use of all electronically accessible health information. Further, the interoperability definition also focuses, in part, on the secure exchange and use of EHI from other health IT without special effort on the part of the user. The Assurances Condition is an important piece to supporting and achieving these goals because it seeks assurances from health IT developers that they will not take any actions to inhibit the appropriate access, exchange, and use of EHI.
As a more practical and concrete implementation of the Assurances Condition and of supporting interoperability, it is important for users, particularly customers of developers of certified health IT, to have health IT certified to the most recent standards and capabilities. Otherwise, a health IT developer voluntarily participating in the Program would be undermining interoperability and making it more difficult for customers of health IT developers of certified health IT to access, exchange, and use EHI as updated standards (
We first propose, in § 170.402(b)(3)(i), that a health IT developer must update a Health IT Module, once certified to a certification criterion adopted in § 170.315, to all applicable revised certification criteria, including the most recently adopted capabilities and standards included in the revised certification criterion. For clarity, `
We propose separate “timely access” or “timeliness” Maintenance of Certification requirements for each of the two proposed Maintenance of Certification requirements above that would dictate by when a Health IT Module must be updated to revised certification criteria, including the most recently adopted capabilities and standards; and by when a Health IT Module certified to a revised certification criterion, including the most recently adopted capabilities and standard, must be provided to the health IT developer's customers. We propose, in § 170.402(b)(3)(iii), that unless expressly stated otherwise in 45 CFR part 170, a health IT developer must complete the proposed “update” and “provide” requirements according to the following proposals. First, we propose, in § 170.402(b)(3)(iii)(A), that a health IT developer must update and provide a Health IT Module by no later than December 31 of the calendar year that falls 24 months after the effective date of the final rule adopting the revised certification criterion or criteria. This would mean that, depending on the day when the final rule effective date fell, a health IT developer would have between two years and potentially up to
To illustrate when and how the “provide” and “timeliness” requirements would be applicable to a health IT developer beyond the “update” scenario recited above, we offer the following explanations. If a developer “expanded the scope” of a certified Health IT Module to include certification to a revised certification criterion, then the “provide” condition would be applicable. In such cases, all of the health IT developer's customers would be considered “new” customers for purposes of the Health IT Module certified to the revised certification criteria criterion as the
In all the above circumstances, we propose that health IT certified to revised certification criteria must be provided to all customers, including new customers (
Unless expressly stated otherwise in 45 CFR part 170, a health IT developer must complete the “update” and “provide” requirements:
• By no later than December 31 of the calendar year that falls 24 months after the effective date of the final rule adopting the revised certification criterion or criteria; or
• If the developer obtains new customers of health IT certified to the revised certification criterion after the effective date of the final rule adopting the revised certification criterion or criteria, then the health IT developer must provide the health IT certified to the revised certification criterion to such customers within whichever of the following timeframe that expires last:
○ By no later than December 31 of the calendar year that falls 24 months after the effective date of the final rule adopting the revised certification criterion or criteria; or
○ No later than 12 months after the purchasing or licensing relationship has been established between the health IT developer and the new customer for the health IT certified to the revised certification criterion.
The proposed above timeframes would offer health IT developers, at a minimum, no less than 12 months to provide health IT certified to revised certification criteria to new customers (
This USCDI v3 proposal not only would override the “24 month or more” timelines, but it also illustrates the importance of the “update and provide” proposals in this rule that support interoperability. The adoption of USCDI v3 would expand the data required to be accessible through certified health IT beyond the data elements included in USCDI v1 and thus would increase the amount of data available to be accessed, exchanged, and used for patient care. However, if a health IT developer with certified health IT inhibited its customers' timely access to health IT certified to USCDI v3 (
If a health IT developer did
To note, we propose a conforming revision to the Real World Testing Maintenance of Certification requirements in § 170.405(b) in that we propose to remove most of the “update and provide” requirements currently found in this section because they are moot based on the publication date of this proposed rule and the subsequent publication of a final rule for this proposed rule (
In the ONC Cures Act Final Rule, we finalized requirements in § 170.405(a) that a health IT developer with Health IT Module(s) certified to § 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h) must: successfully test the real world use of the technology for interoperability in the type(s) of setting(s) in which such technology would be marketed. We established in § 170.405(b) that each developer's annual real world testing plan is required to be published by December 15 of a given year and would need to address all of the developer's Health IT Modules certified to criteria listed in § 170.405(a) as of August 31 of that year (85 FR 25769). We also finalized that this annual real world testing plan would pertain to real world testing activities to be conducted in the year following the December 15 plan publication due date, with an annual
However, many health IT developers update their Health IT Module(s) on a regular basis, leveraging the flexibility provided through ONC's Inherited Certified Status (ICS).
In order to ensure that all developers test the real world use of their technology as required, we propose to eliminate this anomaly by requiring health IT developers to include in their real world testing results report the most recent version of those Health IT Module(s) that are updated using Inherited Certified Status after August 31 of the year in which the plan is submitted. This will ensure that health IT developers fully test all applicable Health IT Modules as part of their real world testing requirements. Please note, this proposal would prevent a developer from avoiding, or delaying conducting or reporting real world testing specifically on the updated versions of Modules certified through Inherited Certification Status after August 31 of a given year. This proposal would not change the underlying requirement that a developer with one or more Health IT Modules certified to any criterion listed in § 170.405(a) must plan, conduct, and report on real world testing of each of those Health IT Modules on an annual basis. We seek comment on this proposal.
The Cures Act specified requirements in section 4002(c) to establish an Electronic Health Record (EHR) Reporting Program to provide transparent reporting on certified health IT in the categories of interoperability, usability and user-centered design, security, conformance to certification testing, and other categories, as appropriate to measure the performance of EHR technology. Data collected and reported would address information gaps in the health IT marketplace and provide insights on the use of certified health IT.
To develop the EHR Reporting Program, ONC contracted with the Urban Institute and its subcontractor, HealthTech Solutions, to engage the health IT community for the purpose of identifying measures that developers of certified health IT would be required to report on as a Condition and Maintenance of Certification under the Program. The Urban Institute published a final report in February 2022, which included a recommended set of measures for the EHR Reporting Program. ONC conducted additional research and expert consultations to refine the recommended set of measures in the Urban Institute's final report. Based on the additional research and expert consultations, we propose in this proposed rule, to modify the measures that the Urban Institute developed, consistent with section 3009A(a)(4) of the PHSA. We propose our modified versions of the measures in this proposed rule and solicit comment on both the underlying measures and our proposed modifications to them. In other words, our proposals with respect to each measure reflect how we propose to modify the set of measures in the Urban Institute's final report.
For clarity purposes, we intend to refer to the Condition and Maintenance of Certification associated with the “EHR Reporting Program” as the “Insights” Condition and Maintenance of Certification (also referred to as the “Insights Condition”) throughout this proposed rule. We believe this descriptive name captures a primary policy outcome of this requirement.
The proposed measures associated with the Insights Condition described in this proposed rule relate to and reflect the interoperability category in section 3009A(a)(3)(A)(iii) of the PHSA. They relate to four aspects or areas of interoperability, which we refer to as “areas” throughout this proposed rule: individuals' access to EHI, public health information exchange, clinical care information exchange, and standards adoption and conformance, as discussed in further detail below. The majority of our proposed measures are data points derived from certified health IT systems. The proposed measures generally consist of numerators and denominators that will help generate metrics (
As mentioned above, ONC contracted with the Urban Institute and its subcontractor, HealthTech Solutions, to engage the health IT community for the purpose of identifying measures that developers of certified health IT would be required to report on as a Condition and Maintenance of Certification under the Program. Identification of developer measures began with a broad literature and market scan, including market research discussions with subject matter experts, to identify potential measures for the categories specified in the Cures Act. The approach for identifying measures included several considerations, such as priority interoperability functions, relevance to ONC policy priorities and broader interests, measures reflecting information that ONC cannot obtain without regulation, and efforts that are not duplicative of other data collection.
The Urban Institute published draft measures for public feedback. ONC charged the HITAC to review the draft measures and provide recommendations to the National Coordinator on the draft measures. Both the HITAC and public were asked to provide feedback on topics such as frequency of reporting; data granularity; appropriateness of look-back periods; clarity of definitions and measurement; benefit of measures relative to burden of collecting data; how to address potential interpretation challenges; potential burden on users of certified health IT; potential burden on small or start up developers of certified health IT; and value of measures to provide insights on interoperability. The HITAC transmitted recommendations to the National Coordinator on September 9, 2021. The Urban Institute's public feedback period ended on September 14, 2021.
After the public feedback period ended, the Urban Institute conducted feasibility testing with targeted respondents to assess the extent to which developers of certified health IT could produce and report on prospective measures. Specifically, the feasibility testing focused on understanding developers' ability to produce data required to calculate the
The Urban Institute published a final report in February 2022, which included a recommended set of measures. The Urban Institute considered public feedback, HITAC recommendations, and feasibility testing with developers in determining the recommended set of measures included in the Urban Institute's final report.
ONC conducted additional research to modify the recommended set of measures in the Urban Institute's final report. The proposed measures included in this proposed rule were modified to reduce ambiguities and to address potential costs and burdens. Consistent with section 3009A(a)(3)(C) of the PHSA, we propose to modify the measures the Urban Institute developed, as well as implement minimum reporting qualifications designed to ensure that small and startup developers are not unduly disadvantaged by the proposed measures.
We note that the following proposed measures are for the initial Insights Condition requirements. In future rulemaking, we anticipate proposing additional measures for future iterations of the Insights Conditions and Maintenance of Certification requirements under the Program.
Through this first set of proposed measures, ONC intends to provide insights on the interoperability category specified in the Cures Act (as codified at section 3009A(a)(3)(A)(iii) of the PHSA). We intend to explore the other Cures Act categories (security, usability and user-centered design, conformance to certification testing, and other categories to measure the performance of EHR technology) in future requirements.
We seek feedback on how we may further refine the proposed measures to improve feasibility, clarity, and potential insights gained. We welcome comments from the public on the proposed measures and overall Program processes related to the Insights Conditions and Maintenance of Certification. As stated above, the following describes our rationale for proposing the measure, proposed numerators and denominators, and key topics for comment.
We also have explored various pathways on how to make it easier for the public to view and comment on the detailed technical specifications supporting the proposed measures. While the substantive requirements for each measure are defined in this proposed regulation, we have determined that measure specification sheets would be a logical and accessible method for the public to also review and provide comment on the technical specifications supporting those requirements. This is consistent with the approach used by other HHS programs to solicit public feedback related to measure technical specifications (
While the following proposed measures, as detailed below, require unique and specified data points, there are certain requirements that we propose to apply across multiple measures, including but not limited to: (1) data submitted by health IT developers would be provided and aggregated at the product level (across versions); (2) health IT developers would provide documentation related to the data sources and methodology used to generate these measures; and (3) health IT developers may also submit descriptive or qualitative information to provide context as applicable. The Cures Act specifies, per section 3009A(b) of the PHSA, that as a Condition of Maintenance of Certification, a health IT developer shall submit responses to the criteria developed with respect to all certified technology offered by such developer. Due to the specified requirements of the proposed measures, we believe it is reasonable to expect health IT developers, as part of their responses, to provide documentation used to generate the proposed measures for more accurate and complete data calculation. Overall, the documentation should help ensure the data is interpreted correctly. Thus, the documentation related to the data sources and methodology would include the types of data sources used, how the measure was operationalized (
For measures where patient encounters are relevant, we propose the definition of an encounter should be based on the National Committee for Quality Assurance (NCQA) outpatient value set and SNOMED CT inpatient encounter codes. For outpatient codes, developers should use NCQA's Outpatient Value Set.
We selected these value sets because they were recommended by HITAC
Other shared requirements relate to similar sets of denominators across some of the measures. This should reduce burden associated with the measures. For example, the number of encounters during a reporting period is used as a denominator for the individual access to electronic health information measure, the immunization measures, and the clinical exchange measures.
We refer readers to section III.F.4 of this preamble below for a discussion of the reporting period, reporting submission process, and other reporting requirements, that apply across measures associated with the Insights Condition's requirements.
A number of federal policies have sought to increase individuals' access to their EHI. In 2014, CMS' EHR Incentive Programs, supported by the Program, required participating hospitals and eligible health care providers to adopt certified EHR technology with capabilities that enable individuals to electronically view, download, and transmit their health information, which was largely implemented via a patient portal.
Given the national efforts made to advance the use of EHI with the goal of enhancing patient engagement and improving health outcomes, it is important to monitor the uptake and usage of EHI by individuals. ONC has largely relied on national surveys
Recently, third-party apps have emerged as an alternative method for individuals to view and manage their EHI. These apps are considered “third-party” because they are not directly associated with a health care provider or the developer of the provider's certified health IT, but instead are developed and marketed by an outside software developer. Some third-party apps permit patients to view their EHI using certified API technology (as defined in § 170.404(c)) that integrates the app with information in the health care provider's certified health IT using the Health Level Seven (HL7®) Fast Healthcare Interoperability Resources (FHIR®) standard, HL7 SMART Application Launch Framework and other associated standards and implementation specifications.
Given the different access methods that now exist, we propose an individuals' access to their EHI measure (as further discussed below) to require developers of certified health IT to report on the different methods individuals use to access their health information. This proposed measure would provide more detailed insights into the implementation and use of this capability by individuals, including whether and to what extent individuals are using third-party apps to access their EHI. We also seek to differentiate between individuals who access their EHI using these methods who had an encounter during the reporting period from those that did not have an encounter during the reporting period, as this differentiation would provide insights into usage for other convenience-oriented reasons (
We propose to adopt the “Individuals' Access to Electronic Health Information Supported by Certified API Technology” measure within the “Individuals' Access to Electronic Health Information” area in § 170.407(a)(1). We propose to require that any developer of certified health IT with Health IT Modules certified to either the “view, download, and transmit to a 3rd party” certification criterion (§ 170.315(e)(1)), or the
We propose two distinct numerators and three denominators as part of the measure in § 170.407(a)(1). As noted earlier in this section, we plan to generate multiple metrics from a combination of different numerators and denominators. We propose the first numerator to be the number of unique individuals who had an encounter and accessed their EHI at least once during the reporting period via at least one of three types of methods: (1) third-party app using technology certified to “standardized API for patient population services” certification criterion under § 170.315(g)(10); (2) patient portal using technology certified to the “view, download, and transmit to 3rd party” certification criterion under § 170.315(e)(1) only; or (3) app offered by the health IT developer or health care provider using technology certified to the API criterion under § 170.315(g)(10) (if applicable). We propose a second numerator to be the number of unique individuals who accessed their EHI regardless of an encounter during the reporting period using at least one of the same three types of methods identified above. Each of these numerators would be stratified or reported by type of method.
These proposed numerators differ from those developed by the Urban Institute by separating the numerators by individual encounter and EHI access status instead of by method. As explained above, this differentiation would provide insights into usage for other convenience-oriented reasons (
We propose the first denominator for this measure to be the total number of unique individuals who had an encounter (as defined earlier in this preamble) during the reporting period. We propose the second denominator to be the total number of unique individuals who used at least one of the types of methods referenced above to access their EHI who had an encounter during the reporting period. We propose the third denominator to be the total number of unique individuals who used at least one of the three types of methods referenced above to access their EHI during the reporting period (regardless of whether the individual had an encounter or not).
The data collected for this specification would enable ONC to calculate the following metrics:
Our proposed measure would provide insight into the methods patients use to access their EHI through certified health IT. We believe this measure is important because as noted earlier in this section, increasing patients' access to their data can increase patient engagement and improve health outcomes.
We believe this proposed individuals' access measure will provide a national view into how individuals access their EHI and will inform ONC and health IT community efforts to empower individuals with access to their EHI. We welcome comments on our proposed measure.
We propose two measures under the “Clinical Care Information Exchange” area in §§ 170.407(a)(2) and (3). The proposed measures are titled, “Consolidated Clinical Document Architecture (C-CDA) Documents Obtained Using Certified Health IT by Exchange Mechanism” and “C-CDA Problems, Allergies and Medications Reconciliation and Incorporation Using Certified Health IT.” These measures are primarily focused on characterizing the state of information exchange between health care providers who are customers of health IT developers with certified health IT, in contrast to other measures that capture exchange with individuals, public health agencies, and other entities.
There are numerous mechanisms by which information can be exchanged between organizations using certified health IT, such as point-to-point, developer network-facilitated, or through state health information exchange. Neither the current level of exchange by particular mechanisms nor trends of exchange by mechanism is clear. For example, the use of surveys to gather this information is limited. Based on a national survey analysis of hospitals,
Some health information networks do publish the volume of exchange they facilitate. For instance, DirectTrust
Therefore, we propose to adopt the “Consolidated Clinical Document Architecture (C-CDA) Documents Obtained Using Certified Health IT by Exchange Mechanism” measure, which would report on the volume of C-CDA documents obtained using certified health IT by exchange mechanism relative to patient volume. A developer of certified health IT with Health IT Modules certified to the “clinical information reconciliation and incorporation” certification criterion in § 170.315(b)(2) would be required to report the proposed numerators and denominators for this measure.
There are four numerators and four denominators for this proposed measure. As noted earlier in this section, we plan to generate multiple metrics from different combinations of these numerators and denominators. For example, a single numerator can be used with two different denominators to produce two different metrics. We propose to adopt the following numerators for this measure: (1) number of unique C-CDA documents obtained (which we define for the purpose of this proposal as either C-CDAs that are received—that is, C-CDAs that have been sent or `pushed' by others and received using certified health IT
We propose to adopt the following denominators for this measure: (1) number of encounters during the reporting period; (2) number of unique patients with an encounter during the reporting period; (3) number of unique patients with an associated C-CDA document during the reporting period; and (4) number of unique C-CDA documents obtained (received or queried) using certified health IT during the reporting period. We propose to include denominators for the number of encounters during the reporting period and the number of unique patients seen (
The data collected for this proposed measure would enable ONC to calculate the following metrics:
• The number of unique C-CDA documents obtained using a local/regional HIE or national HIN divided by the number of unique C-CDA documents obtained using certified health IT within the reporting period.
• The number of unique C-CDA documents obtained using developer-specific networks divided by the number of unique C-CDA documents obtained using certified health IT within the reporting period.
• The number of unique C-CDA documents obtained using Direct Messaging divided by the number of unique C-CDA documents obtained using certified health IT within the reporting period.
• The number of unique C-CDA documents obtained using other means divided by the number of unique C-CDA documents obtained using certified health IT within the reporting period.
• The number of unique patients with associated C-CDA documents obtained within the reporting period divided by the number of unique patients with an encounter within the reporting period.
• The number of unique C-CDA documents obtained using certified
• The number of unique C-CDA documents obtained using certified health IT within the reporting period divided by the number of unique patients with an associated C-CDA documents obtained within the reporting period.
• The number of unique C-CDA documents obtained using certified health IT within the reporting period divided by the number of encounters during the reporting period.
This proposed measure would capture C-CDA documents obtained by electronic transport mechanisms, including national HINs (
Using data gathered under this measure, we would also be able to examine trends in the use of various mechanisms for exchange of health information over time. Monitoring the volume of exchange by various mechanisms is critical to monitoring the implementation of key ONC policies that support exchange and interoperability, including most recently TEFCA (87 FR 2800). ONC seeks to facilitate exchange so that interoperability is best supported. Understanding varying usage of different mechanisms could better inform ONC policies because not all exchange mechanisms may adequately support true interoperability. Understanding where the market is with regards to the usage of exchange mechanisms that support interoperability (versus those that do not) is critical to informing ONC policy. Furthermore, examining variation in usage of exchange mechanisms can provide insights into what mechanisms may be limited to certain use cases, and whether some mechanisms implicitly or explicitly favor some parties (
We seek comment on whether it would be meaningful to further reduce the mechanisms of exchange measure into fewer categories, by combining regional HIE and/or national HIN and developer-specific HINs into one category (network-mediated exchange) and combining Direct Messaging and “other methods” into a second category (exchange directly between two entities). Thus, an alternative proposal would be to reduce the exchange mechanisms from three categories to two categories. We also seek comment on whether the expected burden associated with this measure would, in practice, be reduced if the number of categories were reduced.
We propose to adopt the “C-CDA Medications, Allergies, and Problems Reconciliation and Incorporation Using Certified Health IT” measure, which would capture the number of C-CDA documents that are reconciled and incorporated (as defined in § 170.315(b)(2)(iii)) as part of a patient's record by clinicians or their delegates. A developer of certified health IT with Health IT Modules certified to the “clinical information reconciliation and incorporation” certification criterion in § 170.315(b)(2) would be required to provide information on how data in C-CDA documents are used, focusing on the reconciliation and incorporation of medications, allergies and intolerances, and problems.
We propose the numerator to be the total number of C-CDA documents of the Continuity of Care Document (CCD), Referral Note, Discharge Summary document types that are obtained and incorporated across all exchange mechanisms supported by the certified health IT during the reporting period. The numerator would increment, or increase in number, upon completion of clinical information reconciliation of the C-CDA documents for medications, allergies and intolerances, and problems, as described in the certification criterion in § 170.315(b)(2).
We propose the denominators for this measure to match the denominators for the “C-CDA Documents Obtained Using Certified Health IT by Exchange Mechanism” proposed measure, using the definition of “encounter” described previously in this proposal. The data collected for this proposed measure would enable ONC to calculate the following metrics:
• The total number of C-CDA documents (CCD, Referral Note, Discharge Summary) obtained and incorporated divided by the number of encounters during the reporting period.
• The total number of C-CDA documents (CCD, Referral Note, Discharge Summary) obtained and incorporated divided by the number of unique patients with an encounter during the reporting period.
• The total number of C-CDA documents (CCD, Referral Note, Discharge Summary) obtained and incorporated divided by the number of unique patients with an associated C-CDA document during the reporting period.
• The total number of C-CDA documents (CCD, Referral Note, Discharge Summary) obtained and incorporated divided by the number of unique C-CDA documents obtained (received or queried) using certified health IT during the reporting period.
This proposed measure can be used to inform the extent to which information is being incorporated into a patient's record as discrete data that is trackable over time. Our proposed measure includes several metrics intended to directly measure the success of certified health IT in supporting reconciliation and incorporation of C-CDA documents. Our specifications are intended to ensure the measure captures several key dimensions of information reconciliation. First, we intend the measure to capture the success of certified health IT at facilitating maintenance of a patient's record composed of discrete data that is trackable over time through the incorporation of medications, allergies and intolerances, and problems into the medical record as appropriate. This would help us understand the degree to which information received from C-CDA documents is subsequently available for use after receipt and incorporation. Second, the measure is
This measure is closely related to a measure used by CMS in the Promoting Interoperability performance category of MIPS and the Medicare Promoting Interoperability Program. CMS generally describes their measure “Support Electronic Referral Loops by Receiving and Incorporating Health Information” (originally finalized in 83 FR 59811 and 83 FR 41661, respectively) as capturing the rate at which problems, medication allergies, and medications were reconciled and incorporated out of all transitions of care or referrals for which a health care provider received an electronic summary of care record. In contrast to the CMS measure, our proposed measure would provide a more nationally representative view of the use of certified health IT since many clinicians, including those in small practices, do not report for the Promoting Interoperability performance category of MIPS. Among those that do report for the Promoting Interoperability performance category of MIPS, many do not report this information, either because they claim an exclusion from reporting the measure or they report on the optional Health Information Exchange (HIE) Bi-Directional measure in lieu of reporting performance on the Support Electronic Referral Loops by Receiving and Incorporating Health Information measure.
We note that a majority of developers of certified health IT should already be capable of supporting some components of our proposed measure because of the existing requirements for the Promoting Interoperability performance category of MIPS and the Medicare Promoting Interoperability Program and ONC certification criteria related to measuring exchange under “automated numerator recording” (§ 170.315(g)(1)) and “automated measure calculation” (§ 170.315(g)(2)). We note that approximately 68% (517 of 818) of Health IT Modules listed on CHPL are certified to one or both of these criterion as of the second quarter of the 2022 calendar year. Therefore, we believe our proposed measure should impose a low burden on a majority of developers of certified health IT to fully implement as part of this Insights Condition. We request comment on the anticipated burden associated with this measure.
We request comment on whether focusing on the three types of C-CDA documents described above in the proposed numerator (CCD, Referral Note, Discharge Summary) would impose a substantial burden beyond summary of care records. We request comment on the value of focusing on these three document types relative to all types of summary of care records. We also request comment on whether meaningful measures could be generated without de-duplication of C-CDAs, how often duplicate C-CDA documents may be obtained by customers of certified health IT, and how much of a burden it will impose on developers of certified health IT to ensure that C-CDA documents are not duplicates.
We propose to adopt four measures in the “Standards Adoption and Conformance” area in §§ 170.407(a)(4) through (7) to provide insight into the role that standards play in enabling access, exchange, and use of EHI. We propose to measure the following aspects within this area: (1) availability of apps to support access to EHI for a variety of purposes; (2) the usage of FHIR-based APIs to support apps; (3) the use of bulk FHIR to support the access to EHI for groups of individuals; and (4) the use of EHI export functionality. Together, these measures would provide a foundation for understanding whether and to what extent ONC's policies to promote standards are supporting users of health IT, including patients, clinicians, researchers, and others, to access and use EHI via certified health IT for a variety of purposes. These measures would also provide visibility into industry adoption of standards required by the Program and provide data to inform future standards development work.
We propose to adopt an “Applications Supported Through Certified Health IT” measure, which would provide information on how certified health IT is supporting the health app ecosystem by asking certain health IT developers under the Program to report app names and app developer names, intended app purposes, intended app users, and whether a registered app is in “active” use across a developer's client base (as further detailed below). This measure would result in a listing of apps that could be used to generate a variety of metrics. Only developers of certified health IT with Health IT Modules certified to the “standardized API for patient and population services” (§ 170.315(g)(10)) certification criterion would be required to report data for this proposed measure.
As there is currently no comprehensive source of this type of information, we believe that data reported through this measure would provide greater transparency regarding the apps that are connected to certified health IT. This measure will provide information on most apps connected to developers of certified health IT with
Therefore, we propose that developers of certified health IT with Health IT Modules certified to § 170.315(g)(10) provide the following information about the apps that are connected to their certified technology. We propose that the app name and the developer (company/organization or individual) responsible for the app shall be reported for each app registered to a developer of certified health IT whose Health IT Module is certified to the § 170.315(g)(10) criterion. We note that the app registration process required under § 170.315(g)(10)(iii) may provide an opportunity for developers of certified health IT to gather standard information for apps connecting to their certified API technology as part of existing workflows. There may be other mechanisms besides the app registration process by which developers of certified health IT wish to obtain this information.
This measure would enable ONC and the public to understand to what degree apps are able to connect across different certified health IT products. The ONC Cures Act Final Rule (85 FR 25750) emphasized the importance of standardization, transparency, and pro-competitive business practices through the API Condition and Maintenance of Certification requirements that would make it easier for third-party apps to connect to certified health IT, and subsequently facilitate individuals' access to their EHI. By collecting the names of apps and developers connecting to developers of certified health IT whose Health IT Module is certified to § 170.315(g)(10), ONC and the public will be better able to identify whether certain apps are only connecting to one certified health IT product versus other apps that may be connecting to multiple different certified health IT products. This information provides insights into whether apps are able to connect to a variety of certified health IT products, which is important for enabling individuals' access to their EHI.
We propose that developers of certified health IT with Health IT Modules certified to § 170.315(g)(10) obtain and report the intended purpose(s) for each app connected to their certified API technology using the following categories:
Developers of certified health IT to whom the measure applies would report the intended purpose(s) of the app for each app registered to their Health IT Module(s) certified to the § 170.315(g)(10) criterion. The categories we propose under this measure were informed by app category taxonomies in published literature from Barker & Johnson (2021),
We propose that developers of certified health IT with Health IT Modules certified to § 170.315(g)(10) obtain the following intended user(s) categories for each app connected to their certified API technology:
These proposed categories include a variety of users and would provide a better understanding of the extent to which apps are available and in use for different types of users, since the intended purpose alone may not shed light on the types of users for which the app is intended. For example, some apps intended for research purposes may have both patients and researchers as users, whereas others may be intended for research alone. It is important to understand the breadth of intended users of apps to provide insights into the impacts of ONC's efforts on users' ability to access EHI via certified API technology through apps.
We propose that developers of certified health IT with Health IT Modules certified to § 170.315(g)(10) obtain the status for each app connected to their certified API technology using the following categories:
• Actively Used—An app is defined as “Actively Used” if EHI has been transferred to the app using certified API technology for 10 or more unique patients during the reporting period.
• Not Actively Used—An app is defined as “Not Actively Used” if EHI has been transferred to the app using certified API technology for fewer than
We recognize that apps registered to certified API technology may not necessarily be in production nor have any users, and thus an indicator of active use would be important to differentiate those apps in use, versus those not ready for use (or that may never make it to that stage). This will provide an accurate indicator of the availability of apps based upon the usage activity. Without this indicator of active use, we would not know if an app was registered but never in production, and thus the value of the overall data would be limited. We welcome comments on our proposed “active use” status categories, including their definitions, and welcome comment on whether these categories reflect how app status is currently monitored by developers of certified health IT.
We believe our proposed measure would provide information that would be useful to guide future policy and assess ongoing efforts to support app connectivity to certified health IT. This data would also provide insight into whether and how impactful ONC standards and policies are to expanding the availability of apps, including the “standardized API for patient and population services” (§ 170.315(g)(10)) certification criterion. Additionally, this measure would produce a list of apps that would provide information on the degree to which apps are able to connect to multiple different certified health IT systems in a seamless manner. We believe capturing this information over time would provide insights into the evolution of the types of apps that are available for meeting the needs of various end users of app technology to support a variety of critical purposes. We welcome comments on our proposed measure.
We propose to adopt a “Use of FHIR in Apps Supported by Certified API Technology” measure, which would capture the volume of FHIR resources transferred in response to API calls from apps connected to certified API technology by FHIR resource type. We also propose that the volume of FHIR resources transferred be reported by FHIR version used and by U.S. Core Implementation Guide version deployed. This measure would also require developers to report FHIR resources transferred in response to calls from two different endpoint types: patient-facing and non-patient-facing, the latter of which would include endpoints that do not facilitate individuals' access (
Similar to other measures, we propose a number of numerators and denominators that would be used to generate a variety of metrics. We propose the first numerator to be the number of FHIR resources returned/transferred in response to a call to a certified API technology by resource type. We propose the second numerator to be the number of distinct certified API technology deployments (across clients) associated with at least one FHIR resource returned/transferred in response to a call. We note that each of the numerators would be stratified (
We propose the denominator to be the total number of distinct certified API technology deployments (across clients). In addition, we propose this denominator to be stratified by type of endpoint (patient-facing vs. non-patient facing), FHIR version, and U.S. Core Implementation Guide. We note that non-FHIR APIs, such as those represented with proprietary standards, are excluded from this measure, including numerators and denominators.
The data collected for this proposed measure would enable ONC to calculate the following metrics:
This proposed measure could be used to monitor progress related to ONC's efforts to make EHI accessible through standardized APIs. The implementation of the “standardized API for patient and population services” certification criterion in § 170.315(g)(10) plays an important role in our approach to nationwide access, exchange, and use of EHI without special effort. As industry implements standard APIs for patient and population services, it is important to understand (1) the extent to which health IT capabilities are in place to support access to EHI via FHIR-based APIs; (2) the degree to which those capabilities are available to be used; and (3) the use of those capabilities in practice.
We are currently using multiple data sources to measure the use of FHIR in apps supported by certified API technology. By using data from the CHPL, CMS program data, and national survey data of hospitals, ONC has conducted analyses that provide insights into the capabilities of certified health IT to support FHIR APIs. Through the Lantern Project,
The proposed measure would build on these other data sources and add to our collective understanding by assessing to what degree these
Requiring health IT developers of certified health IT to report FHIR resources transferred in response to calls from two different endpoint types, patient-facing endpoints and non-patient-facing (
As stated above, this proposed measure would also require that developers report the volume of FHIR resources transferred in response to calls by FHIR version and by U.S. Core Implementation Guide. While Health IT Modules certified to § 170.315(g)(10) are required to respond to requests according to FHIR version Release 4, we are aware that in the future there will be newer versions of FHIR supported by newer versions of the U.S. Core Implementation Guide. Gaining insights into the frequency in use of U.S. Core Implementation Guides would help inform ONC regarding variability in the implementation of FHIR across developers. Having these measures stratified by FHIR resource version, in addition to the U.S. Core Implementation Guide, could help ONC advance the use of FHIR APIs. Knowing which FHIR and U.S. Core Implementation Guides are in use would provide insights into where the industry is currently, and where it may be headed with regards to the implementation of specific versions of FHIR.
We request feedback on whether information on both aspects of the measure, FHIR version and U.S. Core Implementation Guide, are necessary as each provides unique insights or whether focusing on just one of these (either FHIR version or U.S. Core Implementation Guide) would be feasible and sufficient for understanding where the industry is with regards to the implementation of FHIR. We also seek comment on the feasibility of reporting the use of different HL7 FHIR implementation guides and FHIR versions overall, versus stratified by type of endpoint, type of FHIR resources, and by the number of certified API technology deployments.
Finally, as this proposed measure would require developers to report on the number of certified API technology deployments they support across their customer base, we believe it is important to examine usage not only at the product level of a health IT developer with certified health IT, but also across the organizations that are using those products. Therefore, we propose to require health IT developers of certified health IT to whom the proposed measure would be applicable to report the number of certified API technology deployments (as a proxy for organizations that have installed certified API technology) where FHIR resources were transferred in response to a call (relative to the total number of certified API technology deployments). This information can shed light on whether usage is concentrated versus dispersed, indicating the breadth of usage across end users and organizations. However, given that API deployments may vary across developers, we seek feedback on whether this measure would be a good proxy for understanding usage across their client bases. Overall, data on the usage of FHIR resources by type of resource, endpoint, version, and U.S. Core Implementation Guide, would provide greater transparency and insights on the availability and use of different data elements available through certified API technology. In addition, we would also be able to monitor trends as data is reported over time and gain a sense of whether and how useful standards required by the “standardized API for patient and population services” certification criterion are to understanding the state of health data interoperability. We welcome comments on our proposed measure.
We propose to adopt the “Use of FHIR Bulk Data Access through Certified Health IT” measure, which would measure the number of bulk data downloads completed through certified health IT relative to the number of certified health IT deployments or installations. Specifically, this measure would provide information on how certified health IT is being used to perform “read” services for a specified patient population using the HL7® FHIR® Bulk Data Access (Flat FHIR) V1.0.1 standard. A developer of certified health IT with Health IT Modules certified to the “standardized API for patient and population services” (§ 170.315(g)(10)) certification criterion would be required to report under this proposed measure.
We propose the first numerator to be the number of data/download requests completed during the reporting period using certified health IT certified to the “standardized API for patient and population services” (§ 170.315(g)(10)) in response to a bulk data download request to export all data for patients within a specified group. We propose the second numerator to be the number of distinct certified health IT deployments or installations certified to the “standardized API for patient and population services” (§ 170.315(g)(10)) (across clients) that successfully completed at least one bulk data download request during the reporting period.
We propose the denominator to be the total number of distinct certified health IT deployments or installations (across clients).
The data collected for this proposed measure would enable ONC to calculate the following metrics:
• Percent of certified health IT deployments or installations with at least one successfully completed bulk data download request.
• Rate of bulk data download requests successfully completed per certified health IT deployments or installations.
Our current ability to measure the Bulk FHIR access is limited to using national survey data through which
We also note and clarify that non-standard or proprietary resources (
We propose to adopt the “Use of Electronic Health Information Export through Certified Health IT” measure which would capture the use of certified health IT to export single patient and patient population EHI. A developer of certified health IT with Health IT Modules certified to the “electronic health information (EHI) export” (§ 170.315(b)(10)) certification criterion would be required to report data under this proposed measure.
We propose a count for this measure (rather than a numerator and denominator) that includes the number of full data EHI exports requests processed during the reporting period and reported by the following subgroups: (1) by a single patient EHI export; and (2) by patient population EHI export. While this stratification differs from what the Urban Institute reported, we believe that it will give more precise insights into how the EHI export certification criterion is used. We also propose reports should include a “yes” or “no” attestation for enabling direct-to-individual EHI exports.
The data collected for this proposed measure would enable ONC to calculate the following metrics:
• Count of full data EHI export requests processed by single patient and patient populations requests.
• Whether or not the certified Health IT Module supports direct-to-individual EHI exports.
The EHI export certification criterion in § 170.315(b)(10) requires that certified health IT have the capability to export single patient and population-level data. This function provides a means for patients to obtain copies of their EHI and equips health care providers with better tools to transition patient EHI from one health IT system to another. The proposed measure would report on the number of EHI export requests processed by a health IT developer and provide insights on the implementation of the EHI export capability. Current data sources to provide insights on the use of the EHI export function are limited, and our experiences with surveys of health care providers indicate that many health care providers, particularly office-based clinicians, may not be familiar with the technical terminology, and thus survey data would not serve as a useful data source for the use of this functionality. Therefore, by requiring data to be reported under this measure, we would be able to understand if the capability is functioning in the market as intended. We welcome comments on our proposed measure.
We noted in the ONC Cures Act Final Rule (85 FR 25695) that the EHI Export certification criterion in § 170.315(b)(10) does not require “direct-to-patient” functionality in order for a developer to demonstrate conformance to the criterion. However, we did not preclude this functionality, and we seek comment as part of this proposed rule on whether any products support direct-to-patient EHI Export functionality to inform future policy decisions. We also seek comment on whether it would be valuable for this measure to be reported by “use case” for why the data was exported (
The COVID-19 pandemic has exposed many gaps and challenges in the nation's public health infrastructure, including a need for more accurate and timely data, increased electronic exchange of patient health information between health care providers and public health agencies, and greater support for vulnerable individuals and communities disproportionally affected by the pandemic.
Our proposed public health information exchange measures would address these gaps by measuring whether and to what extent providers are using their certified health IT to electronically send and receive public health information to and from public health agencies. We believe that more detailed measurement of health care providers' ability to use certified health IT to successfully exchange health information with public health agencies would provide critical data for pandemic response and other public health emergencies.
In furtherance of our efforts to assess public health exchange, we propose to adopt a public health exchange measure that would report on the volume of immunization administrations electronically submitted to an immunization information system through certified health IT. This measure would capture the use of certified health IT to send information on vaccination and immunization administrations to an IIS. Specifically, this measure would require health IT developers of certified health IT with Health IT Modules certified to the “transmission to immunization registries” (§ 170.315(f)(1)) criterion to report on the number of records of immunizations administered that were sent electronically to an IIS during the reporting period. We propose that developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) that do not have users that administered immunizations during the reporting period would attest that they are unable to report on this measure.
The intent of the proposed “Immunization Administrations Electronically Submitted to an Immunization Information System through Certified Health IT” measure is to ensure that ONC has the information necessary to assess whether Health IT Modules certified to § 170.315(f)(1) are being used to support electronically sending vaccination information data to IIS, which has proven to be critical to public health preparedness and response. While ONC has attempted to capture similar data via surveys, the data is limited by sample size and may not fully reflect certified health IT usage for exchanging data with an IIS since survey-based data does not provide information on actual usage. Thus, our proposed measure would give a more complete view of sending data to an IIS. In addition, this proposed measure goes beyond the Promoting Interoperability performance category of MIPS and the Medicare Promoting Interoperability Program's measurement of “active engagement,” which does not indicate the volume of data successfully transmitted to public health agencies. Our proposed measure would address these information gaps by measuring transactions whereby health care providers use their certified health IT to electronically send public health information on vaccines administered to public health agencies.
For the numerator, we propose developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) report the number of immunization administrations from which the information was electronically submitted to an IIS successfully during the reporting period by IIS and age group. We propose that the numerator and denominator counts would be reported overall (across IIS and age subgroups) and by the following subgroups: (1) number of administrations by IIS; and (2) number of administrations by IIS and age group (adults (18 years and over) and children/infants (17 years and under)). The definition of a successful submission to an IIS would be the total number of messages submitted minus acknowledgments with errors (2.5.1, severity level of E). We believe this definition will avoid limitations from IIS jurisdictions that do not send HL7 Acknowledgment messages (ACKs) for this measure. Given that we propose that ACKs with an error (severity level of E)
We are also considering whether “replays,” which involve resubmitting administrations until they are successfully submitted, qualify as a successful submission. In other words, we seek comment on whether successful submissions should be limited to the first attempt to submit. We believe “replays” should qualify as a successful submission since the purpose of this proposed measure is to identify administrations successfully submitted, not necessarily those submitted on the initial try, and welcome public comment on this.
We propose the denominator for this measure to be the number of immunizations administered during the reporting period. We propose this denominator be stratified by the following subgroups: (1) number of administrations reported to each IIS; and (2) number of administrations reported to each IIS, by age group (adults (18 years and over) and children/infants (17 years and under)). This measure differs from that developed by the Urban Institute by the inclusion of stratifications by IIS and age group. Given the variation in immunization reporting requirements and patient consent by state or jurisdiction, reporting of administrations by IIS is critical to interpreting the data correctly, therefore we propose this measure to be stratified by IIS. In addition, given that immunization requirements are different for children and adults, we propose stratifying by age group as well. Reporting by these subgroups will assist in interpreting the data and in creating public awareness that could inform IISs and others in the public health community about the progress being made in immunization data exchange. To further inform public health exchange efforts, we also seek comment on whether adolescents/infants should be further stratified by age, and by what age limits. For providers who operate in multiple states, and thus would be sending data for the same administration to multiple IISs, we seek comment on whether a successful submission should be counted if a provider is able to successfully submit
The data collected for this proposed measure would enable ONC to calculate the percent of immunizations administered where the information was electronically submitted to an IIS.
We believe this measure would inform public health information exchange efforts about how frequently and effectively health care providers are using their certified health IT to send immunization data to an IIS. In addition, we believe that more detailed measurements of health care providers' engagement in public health exchange would provide critical data in response to a pandemic or other public health emergencies. We welcome feedback on the proposed “Immunization Administrations Electronically Submitted to an Immunization Information System through Certified Health IT” measure.
We propose to adopt a public health information exchange measure to require reporting on the number and percentage of IIS queries made per individual with an encounter.
For the numerator, we propose developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) report the number of query responses received successfully from an IIS overall and by subgroup, by IIS and age group (adults (18 years and over) and children/infants (17 years and younger)) during the reporting period. The definition of a successful response from an IIS should be the total number of messages submitted minus acknowledgments with errors (2.5.1, severity level of E). However, since HL7 Z42 messages contain both immunization history and forecast, whereas Z32 messages exclusively contain history, we seek comment on whether both message types should be included in the measure numerator.
The first denominator we propose for this measure would be the total number of immunization queries overall and by subgroup, by IIS and age group (adults (18 years and over) and children/infants (17 years and younger)) during the reporting period. We propose to add this denominator to the measure proposed by the Urban Institute to provide data on the total number of query responses that are and are not successfully received from an IIS. This will give further insights into any potential technical challenges that may be occurring during query exchange. The second denominator we propose for this measure would be the total number of encounters overall and by subgroup during the reporting period. However, since it is unlikely that queries happen for every patient encounter, we seek comment on whether the second denominator should capture to total number of applicable patient encounters during the reporting period regardless of whether a query was sent to an IIS. The numerator and denominator counts would be reported overall (across IIS and age subgroups) during the reporting period and by the number of IIS queries made by IIS and age group (adults (18 years and over) and children/infants (17 years and younger) during the reporting period. We believe reporting by these subgroups would be necessary to interpret the data and create public awareness that could inform IISs and other public health participants about the progress being made in immunization data exchange. We seek comment on whether children/infants should be furthered divided and by what age limits.
The data collected for this proposed measure would enable ONC to calculate the following metrics:
• Percent of immunization forecast queries responses from an IIS electronically received among all queries sent.
• Percent of immunization forecast queries responses from an IIS electronically received among all patient encounters.
We propose developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) would attest that they are unable to report on this measure if they have no users that administered immunizations during the reporting period. There may also be providers who do not administer immunizations but would want to query an IIS to determine whether their patient has received a vaccination. We seek comments on whether we should include this exclusion or suggestions on how we could better refine it.
We believe the measures under this area will inform public health information exchange efforts related to how frequently health care providers are using their certified health IT to send and query immunization data to an IIS, providing critical data for a response to a pandemic or other public health emergency. We welcome feedback on the proposed Public Health Information Exchange measures.
The Cures Act specifies that a health IT developer be required, as a Condition and Maintenance of Certification requirement under the Program, to submit responses to reporting criteria in accordance with the “Electronic Health Record Reporting Program” established under section 3009A of the PHSA, as added by the Cures Act, with respect to all certified technology offered by such developer. We propose to implement the Cures Act “Electronic Health Reporting Program” Condition and Maintenance of Certification requirements as the “Insights Condition and Maintenance of Certification” (Insights Condition) requirements in § 170.407. As a Condition of Certification, we propose that health IT developers of certified health IT would submit responses to comply with the Insights Condition's requirements, described in this section of the preamble in relation to the Insights Condition's measures and associated certification criteria.
As stated earlier in the preamble, the intent of the Insights Condition is to address information gaps in the health IT marketplace, as well as provide insights on how certified health IT is being used, consistent with Program certification criteria and associated conformance to identified technical standards. As required by section 3009A(a)(3)(C) of the PHSA, ONC worked with an independent entity, the Urban Institute, to develop measure concepts for the Insights Condition that would not unduly disadvantage small and startup developers. We propose modifications to the measures the Urban Institute developed to further ensure measures would not unduly disadvantage small and startup developers. The measures we propose reflect the functions of certified health IT and the ability of users to successfully use those functions, rather than reflect the resources and market
Therefore, we propose to implement the Insights Condition requirements in a way that does not unduly disadvantage small and startup health IT developers of certified health IT. We understand that developers of certified health IT would need to invest resources to capture and report on these proposed measures. We generally understand these resources to be relatively consistent across developers, regardless of the developer's organizational size. Given this understanding and with the objective to avoid unduly disadvantaging small and startup health IT developers of certified health IT, we propose to establish minimum reporting qualifications that a developer of certified health IT must meet to report on the measure. Developers of certified health IT who do not meet the minimum reporting qualifications (as specified under each measure), would submit a response to specify that they do not meet the minimum reporting qualifications under the Insights Condition measure. In this way, all developers of certified health IT would report on all measures, even if some report that they do not meet the minimum reporting qualifications.
The minimum reporting qualifications include whether a health IT developer has any applicable Health IT Modules certified to criteria associated with the measure, and whether the developer has at least 50 hospital users or 500 clinician users across its certified health IT products, which serves as a proxy for its size or maturation status (
In sum, a developer of certified health IT would be expected to report as required by each measure under the following circumstances:
• If the developer has at least 50 hospital users or 500 clinician users across their certified health IT products;
• Applicable criterion/criteria associated with the measure; and
• If the developer has any users of the applicable criterion/criteria associated with the measure.
Otherwise, the health IT developer would report that it does not meet the minimum reporting qualifications.
Additionally, a developer of certified health IT who meets the minimum reporting qualifications, has an applicable criterion or criteria associated with the measure, and has users of that criterion or criteria would be expected to report the following for each measure:
• Measure results;
• Required documentation used to generate the measure; and
• Optional documentation used to generate the measure.
We also propose that health IT developers of certified health IT report measures aggregated at the product level, across product versions. We believe that product level data would provide insights on how performance on the measures vary by market (
As stated above, we propose to require all health IT developers of certified health IT to comply with the initial Insights Condition's requirements. Developers who do not meet the minimum reporting qualifications specified under each measure must still comply with the Insights Condition's requirements by submitting a response that they do not meet the minimum reporting qualifications. The certification criteria to which the initial Insights Condition requirements apply include the following (as listed in Table 2):
Health IT developers of certified health IT that have less than 50 hospitals users or 500 clinician users across their certified health IT products would be required to submit a response that they do not meet the minimum reporting qualifications for each applicable measure. We believe this approach would allow us to collect nationally representative data, while allowing small and startup health IT developers of certified health IT to participate within their means. We seek comment on the effectiveness of this approach in ensuring that small and startup developers are not unduly disadvantaged.
As stated above, we propose the Insights Condition threshold for small and startup developers would only apply if a developer of certified health IT has no more than 50 non-federal acute care hospitals that participated (reported measure data and use of certified EHR technology) in the Medicare Promoting Interoperability Program and no more than 500 clinician users who participated in MIPS across all of the developer of certified health IT's products. The specific proposed threshold of no more than 50 hospital users or 500 clinician users across their products is based upon the goals of maximizing the number of certified health IT users represented through the program while not unduly disadvantaging small and startup health IT developers. The specific threshold of users is based upon the number of hospital users that participate in the Medicare Promoting Interoperability Program across a developer's products and the number of clinicians who participated in MIPS. The advantage of this approach is that the focus on clinicians and hospitals that participate in the Promoting Interoperability performance category of MIPS and the Medicare Promoting Interoperability Program aligns with past policy efforts to increase adoption and use of certified EHR technology (CEHRT). Additionally, Promoting Interoperability performance category of MIPS and the Medicare Promoting Interoperability Program data represent a consistent data source that can be used to set thresholds, though this approach may need to evolve over time as the market evolves. While most hospitals participate in the Medicare Promoting Interoperability Program, many clinicians do not participate in the Promoting Interoperability performance category of MIPS.
We have proposed thresholds based upon the goal of maximizing the number of end users on whose usage of certified health IT we receive data rather than the number of developers of certified health IT. We seek to receive data on a broad array of end users to ensure the measures are broadly representative; however, we also do not want to disadvantage small or startup health IT developers of certified health IT. Thus, we developed criteria designed to balance these goals. We propose thresholds so that we cover approximately 99% of the inpatient and outpatient certified health IT market share, consisting of hospital users and clinician users as measured by Promoting Interoperability performance category of MIPS and the Medicare Promoting Interoperability Program participation data (see analysis below). Setting this high bar would allow us to ensure that ONC and the public receive insights from a large share of certified health IT end users We used data from 2019 for the Promoting Interoperability performance category of MIPS and the Medicare Promoting Interoperability Program to develop the proposed thresholds for number of hospital and clinician users. The data included 4,209 non-federal care acute hospitals and 691,381 clinicians who participated in the CMS program. After limiting hospitals and clinicians to those using existing 2015 Edition certification criteria, the 2015 Edition Cures Update criteria, or a combination of the two; and to those products of developers who had certified to at least one of the criteria associated with the measures proposed as described above (see Table 2), we ended up with 3,863 hospitals
Based upon a threshold of 50 hospitals, we would be able to include approximately 99% of all hospital users and the top 18 developers (based upon market share) while excluding the bottom 33 developers (based upon market share). This 99% value is based upon the percentage of users who are not exclusively using products from small developers based upon the threshold. Therefore, in the case of a 50-hospital threshold, only 1.4% of hospital users are exclusively using products from small developers, and thus about 99% of the inpatient market would be covered.
If we implement the Insights Condition, including the proposed thresholds, as proposed, and if we subsequently determine that the market differs from 2019 (the year upon which these proposed thresholds are based) and the goal of covering approximately 99% of the inpatient and outpatient market share cannot be met with the proposed thresholds, we will intend to revisit the proposed thresholds to ensure coverage goals are being met. We request comment on this approach for setting thresholds.
We propose in § 170.407(b)(1) that, as a Maintenance of Certification requirement for the Insights Condition, health IT developers of certified health IT must submit responses every six months (
The HITAC recommended that ONC begin and end the reporting periods mid-year, ensuring that certain public health data (
To further minimize burden, we propose to provide developers of certified health IT with ample time to collect, assemble, and submit their data. We propose that developers of certified health IT would be able to provide their submissions within a designated 30-day window, twice a year. Under this proposal, health IT developers of certified health IT would begin collecting their data twelve months prior to the first 30-day submission window. The first six months of this period would be the period that health IT developers of certified health IT would report on for the first 30-day submission window. Health IT developers of certified health IT would then have the next six months to assemble this data for reporting. During the second six months of this period, health IT developers of certified health IT would begin collecting data for the next 30-day submission window and so on.
For example, if we establish the first 30-day submission window as April 1, 2025, we would expect developers of certified health IT to begin gathering data for the first six-month submission beginning April 1, 2024 (this reporting period would cover April 2024 through October 2024) and spend from October 2024 to April 2025 assembling their data for submission. Meanwhile, we would expect, under this example, developers of certified health IT would also be collecting data for the October 2025 submission during this same period, from October 2024 to April 2025. This
As stated above, we propose in § 170.407(b)(1) to require a developer of certified health IT with any applicable Health IT Module(s) that have or have had an active certification at any time under the Program during the prior six months to provide responses to the Insights Condition of Certification specified in paragraph (a) of this section semiannually (
We believe that initiating developer submission of responses for certain measures (as identified above) in April 2025 would allow us to both calculate and prioritize data relevant to ONC policy priorities and broader public interests. Monitoring patients' access to their electronic health information was identified as priority of the Cures Act, and ONC has taken major initiatives to enable that access, including improving patient access to their EHI through standard-based APIs. It is critical to assess the availability and ability for applications to integrate with EHRs in order to make that data accessible to individuals. The COVID-19 pandemic has enhanced the need for electronic exchange between health care providers and public health agencies. Therefore, we are also prioritizing the proposed measures related to immunization exchange. We believe the submission of responses for the remaining specified measures in April 2026 provides adequate time for developers of certified health IT to make necessary changes to their systems to collect data as described above—effectively giving developers from the time this rule is finalized to April 2025 to modify their systems to begin collecting data for submission in April 2026.
We welcome comments on our proposed approach, as well as the proposed frequency of reporting, other frequencies of reporting such as more or less frequent, and any additional burdens that should be considered for health IT developers of certified health IT to meet the proposed Insights Condition and Maintenance of Certification requirements.
We also note that there may be other factors that could impact a developer of certified health IT's ability to easily collect data to comply with the Insights Condition's requirements. For example, a developer of certified health IT may have contracts or business agreements that inhibit the health IT developer's ability to collect data from its customers. We note that in such scenarios, developers of certified health IT would need to renegotiate their contracts if we finalize our proposals. We expect developers of certified health IT would work to mitigate any issues and provisions affecting their ability to comply with this Condition and Maintenance of Certification requirement. Therefore, a developer of certified health IT that is required to meet the Insights Condition's requirements must submit responses or may be subject to ONC direct review of the Conditions and Maintenance of Certification requirements, corrective action, and enforcement procedures under the Program. We believe this is consistent with the enforcement for any noncompliance with the Conditions and Maintenance of Certification requirements and note that our goal is to work with health IT developers of certified health IT to remedy any noncompliance in a timely manner. We welcome comments on our approach, as well as any specific hardships health IT developers of certified health IT may encounter with the Insights Condition of Certification.
We propose that responses to the Insights Condition would occur via web-based form and method, consistent with the requirements in § 3009A(c) of the PHSA. We note that under the statute, developers of certified health IT must report to an “independent entit[y]” to “collect the information required to be reported in accordance with the criteria established.” We intend to award a grant, contract, or other agreement to an independent entity as part of the implementation of the Insights Condition and will provide additional details through subsequent information. We intend to make responses publicly available via an ONC website, and we intend to provide developers of certified health IT the opportunity to submit qualitative notes that would enable them to explain findings and provide additional context and feedback regarding their submissions.
Further, we propose a new Principle of Proper Conduct for ONC-Authorized Certification Bodies (ONC-ACBs) in § 170.523(u) that would require ONC-ACBs to confirm that applicable health IT developers of certified health IT have submitted their responses for the Insights Condition of Certification requirements in accordance with our proposals. We expect that the ONC-ACBs would confirm whether or not the applicable health IT developers submitted responses for the Insights Condition of Certification requirements within the compliance schedule. The intent of this responsibility is not to duplicate the work of the independent entity in collecting and reviewing the response submissions. Rather, it is instead meant to support the ONC-ACBs' other responsibility in § 170.550(l) to ensure that health IT developers of certified health IT are meeting their responsibilities under the Conditions and Maintenance of Certification requirements before issuing a certification.
We welcome comments on the proposed Insights Condition and Maintenance of Certification requirements.
We seek public feedback that may be used to inform a study and report required by Division FF, Title II, Subtitle B, Ch. 2, Section 2213(b) of the Consolidated Appropriations Act, 2023 (Pub. L. 117-328, Dec. 29, 2022), or future rulemaking regarding the adoption of standards and certification criteria to advance laboratory data interoperability and exchange.
ONC has long recognized the importance of enabling the electronic exchange of laboratory data and has addressed laboratory interoperability through a variety of activities. These include adoption of multiple certification criteria and standards related to laboratory data and interoperability as part of the Program. For example, the current certification criterion “Transmission to public health agencies—reportable laboratory tests and values/results” in § 170.315(f)(3) relates to Electronic Lab Reporting (ELR) to public health agencies and references the “Electronic transmission of lab results to public health agencies” standard in § 170.205(g). Other current Program criteria and standards associated with laboratory data interoperability include:
• “Computerized provider order entry—laboratory,” certification criterion (§ 170.315(a)(2));
• “View, download, and transmit to 3rd party,” certification criterion (includes laboratory test report(s) in § 170.315(e)(1)(i)(A)(
• “Transmission to public health agencies—reportable laboratory tests and values/results,” certification criterion (§ 170.315(f)(3));
• Laboratory tests, vocabulary standard (§ 170.207(c));
• Electronic transmission of lab results to public health agencies, content standard (§ 170.205(g));
In the proposed rule titled “2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications” (80 FR 16804), ONC proposed to adopt certification criteria specific to laboratory ordering that included HL7 version 2.5.1 Laboratory Order Interface (LOI) Release 2, Electronic Directory of Services (eDOS), and Laboratory Results Interface (LRI) Release 2 Implementation Guides (IGs). However, with consideration of public comments on the proposal, ONC did not adopt these IGs in the 2015 Edition Final Rule based on a number of factors that included insufficient readiness of the best versions of the IGs for the associated certification criterion (80 FR 62617 and 62685).
The COVID-19 pandemic has highlighted gaps in laboratory data exchange, particularly in reporting test results. Advancing standards-based exchange of data from the health IT used by ordering clinicians to laboratories' in vitro diagnostics systems and laboratory information systems, and from laboratories' systems to public health agencies and the EHR systems and other health IT used by health care providers or patients would be beneficial to laboratories, other types of health care providers, patients, and public health authorities. Over the past decade, new standards for health data exchange have emerged and gained acceptance, such as HL7® Fast Healthcare Interoperability Resources (FHIR®), and existing IGs for transmission of laboratory data using HL7 v2.5.1 have gained maturity and could be leveraged to improve laboratory interoperability.
Section 2213(b) of the Consolidated Appropriations Act, 2023 includes a provision directing ONC to conduct a study (and issue a report to Congress) on the use of standards for electronic ordering and reporting of laboratory test results.
We seek public comment generally on any topics identified above for the Consolidated Appropriations Act, 2023, Section 2213(b) study on the use of standards for electronic ordering and reporting of laboratory test results, such as the use of health IT standards by clinical laboratories, use of such standards by labs and their effect on the interoperability of laboratory data with public health systems, including any challenges of the types identified above. We also seek comment on whether ONC should adopt additional standards and laboratory-related certification criteria as part of the ONC Health IT Certification Program. ONC specifically seeks comments from the public on the following:
1. Which implementation guides or other standards should ONC adopt in certification criteria for health IT supporting transmittal and receipt of laboratory orders, laboratory results and directory of services?
2. The utility and maturity of existing HL7 v2 and C-CDA standards supporting laboratory interoperability and the impact of moving to FHIR-based laboratory data exchange.
3. What barriers would additional health IT certification criteria for laboratory interoperability create for developers and other interested parties, and how might this affect adoption and use of such technology?
4. Would developers of laboratory information systems or in vitro diagnostics systems that have not traditionally submitted products for certification under the Program seek out and benefit from certification to criteria relevant to such developers' products?
5. Are there any other steps that ONC and HHS should consider taking to advance laboratory interoperability?
Section 119 of Title I, Division CC of the Consolidated Appropriations Act, 2021, (Pub. L. 116-260) (CAA), requires PDP sponsors of prescription drug plans to implement one or more real-time benefit tools (RTBTs) after the Secretary has adopted a standard for RTBTs and at a time determined appropriate by the Secretary. The law specified that a qualifying RTBT must meet technical standards named by the Secretary, in consultation with ONC. Section 119(b)(3) also amended the definition of a “qualified electronic health record” in section 3000(13) of the PHSA to specify that a qualified electronic health record must include or be capable of including an RTBT. In the 2014 Edition Final Rule, ONC established the term “Base EHR,” based on the “Qualified EHR” definition, for use within the ONC Health IT Certification Program (Program) (77 FR 54262).
We intend to propose in future rulemaking the establishment of a real-time prescription benefit health IT certification criterion within the Program and include this criterion in the base EHR definition in § 170.102. We intend to propose a criterion that would certify health IT to enable a provider to view within the electronic prescribing workflow at the point of care patient-specific benefit, estimated cost information, and viable alternatives. We are also considering a
While we believe that implementing RTBT functionality required for inclusion in the Program under the CAA would be an important step towards improving prescribing experiences for providers and patients, we recognize that it is only one of a series of capabilities that are part of a comprehensive workflow for evaluating and prescribing medications. Other key processes working in concert with real-time prescription benefit capabilities may include:
• Drug Interaction Checks.
• Medication History.
• Formulary and Benefit Management.
• Eligibility Checks.
• Electronic Prior Authorization.
• Electronic Prescribing.
For example, if a prescriber initiates the real-time prescription benefit process when the prescriber launches an electronic prescribing application and chooses a clinically appropriate medication, the prescriber may have the ability to discuss prescription costs and other options with a patient at the point of care, and during this same process, receive notification that a prior authorization is needed for the prescription. Within the same workflow, prescribers could initiate electronic prior authorization processes, answer any questions, and complete any other requirements before transmitting the electronic prescription to the patient's preferred pharmacy. When the patient arrives at the pharmacy, the medication could be filled and dispensed immediately, and the patient would already be aware of price and copay responsibility information. This scenario is only one of many possibilities.
Today, the Program addresses these additional capabilities in a limited manner. For instance, in the ONC Cures Act Final Rule, ONC adopted NCPDP SCRIPT standard version 2017071 and updated the “electronic prescribing” certification criterion in § 170.315(b)(3)(ii) to reflect this standard, including specifying electronic prior authorization transactions supported by the standard as optional transactions, which health IT developers can elect to have explicitly tested, or not, as part of certification of a product to § 170.315(b)(3) (85 FR 25680).
A “drug-formulary and preferred drug list checks” certification criterion had been established for the 2015 Edition in § 170.315(a)(10) but was later removed from the Program by the ONC Cures Act Final Rule (85 FR 25660). ONC removed the criterion due to the lack of associated interoperability standards and to reduce certification burden on developers as this functionality had been widely adopted across industry.
We request comment from the public about specific issues related to establishing a certification criterion using NCPDP RTPB standard version 12 and other potential actions that could support complementary and interoperable workflows. Given the statutory definition in PHSA § 3000(13) of “qualified electronic health record” as an electronic record of health-related information on an individual that includes, or is capable of including, RTBT functionality, we seek to understand whether ONC should offer or require certification of other capabilities to optimize the value of real-time prescription benefit capabilities to clinicians and patients.
First, we present in section III.G.2.c (below) a series of scenarios and specific questions regarding the real-time prescription benefit criterion we intend to establish through future rulemaking. Areas for input include: the specific transactions that should be included in the criterion; amendments to conformance requirements related to the NCPDP RTPB standard version 12 that we believe may help to improve interoperability; and whether to propose a certification criterion, or propose revisions to an existing criterion, that would require for certification certain segments and vocabularies that are optional or situational within the NCPDP RTPB standard.
We then turn in section III.G.2.d (below) to the broader electronic prescribing ecosystem for pharmacy interoperability. Specific areas for input include: whether ONC should adopt additional standards and certification criteria that support real world electronic prescribing workflows; whether ONC should explore developing certification criteria bundles that mimic real world workflows; and how ONC should approach structuring certification criteria for Health IT Modules that must interact as part of these workflows.
Reviewers who may be interested in commenting on this RFI are encouraged while reviewing it to consider identified data, standards and specifications, and technical capabilities from an ecosystem perspective. Commenters are also encouraged to consider interoperability between certified Health IT Modules and other relevant systems, including third-party applications, electronic prescribing networks and intermediaries, drug knowledge databases and content provider systems, pharmacy information systems, prescription benefit manager systems, and payer systems. Further, we are interested in commenters' views on how developers of certified health IT may be able to support drug price transparency, patient choice, and meet other market demands while ensuring reliable and trusted performance.
ONC is currently considering certification testing scenarios that would assess the capacity of the Health IT Module under test to: capture data specified in the NCPDP RTPB standard version 12; format a RTPB Request transaction; and deliver a RTPB Request transaction to a processor, prescription benefit manager, or adjudicator either directly or via an intermediary or switch. As part of these potential testing scenarios, Health IT Modules would also need to demonstrate the capacity to: receive a RTPB Response transaction; display RTPB Response information for the health care provider to review within their electronic prescribing workflow; and (potentially) to display RTPB Response information for a patient.
Specifically, we are considering a set of scenarios in which the Health IT Module under test would need to demonstrate capacity:
• That allows end users to choose a specific patient, product, and pharmacy, then successfully transmit a request for patient and product specific benefit information directly to a Pharmacy Benefit Manager (PBM), or optionally to a PBM through an intermediary;
• To receive a response correctly displaying price and coverage details of the submitted and covered products, including alternative pharmacies or medications;
• To receive a response correctly displaying that a component of the request (
• To receive a response correctly displaying a message indicating “Patient not found” or “Patient not eligible;”
• To receive a response correctly displaying the identified product is considered a benefit exclusion;
• To receive a response correctly displaying the identified product is not on the patient's formulary;
• To receive a response correctly displaying Step Therapy is required;
• To receive a response correctly displaying a Drug Utilization Evaluation (DUE) Alert;
• To receive a response correctly displaying Out-of-Network pharmacy;
• To receive a response correctly displaying Out-of-Network provider;
• To receive a response correctly displaying the submitted provider is not an allowed provider;
• To receive a response correctly displaying Prior Authorization is required;
• To receive a response correctly displaying not an allowed pharmacy (a pharmacy, mail order pharmacy, specialty pharmacy, or other restricted pharmacy where the product may not be covered); and
• To receive status and error messages such as “Transmission accepted and transaction processed,” “Transmission accepted and transaction not processed,” and “Transmission rejected, and transaction not processed” for different scenarios.
ONC requests comment on whether inclusion of these testing scenarios under a real-time prescription benefit certification criterion would effectively test a certified Health IT Module's capacity to successfully send and receive RTPB transactions in accordance with the NCPDP RTPB standard version 12, specifically:
• Is the set of testing scenarios described above appropriate for a real-time prescription benefit certification criterion?
• Should ONC consider other testing scenarios as part of a real-time prescription benefit certification criterion?
• Are there other testing considerations ONC should take into account in structuring a real-time prescription benefit certification criterion?
ONC is also considering ways to support the standardized capture and exchange of negotiated price, as required in Section 119 of the CAA. Section 119(a)(2) of the CAA specifies “[c]ost-sharing information and the negotiated price for such drug and such alternatives at multiple pharmacy options, including the individual's preferred pharmacy and, as applicable, other retail pharmacies and a mail order pharmacy,” as information that technology meeting the definition of “qualified electronic health record” in PHSA § 3000(13)(C), as added by section 119(b)(3) of the CAA, must be capable of incorporating. In the 2019 “Modernizing Part D and Medicare Advantage to Lower Drug Prices and Reduce Out-of-Pocket Expenses” proposed rule, CMS encouraged, but did not propose to require, plans to use RTBTs to promote full drug cost transparency by showing each drug's negotiated price in addition to the beneficiary's out-of-pocket cost (83 FR 62166). CMS has also encouraged plans to provide additional cost data comparing the beneficiary and plan cost comparisons for each drug and its alternatives.
The NCPDP RTPB standard version 12 does not include fields to support the exchange of negotiated price. We understand that this information was not included because of concerns regarding the confidentiality of drug pricing agreements as well as the inherent challenges in determining the negotiated price in real time—for example, rebates calculated later, the definition of negotiated price under revision, and exclusion of Usual and Customary price information. We seek comment on the value of negotiated price to patients and prescribers to aid in their discussions and decision-making during prescribing. Patient cost-sharing responsibilities are often driven by their plan design, deductible, copay requirements, and other related factors, thus it is unclear whether including such information will improve the utility or usability of technology certified to a real-time prescription benefit certification criterion.
The NCPDP RTPB standard version 12 supports the exchange of RTPB transactions in both extensible markup language (XML) and electronic data interchange (EDI) formats. We understand that the pharmacy industry is currently moving away from EDI for reasons that include its lack of flexibility and human readability as well as EDI's higher overall development and maintenance costs. XML defines a set of rules for encoding documents in a format that is both human and machine readable and allows developers to create and manage their own XML files, but this high level of customizability may pose challenges during exchange. The NCPDP RTPB standard version 12 Implementation Guide contains guidance intended to assist alignment across exchange partners. XML also facilitates compliance with the FDA's requirements for prescription drug labeling submissions,
The NCPDP SCRIPT standard version 10.6 adopted in § 170.205(b)(2) and referenced by the electronic prescribing criterion in § 170.315(b)(3)(i) supports both EDI and XML format. However, the ONC Cures Act Final Rule adopted the NCPDP SCRIPT standard version 2017071 in § 170.205(b)(1) and finalized an updated version of the “Electronic prescribing” criterion in § 170.315(b)(3)(ii) to reference this standard, which only supports the use of XML (85 FR 25678). Certification to the § 170.205(b)(2) criterion has not been available since June 30, 2020. The real world testing provisions in § 170.405(b)(5) required developers with health IT certified to § 170.315(b)(3) prior to June 30, 2020, to update the technology to provide customers of that health IT to be compliant with § 170.315(b)(3)(ii) and provide the updated technology to their customers by December 31, 2022. However, a variety of health IT products that support the older NCPDP SCRIPT standard version 10.6 may remain in use—including by entities who do not use certified health IT and do not need to meet Medicare Part D requirements for electronic prescribing transactions.
We are concerned that legacy or other health IT may not be prepared to adopt XML at this time and that there may be challenges exchanging data between systems conformant only with EDI and those conformant only with XML. We are seeking comment on whether the real-time prescription benefit certification criterion under consideration should only require and test XML format or both XML and EDI formats.
The NCPDP RTPB standard version 12 supports the exchange of RTPB transactions containing both NDC and RxNorm code sets. National Drug Codes (NDC) provide a unique identifier for products such as vaccines or medications. Each product is assigned a unique 10- or 11-digit, 3-segment number that identifies the labeler, product, and trade package size. RxNorm is a drug terminology providing a set of normalized medication names
The NCPDP RTPB standard version 12 supports the exchange of representative NDCs in transactions originating from prescribing providers, which may be any NDC belonging to the same product concept that is nationally available, not repackaged, not obsolete, not private label, and not unit dose (unless it is the only NDC available). A product concept describes a medication or non-medication product that has the same active ingredient, strength, route, dosage form, drug delivery system or packaging, or therapeutic use/indication. Product concepts also have brand and generic distinctions. The Centers for Disease Control (CDC) has also developed NDC and CVX crosswalk resources to facilitate the use of NDCs for vaccines.
RxNorm (currently adopted in § 170.207(d)(3) and proposed in § 170.207(d)(1), see section III.C.3 of this preamble) is required in the electronic prescribing certification criterion in § 170.315(b)(3)(ii)(A) and (B) as a minimum standard code set for a drug. Where no RxNorm code exists, nothing prohibits another allowable code from being used; however, where corresponding RxNorm codes exist, certified health IT must be able to use those codes. Under the NCPDP RTPB standard version 12, NDC is required and RxNorm is situational, where RxNorm is required only when populated in the RTPB Product Segment. The Product Segment is mandatory for an RTPB request. We are concerned that “situational” may be viewed as optional by health IT developers seeking certification, leading to a lack of coded values. Missing codes may limit the utility of this data for clinical decision support and pharmacy interoperability and have negative downstream effects on claims and billing.
ONC has received comments and feedback from the HITAC and other industry participants stressing the need to reconcile the use of NDC and RxNorm codes, and to support accurate NDC-RxNorm mapping.
We believe that requiring RxNorm in addition to NDC for a real-time prescription benefit criterion could facilitate the adoption, maintenance, and harmonization between NDC and RxNorm. However, we understand that adoption alone will not support concept and code mapping between NDC and RxNorm. We are requesting comment on whether a potential real-time prescription benefit certification criterion should require demonstration of compliance with both NDC and RxNorm, specifically:
• Would requiring demonstration of compliance with both NDC and RxNorm in a real-time prescription benefit criterion support improved adoption, maintenance, and harmonization between code sets?
• How would requiring Health IT Modules to demonstrate compliance to both code sets for certification to a real-time prescription benefit criterion affect implementation of this capability? What benefits would this have for health care providers and other participants that support real-time prescription benefit transactions?
• What burden would demonstration of compliance with both code sets impose on developers of seeking or maintaining certification of Health IT Modules to this criterion?
• Would either NDC or RxNorm alone provide sufficient information for applications to provide reliable, accurate clinical decision support, such as dosing guidance, drug-drug interaction or drug allergy checks?
• What would be the consequences (positive or negative, intended or unintended) of establishing “RxNorm as the single source of clinical data for clinical care, research and administrative workflows, replacing NDC for such purposes,” as recommended by the HITAC?
The Clinical Segment in the NCPDP RTPB standard version 12 is used to specify diagnosis information associated with the prescription. Under this version of the standard, the segment is situational, meaning if it is used, it should be included in a RTPB Request transaction. It is required when needed for coverage determinations and assists with claims submissions and processing. However, if the Clinical Segment is not sent, diagnosis codes may not be transmitted to PBMs, which provide oversight for (and are sometimes delegated the responsibility of) coverage determinations and redeterminations. Given the importance of this information, ONC is strongly considering specifying mandatory use of the Clinical Segment (rather than situational use) in RTPB Request transactions as part of a future proposal for a real-time prescribing benefit certification criterion.
The Clinical Segment specified in the NCPDP RTPB standard version 12 supports a DiagnosisCodeQualifierCode element that qualifies the external code list used for medication-associated diagnosis, supporting both the International Statistical Classification of Diseases and Related Health Problems (ICD) and SNOMED CT. SNOMED CT is a clinical healthcare terminology and infrastructure that provides a common language that enables a consistent way of capturing, sharing and aggregating health data across specialties and sites of care. SNOMED CT can serve as a common language between ICD-10-CM and ICD-11 and may help developers and providers during the transition between ICD versions should ICD-11 be adopted.
ONC seeks comments that may help inform our consideration of whether to require the Clinical Segment in the NCPDP RTPB standard version 12 as part of any future real-time prescription benefit certification criterion, and whether to require that Health IT Modules under pre-certification testing, real world testing after certification, and (as applicable) ONC-ACBs' in-the-field surveillance for such criterion
• Would a requirement to demonstrate use of both ICD-10-CM and SNOMED CT within the Clinical Segment as part of an RTPB certification criterion support a more seamless transition between ICD-10-CM and ICD-11, in the event ICD-11 is adopted? Are there other benefits to requiring certified Health IT Modules demonstrate compliance with both terminologies?
• What additional burden would demonstration of compliance with both ICD-10-CM and SNOMED CT impose on health IT developers seeking or maintaining certification of Health IT Modules to a real-time prescription benefit criterion?
One of the most challenging areas of real-time prescription benefit functionality is the need to match patient records to their medical and pharmacy benefit records in order to facilitate the exchange of patient specific benefit information between pharmacies, EHRs, and PBMs/adjudicators. We are currently considering requiring real-time prescription benefit implementation within the electronic prescribing workflow and requiring health IT certified for electronic prescribing capabilities be capable of ingestion and integration of this information. In addition, we expect health care providers will typically send a NewRx soon after receiving an RTPB Response transaction. In order to better support these transactions and support improved patient matching we are considering a more comprehensive Patient Segment than that which is required in the NCPDP RTPB standard version 12.
After reviewing and comparing Patient Segments across NCPDP SCRIPT standard version 2022011, NCPDP RTPB standard version 12, and the NCPDP Formulary and Benefit standard version 54, we are considering requiring support for the patient identity segment as outlined in NCPDP SCRIPT standard version 2022011 as part of a real-time prescription benefit certification criterion. We acknowledge that both NCPDP SCRIPT standard version 2022011 and NCPDP RTPB standard version 12 support the exchange of unique, but not universal, identifiers produced by vendors, but because not all providers have access to these services, and patients lack access to these types of unique identifiers, demographics-based patient matching must also be enabled to support most health care providers and patients across the country.
We are requesting comment on whether a real-time prescription benefit certification criterion should require conformance to the Patient Segment specified in NCPDP SCRIPT standard version 2022011 (replacing the NCPDP RTPB standard version 12 Patient (Demographic) Segment) to support the identification and linkage of records needed to support the successful exchange of patient-specific benefit information, specifically:
• Would requiring the Patient Segment identified in NCPDP SCRIPT standard version 2022011 as part of a real-time prescription benefit certification criterion support improved patient matching?
• What additional burden would requiring the Patient Segment identified in NCPDP SCRIPT standard version 2022011 as part of a real-time prescription benefit certification criterion impose on health IT developers seeking to certify Health IT Modules to this criterion?
• Should ONC consider requiring alternative or additional demographic data elements or sets of demographic data elements as part of a real-time prescription benefit certification criterion to further improve patient matching? For instance, should ONC consider requiring the Patient Demographics/Information data class identified in USCDI Version 3? What additional benefit would this offer to health IT developers, health care providers, patients, and the healthcare industry in general? What additional burden would these or other alternatives impose on health IT developers?
As added by Section 119 of the CAA, section 3000(13)(C) of the PHSA specifies that a qualified electronic health record: “includes, or is capable of including, a real-time benefit tool that conveys patient-specific real-time cost and coverage information with respect to prescription drugs that, with respect to any health information technology certified for electronic prescribing, the technology shall be capable of incorporating the information described in clauses (i) through (iii) of paragraph (2)(B) of section 1860D-4(o) of the Social Security Act.” We believe that PHSA § 3000(13)(C) as a whole requires that a real-time prescription benefit certification criterion must require a Health IT Module certified to the criterion to demonstrate capabilities both to convey real-time prescription benefit information and ingest and integrate real-time prescription benefit information for use by other health IT services, components, or combinations thereof that are part of the electronic prescribing workflow. While we expect some health IT developers may plan to develop real-time prescription benefit functionality as part of a suite of electronic prescribing capabilities contained within one health IT product, we also expect that some health IT developers who participate in the ONC Health IT Certification Program may prefer to obtain certification to a criterion that allows them to leverage a third-party real-time prescription benefit tool. Under such a certification approach, we would seek to ensure through requirements and testing for conformance to those requirements that integration between systems is conducted effectively.
Workflow integration refers to the capacity of health IT to launch and perform all functions within the electronic prescribing workflow without the need for the user to sign into a separate web-based platform or otherwise leave the electronic health record system, or prescribing application, user interface to send and receive RTPB transactions. Data integration refers to the capacity of a receiving system to receive, ingest, and reuse all data elements received in accordance with the standards and other requirements as stated in a certification criterion. For instance, for electronic prescribing, data integration is necessary for health IT to conduct drug interaction checks and alerts. In real-time prescription benefit processes, data integration embeds patient-specific benefit, estimated cost information, and viable alternatives into the electronic prescribing workflow at the point of care.
We believe that a real-time prescription benefit certification criterion should address concepts of both workflow and data integration in order to facilitate, where lawful and appropriate, the free flow of and reuse of EHI and other prescription benefits data across the healthcare landscape and reduce burden and high potential for error associated with manual data entry, translation across disparate formats and standards, and other
• How can ONC most effectively address the definition of “qualified electronic health record” in PHSA § 3000(13)(C) as added by the CAA to achieve the benefits of workflow and data integration while minimizing potential burden on health IT developers seeking to certify health IT to the real-time prescription benefit tool criterion?
• Should ONC consider alternative paths to certification to a real-time prescription benefit criterion based on whether a Health IT Module relies on a third-party application or other intermediary to successfully demonstrate full integration and capacity to reuse the data that received from other systems involved in real-time prescription benefit information exchange?
• How should ONC address alignment of a real-time prescription benefit criterion to the electronic prescribing criterion in § 170.315(b)(3)?
Medications are likely to be the primary product type chosen by health care providers when initiating real-time prescription benefit processes at this time. However, the COVID-19 pandemic highlighted the need to ensure vaccine availability in various care settings including pharmacies, as well as needs to collect, aggregate, and report information to immunization registries and submit reimbursement claims for administering vaccines to patients. Requiring health IT certified to a real-time prescription benefit criterion to support RTPB transactions that include vaccines could lead to higher levels of benefit coverage for vaccines obtained from contracted pharmacies, improved eligibility checks, and lower out of pocket costs for routine preventive care that is covered by most plans. In addition, technology certified to a real-time prescription benefit criterion could also support RTPB transactions for medical devices or supplies and exchange this data using device identifiers supported by the NCPDP Formulary and Benefit standard.
The NCPDP RTPB standard version 12 will continue to mature and evolve over time in response to new or unidentified challenges and as needs emerge. We believe that one area of the standard in need of advancement and alignment is how the standard supports the exchange of unique identifiers for devices. The FDA has discontinued use of legacy FDA identification numbers assigned to devices (21 CFR 801.57) where National Health-Related Item Codes (NHRIC) or NDCs assigned to devices are rescinded, and manufacturers may no longer provide an NHRIC or NDC on the label of their devices or on any device package. The FDA has since released guidance
We are requesting comments on whether a real-time prescription benefit criterion should also require demonstration of support for products that are not defined as medications but may also be included in a RTPB transaction, namely vaccines and medical devices or supplies, specifically:
• What benefits would come from supporting the exchange of prescription benefit information for vaccines, medical devices, or supplies?
• What challenges would be involved in supporting the exchange of prescription benefit information for vaccines, medical devices, or supplies?
• What additional burden would exchange of information on vaccines, medical devices, or supplies as part of a certification criterion impose on health IT developers?
• To what extent should ONC require as part of certification to a real-time prescription benefit criterion support for devices or supplies as defined within the NCPDP RTPB standard version 12?
• Alternatively, should ONC require conformance to the NCPDP Formulary and Benefit Standard for devices? The NCPDP Formulary and Benefit Standard supports the exchange of UDIs for devices, and adoption of this standard may support other critical RTPB processes. What are effective ways to support accurate device identification within and beyond the real-time prescription benefit workflow, while aligning with FDA regulations and related requirements?
• What additional opportunities might arise from requiring conformance to the NCPDP Formulary and Benefit Standard?
We seek information on formulary and benefit management and electronic prior authorization capabilities that work in tandem with real-time prescription benefit functionality in the context of electronic prescribing workflows.
When used appropriately, formularies can help manage drug costs without negatively impacting patient health. For example, tiered formularies allow providers and patients to choose lower cost medications for the same clinical indication. With more accurate and timely formulary and benefits data, providers can demonstrate better management of care for their high-risk patients, reducing time-to-therapy with less administrative overhead. Providers who have access to a formulary can use this information to determine appropriate medications consistent with a patient's pharmacy benefit prior to submitting a benefit check.
ONC previously finalized a “drug-formulary and preferred drug list checks” certification criterion for the 2015 Edition of health IT certification criterion in § 170.315(a)(10); however, ONC did not adopt the NCPDP Formulary and Benefit standard to support this criterion. In the 2015 Edition Proposed Rule, ONC proposed to require a Health IT Module to receive and incorporate a formulary and benefit file using the NCPDP Formulary and Benefit standard version 3.0
The ONC Cures Act Final Rule removed the “drug-formulary and preferred drug list checks” criterion from the Program as of January 1, 2022 (85 FR 25660). We stated that we were retiring the criterion because it was a
We note that formulary validation is now ubiquitous across the healthcare industry, using distributed formulary and benefit files. Multiple parties are involved in creating, processing, and disseminating these files, and any variation in timing, scope, processing burden, and accessibility introduces additional complexity and delays. Because each health IT developer follows different schedules, for example, information may be out-of-date by the time the health care provider views it in the electronic health record or electronic prescribing application. In addition, the increasing size of these formulary files have led to an increase in the time and resources it takes for a health IT developer to process this data to be available for health care providers when they need it. All these factors may call into question the timeliness and accuracy of the formulary data available to health care providers at any given time, and any discrepancy between the medication prescribed and its formulary data may impede the success of real-time prescription benefit processes, and slow claims and billing workflows. Simply checking whether a formulary exists for a given medication is no longer sufficient to support the interoperability of formulary and benefits data, especially as real-time prescription benefit and other capabilities emerge that more heavily rely on the real-time availability of accurate formulary data.
While ONC previously declined to finalize the NCPDP Formulary and Benefit standard version 3.0
Use of technology conformant to the NCPDP Formulary and Benefit standard can support real-time prescription benefit processes by helping clinicians avoid prescriptions that are not covered by a patient's pharmacy benefit or are more expensive than other prescriptions clinically appropriate for the indication. The standard also improves efficiency in several ways, helping providers avoid callbacks and the need for additional clarifications on prescriptions or prior authorizations, reducing provider reliance on fax and prescribing burden overall.
We seek comment on whether we should further explore capabilities for Health IT Modules to support access to formulary and benefits information, specifically:
• Should ONC propose a new certification criterion that would enable a user to use a Health IT Module to obtain formulary and benefits information using a more recent NCPDP Formulary and Benefit standard?
• What current challenges do health care providers face in obtaining formulary and benefit information and would a standards-based criterion help to address these challenges?
• Should ONC consider incorporating functionality using the NCPDP Formulary and Benefit standard within the potential real-time prescription benefit criterion discussed above, rather than creating an independent criterion for formulary and benefits functionality?
• What are the key benefits health care providers would likely experience from availability of functionality within certified health IT utilizing the most recent NCPDP Formulary and Benefit standard? If formulary check capabilities have already been widely adopted, how would certification of these capabilities benefit providers?
After receiving a RTPB Request transaction, a processor, PBM, or adjudicator will determine eligibility for the identified patient and determine if the product requires prior authorization. In the RTPB Response, a health care provider may receive notification that a prior authorization is needed for the prescription. Health care providers may benefit from being able to initiate an electronic prior authorization process within the same workflow. For example, within the same interface, health care providers should be able to quickly switch from real-time prescription benefit functionality to electronic prescribing functionality, and send electronic prior authorization transactions (
As noted above, the ONC Cures Act Final Rule adopted the NCPDP SCRIPT standard version 2017071 and updated the “Electronic prescribing” certification criterion in § 170.315(b)(3)(ii) to reflect this standard, including four transactions for electronic prior authorization specified as optional (85 FR 25678). We stated that we adopted these transactions to support alignment with the “Secure Electronic Prior Authorization for Medicare Part D” proposed rule (84 FR 28450), in which CMS proposed to require Part D plan sponsors to support version 2017071 of the NCPDP SCRIPT standard for four electronic Prior Authorization (ePA) transactions, and that prescribers would be required to use that standard when performing ePA transactions for Part D covered drugs they wish to prescribe to Part D eligible individuals (85 FR 25685). CMS subsequently finalized this policy in the “Secure Electronic Prior Authorization for Medicare Part D” final rule with a compliance date of January 1, 2022 (85 FR 86824).
We invite comments on the potential incorporation of these transactions into the “Electronic prescribing” certification criterion and whether we should consider requiring certification to these transactions in a future rulemaking.
The formulary and benefit maintenance, real-time prescription benefit, electronic prior authorization,
For instance, we are considering approaches in the Program that would allow a Health IT Module (or a health IT product incorporating multiple Health IT Modules to support multiple aspects of electronic prescribing workflow) to undergo testing for more than one pharmacy interoperability criterion during a single, streamlined testing event, while maintaining a modular approach to certification that allows health IT developers to certify to only those criteria relevant to their products. We are seeking public comment on the potential benefits or challenges of such an approach, including:
• If ONC were to propose and finalize additional pharmacy interoperability certification criteria similar to those discussed in this RFI, what would be the challenges of testing each criterion individually?
• Could a bundled approach to testing more than one pharmacy interoperability criterion in a single testing event address these challenges? What other principles or parameters should be applied to such an approach?
• If ONC were to propose an alternate approach to bundled testing for related certification criteria, should such an approach be required for any product a health IT developer seeks to certify to multiple criteria within the bundle, or should it be optional?
• Might there be additional opportunities to reuse testing resources and streamline the testing experience for health IT developers while taking additional steps to ensure that certified health IT is optimized for prescribing safety, efficiency, and usability?
This request for information focuses on the FHIR standard for APIs (including FHIR Subscriptions, CDS Hooks, FHIR standards for scheduling, and SMART Health Links) and aligns with our aims of advancing interoperability through the use of APIs for treatment, payment and operations use cases. We welcome technical and policy comments as we consider the potentially applicability of these standards and specifications for potential future rulemaking.
A FHIR API is a “RESTful”
FHIR Subscriptions
FHIR Subscriptions are enabled by the following resources: Subscription,
Furthermore, we request comment on whether there is a need to define a minimum set of Subscription Topics that can be consistently implemented by all health IT developers of certified health IT to provide a base level expectation for clients using the services. We also invite comments on appropriate industry led activities to maintain and keep the artifacts up to date.
Additionally, we welcome comments on security, channels, payloads, and any other areas that would need to be further specified to achieve our goal of providing subscription capabilities across certified Health IT Modules in a consistent and standardized manner using an already adopted standard.
We are including in this proposed rule a RFI seeking input from the public on whether to require certified health IT systems to adopt the CDS Hooks FHIR Implementation Guide v1.0 as part of the requirements in the Program.
Clinical decision-making is an important part of the foundation of care delivery. Each patient presents a unique combination of facts and circumstances that require ongoing assessment, planning, intervention, and evaluation. Each decision in the course of a patient's care involves gathering, analyzing, and acting on information that may be complex, unclear, or incomplete. Clinical decision makers must account not only for information provided by the patient, but also the continuously evolving and growing body of medical and scientific knowledge.
Health IT has the potential to help address the complexities of clinical decision-making for providers and as part of shared decision-making with patients and care team members. CDS provides clinicians, staff, patients, and other individuals with knowledge and person-specific information, intelligently filtered and/or presented at appropriate times to enhance decision-making. CDS encompasses a variety of tools, including computerized alerts and reminders, clinical guidelines,
CDS is a common capability provided by EHR systems today. Computerized physician order entry (CPOE), for example, is often paired with CDS to help clinicians select the appropriate medications for their patients and provide alerts if a patient is allergic to a particular medication.
Although there have been numerous studies demonstrating the value and efficacy of CDS, available evidence suggests the CDS must be carefully implemented and managed to achieve its potential.
Standards development organizations like HL7 provide standards that aim to address some of the CDS interoperability challenges. The FHIR CDS Hooks specification, for example, describes the RESTful APIs and interactions using JSON over HTTPS to integrate CDS between CDS Clients (
Given the growing use of CDS and potential for CDS to improve clinical decision-making, we request comment on the scope and maturity of the FHIR CDS Hooks specification v1.0, which we are considering for future inclusion as part of the Program. Recognizing that CDS Hooks does not prescribe a default or required set of hooks for implementers, we further request comment on specific hooks that we might include in future certification criteria (the CDS Hooks specification, for example, defines a small set of hooks), as well as input on use of CDS Hooks for supporting workflow improvement and reducing health care provider burden. To the extent commenters have specific CDS Hook use cases for supporting the latter, we welcome input on this including comment on the readiness and feasibility of such use cases including, as an example, for the screening and assessing of social risk and health related social needs or history.
Based on public engagement and published analysis,
During the launch of COVID-19 vaccination in U.S., many individuals experienced difficulties in obtaining timely vaccination appointments, including signing up for waitlists at multiple clinics, constantly refreshing different websites that advertised vaccine availability, and repeatedly calling busy phone lines.
Once these issues within vaccine appointment scheduling became known, the health IT industry came together to address the situation in a rapid manner. One such industry-led solution that was developed during the time, and has since gained widespread support, is SMART Scheduling Links.
In this RFI, we seek input on the maturity and scope of the SMART Scheduling Links Implementation Guide that is aligned with FHIR Release 4, to be considered for future certification as part of the Program.
Furthermore, we request comment on the guidance specified in the SMART Scheduling Links Implementation Guide for publishers to advertise the API endpoints and whether there are other approaches that ONC could take to ensure that the APIs are easily discoverable by users of the API.
We also invite comments on any other appropriate industry led activities that we should consider for potential models and approaches, such as the Argonaut Scheduling Implementation Guide.
The SMART Health Cards
While the COVID-19 pandemic certainly played a major role in rapid response by industry, we have heard from industry that some of the key reasons for the implementation success of SMART Health Cards included the focus on a limited data set, which could be provided by health care providers in a verifiable and secure manner using existing FHIR API technologies available in their health IT, and packaged using QR
ONC is generally supportive of such innovative efforts to advance API capabilities for targeted needs. We have been tracking industry advances in not only the SMART Health Cards standard, but also a more recent effort, called SMART Health Links Protocol.
Our understanding is that, conceptually, the SMART Health Links Protocol
In this RFI, we seek input on the value and feasibility of the SMART Health Links Protocol, as well as concerns regarding its implementation. Furthermore, we invite comment from the public on approaches ONC could take, within our authorities, to encourage rapid advancement of the technology.
We also request information on any other promising industry-led innovative activities that we should consider that are aligned with the FHIR standard, and which would help us advance towards achieving our goal of improving interoperability using health information technology.
Specifically, we explained that “an individual or entity that offers certified health IT” would include “any individual or entity that under any arrangement makes certified health IT available for purchase or license” (85 FR 25798). Both individuals or entities that otherwise fall into at least one category of actor as defined in 45 CFR 171.102—such as health care providers—and individuals or entities who otherwise would not fit the definition of any category of actor could offer certified health IT that they did not themselves develop or present for certification. As offerors of certified health IT, these individuals or entities could engage in conduct that constitutes information blocking as defined in § 171.103, such as through contractual terms or practices undertaken in operating and maintaining health IT used by another individual or entity.
In the ONC Cures Act Final Rule (85 FR 25642), we noted that PHSA section 3022(b)(1)(A) expressly references both “a health information technology developer of certified health information technology” and “other entity offering certified health information technology” in the context of authority to investigate claims of information blocking (85 FR 25798). We further explained that including both developers and other offerors in the definition of “health IT developer of certified health IT” is consistent with the policy goal of holding all entities who could, as a developer or offeror, engage in information blocking accountable for their practices that are within the definition of information blocking in § 171.103 (85 FR 25799).
We received comments on the ONC Cures Act Proposed Rule (84 FR 7424) expressing concern about holding offerors who do not themselves develop the health IT accountable for design features or other things done by the developer of the health IT. We did not receive public comments on the ONC Cures Act Proposed Rule (84 FR 7424) questioning or expressing concerns specifically about our interpretation that “individual or entity that offers certified health IT” would include an individual or entity that
Following the publication of the ONC Cures Act Final Rule, public feedback has been received through our Health IT Feedback and Inquiry Portal and through real-time interactions with interested parties in various venues on many points of information blocking policy. Specific to the definition of
Although health care providers are already information blocking actors, those who might be in a position to offer cost subsidies to other providers may be hesitant to do so because of the differences in the information blocking definition and consequences for a
We have also received, through public interaction in various venues, several requests that we clarify, in a manner providing certainty, that a provider using certified health IT acquired from a developer or other offeror will not come to be considered a
To give clarity about the definitional implications under information blocking regulations of making available funding subsidies and certain features or uses of certified health IT, we now propose to codify a definition of what it means to
(1) to encourage beneficial arrangements under which providers in need can receive subsidies for the cost of obtaining, maintaining, or upgrading certified health IT; or
(2) to give health care providers (and others) who use certified health IT concrete certainty that implementing certain health IT features and functionalities, as well as engaging in certain practices that are common and beneficial in an EHR-enabled healthcare environment, will
We further propose potential exclusions we are considering that would provide that an individual or entity is not considered to be
As finalized in the ONC Cures Act Final Rule and consistent with the Cures Act's information blocking provision (42 U.S.C. 300jj-52), an individual or entity that
As stated in the ONC Cures Act Proposed (84 FR 7511) and Final (85 FR 25798) Rules, under current information blocking regulations (45 CFR part 171) “an `individual or entity that offers certified health IT' would include an individual or entity that under any arrangement makes certified health IT available for purchase or license.”
We have believed since long before we issued the ONC Cures Act Proposed Rule, and we continue to believe today, that arrangements that help small or safety net providers afford certified health IT items and services are generally beneficial to the recipient providers and their patients. We further believe policy goals for interoperability, information sharing, and equity throughout the U.S. healthcare system are supported by encouraging the provision of grants or funding subsidies, consistent with other applicable laws, to health care providers who may otherwise struggle to afford modern, interoperable health IT.
Now that we have been made aware of concerns regarding the potential inclination of some health care providers and other donors to stop making available funding subsidies toward the cost of certified health IT for providers who may not otherwise be able to afford it, we believe it is appropriate to consider ways to modify our policy. Specifically, in the proposed definition of what it means to offer health IT in § 171.102, we propose to explicitly exclude certain beneficial arrangements providing funding subsidies for providers to obtain, maintain, and/or upgrade certified health IT.
Exclusion (1) would remove from the definition of
We note that we do not believe it is necessary to assess, for purposes of determining whether a funding subsidy should be considered an offer of certified health IT, whether the source(s) of the subsidy conditions the subsidy on a recipient health care provider referring patients to or away from the source. Other law—not limited to but notably including 42 U.S.C. 1320a-7b(b) where payment for any item, service, or good may be made in whole or part under a “Federal health care program” (as defined in 42 U.S.C. 1320a-7b(f))—is implicated by solicitation or receipt of any remuneration in return for referral steering and similar conduct. The proposed tailoring of the funding subsidies exclusions from the
If an individual or entity engages in conduct that meets the
Similarly, an individual or entity that otherwise meets the definition of an information blocking
In the ONC Cures Act Final Rule preamble, we noted that there are certain actions taken by health care providers who self-develop health IT for their own use that we do not interpret as them offering or supplying certified health IT to others. Specifically, we noted that “some use of a self-developer's health IT may be made accessible to individuals or entities other than the self-developer and its employees without that availability being interpreted as offering or supplying the health IT to other entities in a manner inconsistent with the concept of `self-developer,' ” and we provided examples of activities that we do not consider offers (85 FR 25799). Some of the examples we noted were discussed in context of customary practices amongst hospitals that purchase commercially marketed health IT as well as self-developer hospitals.
We do not, and do not believe anyone else should, consider the examples discussed at 85 FR 25799 to be offerings of health IT in any sense relevant to the
• Issuing login credentials to employees (whether “W2”/traditional or “1099”/contracted or “gig” employee) of the individual or organization for purposes of accessing, using, or exchanging EHI within the scope/duties of their employment or contract. This would include, though it is not limited to, in-house counsel while acting within scope of their engagement as in-house counsel.
• Production instances of API technology supporting patient (also known as “individual”) access or other legally permissible access, exchange, or use of EHI that the individual or entity has in its possession, custody, control, or ability to query from/across a HIN/HIE.
• Production instances of online portals for patients, clinicians, or other health care providers (including employed, affiliated, non-affiliated, or independent providers), or public health entities to access, exchange, or use EHI that the that the individual or entity has in its possession, custody, control, or ability to query from/across a HIN/HIE.
• Issuing login credentials or user accounts to production or development/testing environments to public health authorities or such authorities' employees as a means of accomplishing or facilitating access, exchange, and use of EHI for public health purposes including but not limited to syndromic surveillance.
We also propose to explicitly exclude from the
We reference production instances in proposed paragraph (2) but do not propose to establish a formal definition of “production instance” specific to this purpose. We do not believe that is necessary because we observe health IT developers, resellers, and customer organizations communities generally using and understanding a production instance as a particular implementation of a given health IT product that has “gone live” in a production environment. Production environments, in turn, we observe are generally understood as being the setting where health IT is implemented, run, and relied on by end users in day-to-day conduct of their profession (such as medicine, nursing, or pharmacy) or other business (such as a payer processing healthcare reimbursement claims or a patient managing their health and care). Many health care provider organizations, such as small clinician office practices, may only obtain use of a production instance of whatever health IT they use (such as a patient portal). However, other health care provider organizations' enterprise IT setups do include test, staging, or other pre-production environments where new or updated software or other health IT can be configured and confirmed to operate well in the overall environment before it “goes live” to end users in the production environment.
The reference to production instances in the proposed paragraph (2) explicitly does
In defining what it means to
The bundled exclusions we propose in paragraph (3) of the definition would address specific legal and consulting services related to obtaining and maintaining health IT or involving health IT in certain ways. The services addressed by the subparagraphs of the paragraph (3) “consulting and legal services” exclusion would include:
• legal services furnished by attorneys that are not in-house counsel
• health IT expert consultants' services engaged to help a health IT customer/user (such as a health care provider) define their business needs and/or evaluate, select, negotiate for or oversee configuration, implementation, and/or operation of a health IT product that the consultant does not sell/resell, license/relicense, or otherwise supply to the customer; and
• clinician practice or other health care provider administrative or operational management consultant services where the clinician practice or other health care provider administrative or operational management consulting firm effectively stands in the shoes of the provider in dealings with the health IT developer or commercial vendor and manages the day-to-day operations and administrative duties for health IT and its use alongside other administrative and operational functions that would otherwise fall on the clinician practice or other health care provider's partners, owner(s), or staff.
Questions have arisen for us regarding if or when a health care provider's outside counsel risks becoming an individual or entity that offers certified health IT by virtue of various representational activities. At (3)(a) in the proposed
To be clear, no one has yet brought to our attention a fact pattern in which a law firm's provision of advice, counsel, or other legal services supporting the negotiation, drafting, or execution of agreements by which the provider obtains use of health IT crosses into the realm of activities we would interpret as equivalent to the law firm itself offering the health IT. We have yet to hear a single report of a health care provider or other prospective health IT customer being unable to obtain assistance of competent counsel for their dealings with health IT developers and vendors due to law firms being concerned by any aspect of the
However, as we are proposing the exclusion from the
This proposed exclusion would: codify how we already view, in the context of the definitions currently codified in § 171.102, legal services furnished by outside counsel in certain matters; and remove an ambiguity that could, at least in theory, otherwise have unintended effects on how parties may in the future assess the best available options and mechanisms for efficient, cooperative discovery. The proposed exclusion for legal services furnished by outside counsel, like the proposed exclusion of health IT expert consulting services, would focus on the services provided and
•
•
We focus this proposed exclusion from the
We solicit comment on this proposal.
At (3)(b) in the proposed
We solicit comment on this proposal.
At (3)(c) in the proposed
Alone among the three proposed exclusions of consulting and legal services arrangements, the exclusion of clinician practice or other health care provider administrative or operational management consulting services would be likely to include, on a regular basis, arrangements where the health IT the health care provider uses is directly provided to them by the consultant—for example, as part of a comprehensive (“turn key”) package of practice management or other provider administrative or operations management services. In proposing this specific exclusion ((3)(c)), we call potential commenters' attention first and foremost to its implication for health care providers' accountability for acts or omissions of their consultants operating under the exception—particularly health care providers' administrative or operational management services consultants—that implicate the definition of information blocking in § 171.103: where a an administrative or operations management services firm would not be considered to be making an offer of certified health IT for which they contract on behalf of one or more practices (or facilities or sites of care)
If practice management consultants become unwilling to include amongst their services those whereby they stand in the shoes of the provider to deal with health IT developers and other health IT offerors, the burden would shift to the provider's staff. Healthcare professionals in small office practices, safety-net clinics, or other lower-resource situations may be unable to afford to keep on staff persons with the necessary skills to ensure their operational items and services are managed effectively. Thus, if dealings with health IT developers were no longer available as part of practice management consulting services packages due to the consultants' concern over being considered “health IT developers of certified health IT,” the provider's dealings with IT developers and other health IT offerors would in a variety of small and low-resource provider circumstances tend to shift to the licensed healthcare professional(s). It is not our intent that information blocking regulations increase the need for clinicians and other licensed healthcare professionals in small practices, safety net clinics, or low-resource settings of any type, to directly negotiate with health IT developers or other purveyors of health IT items and services if or when such licensed healthcare professionals would prefer to engage a practice management firm to deal with health IT vendors along with vendors of all the other goods and services needed to operate an office practice, clinic, or other type of health care provider. Furthermore, we believe tailoring this exclusion to health IT items and services bundled with other items and services mitigates what could otherwise be a risk of non-developer purveyors of health IT items and services attempting simple, pretextual rebranding of their offerings of health IT items and services with the aim of evading accountability while engaging in conduct constituting information blocking as defined in § 171.103.
The key factors that would differentiate excluded clinician practice or other health care provider administrative or operational management consultant services from IT managed service provider (MSP) services and arrangements, as the proposed exclusion is drafted (see (3)(c)), would be:
• The individual or entity furnishing the administrative or operational management consulting services acts as the agent of the provider or otherwise stands in the shoes of the provider in dealings with the health IT developer(s) or commercial vendor(s) from which the health IT the client health care providers ultimately use is obtained.
• The administrative or operational management consulting services must be a package or bundle of services provided by the same individual or entity and under the same contract or other binding instrument, and the package or bundle of services must include a comprehensive array of business administration functions, operations management functions, or a combination of these functions, that would otherwise fall on the clinician practice's or other health care provider's partners, owner(s), or in-house staff.
To be considered “[c]omprehensive and predominantly non-health IT” services, the array of operations and functions the consultant administers
• the person hours per year the consultant bills or otherwise applies to the services bundle (including cost allocations consistent with Generally Accepted Accounting Principles), and
• the total cost to the client for, or billing from, the consultant per year (including pass-through costs for the health IT items and services).
Non-health IT services we have observed practice/operations management consultants offering to administer on behalf of health care providers include credentialing or contracting, medical supplies & equipment purchasing and leasing, staffing (also called human resources) management, and location or facility services. An arrangement where the health IT items and services that are passed through the consultant to the end-user health care provider
Similar to the other two potential exclusions proposed for legal and consulting services, this exclusion focuses on specific services that would be construed as outside the proposed definition of what it means to
Thus, for one example, an individual or entity that enables client individuals or entities to obtain use of health IT exclusively through arrangements fitting this exclusion would avoid being considered a
We solicit comment on this proposal, specifically including comment on whether:
• this exclusion is more beneficial than harmful or confusing to the public, including the regulated community (health care providers, other information blocking “actors,” and those who may be more likely to be considered a “health IT developer of certified health IT” in the absence of this exclusion); and
• different or additional criteria should factor into differentiating whether a particular arrangement is a practice/operational management services arrangement that happens to include health IT as one of many necessities to operate as a health care provider rather than an arrangement for supply of health IT that happens to include additional services.
Currently, for reasons discussed in the ONC Cures Act Proposed (84 FR 7511 to 7512) and Final (85 FR 25799 to 25800) Rules, health care providers who self-develop certified health IT
In our experience, self-developers continue to comprise a very tiny segment of the health IT developer of certified health IT population. However, we do not have optimal visibility of the extent to which self-developer health care providers may be providing their self-developed certified health IT to other health care providers—particularly those who, like skilled nursing facilities and other long term/post-acute care (LTPAC) providers, are not eligible to participate in any CMS programs that specifically track use of Certified EHR Technology (CEHRT)—on any terms.
To date, we have received no questions, concerns, or other feedback specific to treating, for purposes of information blocking, self-developer health care providers who offer or supply to others their self-developed certified health IT the same as we would any developer of certified health IT.
However, we believe it is appropriate to revisit the
Should we finalize the
To ensure it is immediately clear from the face of the regulations' text that we had put all health care providers that engage in other activities consistent with exclusions (1) through (3) from the
We note that regardless of whether we finalize this proposed change to the
As finalized in the ONC Cures Act Final Rule (85 FR 25642) and the Cures Act Interim Final Rule (85 FR 70085), the definition of information blocking (§ 171.103) and the Content and Manner Exception (§ 171.301(a)) were limited to a subset of EHI that was narrower than the EHI definition ONC finalized in the ONC Cures Act Final Rule in § 171.102. The narrower subset included only the EHI identified by the data elements represented in the United States Core Data for Interoperability (USCDI) for the first 18 months after the applicability date for 45 CFR part 171 (85 FR 25792). The interim final rule extended the date to October 6, 2022 (85 FR 70069).
Because October 6, 2022, has passed, we propose to revise § 171.103 (information blocking definition) to remove § 171.103(b), which designates the period of time for which the information blocking definition is limited to EHI that consists of the data elements represented in the USCDI. Similarly, because we included the same date in two paragraphs of the Content and Manner exception (§ 171.301(a)(1) and (2)), we propose to revise § 171.301 to remove the existing § 171.301(a)(1) and (2) as no longer necessary. The proposed revised version of § 171.301 refers simply to EHI as defined in § 171.102. We further
In § 171.204, we created an exception under which an actor's practice of not fulfilling a request to access, exchange, or use EHI “due to” the infeasibility of the request would not be considered information blocking. In the preamble of the ONC Cures Act Final Rule (85 FR 25867), we specified that there may be situations when complying with a request for access, exchange, or use of EHI would be considered infeasible because an actor is unable to provide such access, exchange, or use due to unforeseeable or unavoidable circumstances outside the actor's control. We recited our proposals from the ONC Cures Act Proposed Rule, which noted that, as examples, an actor could seek coverage under the Infeasibility Exception if it was unable to provide access, exchange, or use of EHI due to a natural disaster (such as a hurricane, tornado, or earthquake) or war. Importantly, we noted that the actor would need to produce evidence and ultimately prove that complying with the request for access, exchange, or use of EHI in the manner requested would have imposed a clearly unreasonable burden on the actor under the circumstances (85 FR 25866). As part of revisions to add clarity to the Infeasibility Exception in the ONC Cures Act Final Rule, we established the “standalone”
The fact that an uncontrollable event specified in § 171.204(a)(1) occurred is not a sufficient basis alone for an actor to meet the uncontrollable events condition of the Infeasibility Exception. Rather, the use of the words “due to” in the condition was intended to convey, consistent with the ONC Cures Act Proposed Rule, and does convey that the actor must demonstrate a causal connection between not providing access, exchange, or use of EHI and the uncontrollable event. To illustrate, a public health emergency is listed as an uncontrollable event under § 171.204(a)(1). If the Federal Government or a state government were to declare a public health emergency, the mere fact of that declaration would not suffice for an actor to meet the condition. To meet the condition, the actor would need to demonstrate that the public health emergency actually caused the actor to be unable to provide access, exchange, or use of EHI for the facts and circumstances in question. The emergency need not be the
We propose to renumber the Infeasibility Exception's (45 CFR 171.204) “infeasible under the circumstances” condition from paragraph (a)(3) to paragraph (a)(5) and to codify at (a)(3) a new condition “
The proposed § 171.204(a)(3)
In § 171.102, we define “use” for purposes of the information blocking definition to mean “the ability for electronic health information, once accessed or exchanged, to be understood and acted upon.” We stated in the ONC Cures Act Final Rule that “acted upon” within the final “use” definition “encompasses the ability to read, write, modify, manipulate, or apply the information. . . .” (85 FR 25806). Therefore, in § 171.204(a)(3), we propose to use the term “
While the information blocking definition refers to the “access, exchange, or use” of electronic health information, in this portion of the preamble we will instead use the term “modify” or “modification use” to describe the particular type of “use” covered by this new condition. We do so in order to avoid confusion between this “modification use” and the HIPAA Rules' defined term “use” (45 CFR 160.103). The
We propose this new condition to reduce actor burden and uncertainty by creating a condition whereby practices specific to declining
To illustrate the purpose of this proposed condition, an actor may be concerned about the accuracy or reliability of data that a third party would like to add to an individual's designated record set maintained by the actor. Rather than spending resources determining if the Preventing Harm (§ 171.201) or Security (§ 171.203) Exceptions apply, or to consider all of the factors required to determine that a request may be infeasible under the circumstances (currently § 171.204(a)(3), proposed to be renumbered to § 171.204(a)(5)), an actor may be able to make use of the “modification use” condition, if finalized as proposed. More specifically for this example, an actor may be unable to complete a third party's request to modify or add EHI in the specific way that it was requested. Rather than working through all of the alternative manners (and then possibly even ending up using the proposed new “manner exception exhausted” condition of the infeasibility exception), the actor can use the
The
We propose to exclude from applicability of this new condition requests from health care providers to their business associates where these business associates are other actors, such as health IT developers of certified health IT or HINs/HIEs, because the exceptions to the information blocking definition are intended to only cover reasonable and necessary practices of interference that would otherwise constitute information blocking. Covered entities (health care providers) and their business associates (as permitted by their business associate agreement) need to access and modify relevant EHI held by other business associates of those covered entities on a regular basis. Ensuring that this condition does not apply to practices of one business associate/actor that are likely to interfere with health care providers' and their other business associates' ability to access, exchange, and use (including through modification use) EHI maintained by or for the health care provider promotes greater interoperability, efficient transitions of care, and protects the use of EHI as needed to maintain operations. In addition, there is often a level of trust and contractual protections between covered entities and business associates that removes some of the other concerns, such as security and data provenance, that led us to propose this new condition for the specific circumstances when it
Because this new proposed
To provide additional clarity regarding circumstances that would
We request comment generally on this new proposed condition and, if this condition were finalized, whether this condition should be of limited duration. More specifically, we request comment on whether ONC should consider proposing, in the future, that the condition be eliminated if, at some point, health information technology is capable of supporting third-party modification use of EHI by
As with every other condition in § 171.204(a), the proposed § 171.204(a)(3)
We propose to renumber the Infeasibility Exception's (45 CFR 171.204) “
In the ONC Cures Act Proposed Rule, we proposed an exception that would apply where an actor's practice of not fulfilling a request to access, exchange, or use EHI in a manner that is infeasible in the particular circumstances would not be considered information blocking, subject to a duty to provide a reasonable alternative (84 FR 7542). We noted that “in certain circumstances legitimate practical challenges beyond an actor's control may limit its ability to comply with requests for access, exchange, or use” (84 FR 7542). We explained that sometimes those challenges may be related to, for example, technological capabilities. In other cases, however, we noted “the actor may be able to comply with the request, but only by incurring costs or other burdens that are clearly unreasonable under the circumstances” (84 FR 7542). Without such an exception, we noted that inefficiencies could be introduced such that, for example, “the actor may be able, but reluctant, to offer alternative means that would meet the requestor's needs while reducing the burden on the actor, leading to more efficient outcomes overall” (84 FR 7542). To safeguard the exception from inappropriate use, we proposed a two-step test that an actor would need to satisfy in order to meet the exception: first, that complying with the request would impose a substantial burden on the actor, and second, that the burden imposed would be plainly unreasonable under the circumstances (84 FR 7542-43).
In the ONC Cures Act Final Rule (85 FR 25642) we finalized a modified Infeasibility Exception to address concerns raised by commenters (
As discussed in the ONC Cures Act Final Rule (at 85 FR 25869 through 25870) rather than finalize the proposed requirement to provide a reasonable alternative in order for an actor's practice to satisfy the
The Infeasibility Exception, as finalized in the ONC Cures Act Final Rule, provides assurance to an actor that if it meets certain conditions of the exception at all relevant times, its practice will not be considered information blocking. We finalized most but not all of the factors we proposed in the ONC Cures Act Proposed Rule for
We propose to renumber the
Amongst those actors with substantial skills and other resources to develop new, unique or unusual manners of supporting access, exchange, or use of EHI, we see actors who appear to be experiencing a problematic level of uncertainty about whether they will be engaging in information blocking if they decline demands from requestors for non-standard, non-scalable, solutions that they do not currently support
Therefore, this new condition is necessary to ensure actors reasonably allocate resources toward interoperable, standards-based manners rather than allowing requestors who, for whatever reason, do not build their products for compatibility with open consensus standards or other industry standards to attempt to force use of non-standard, non-scalable solutions by simply refusing to accept access, exchange, or use of EHI in any other manner. This diversion of resources away from standards-based, scalable manners of exchange detracts from, instead of supporting, achievement of key policy goals such as increased interoperability and innovation in use of open consensus standards to achieve secure, seamless exchange. Where novel approaches to system interfaces or other aspects of access, exchange, or use of EHI represent improvements over other available approaches, we anticipate these approaches will not need to be forced upon the industry but will instead find a natural foothold and diffuse according to a normal innovation curve.
To illustrate the situation we see and believe this new condition is necessary to remediate: an actor that develops or offers certified health IT may, for example, be uncertain as to whether an information blocking exception covers its practice of denying a requestor's demand for access, exchange, or use in a particular manner that relies on unique specifications instead of “interoperable standards” (for example, standards identified in 45 CFR 171.301(b)(2)(i)(B) and also specified below) because the actor has capabilities and resources that it
It is not our intent that the information blocking regulations drive actors to prioritize various requestors' non-standardized, non-scalable preferences for manners of achieving access, exchange, or use of EHI over directing the actors' development resources to developing and implementing scalable, interoperable solutions to meet patients' and health care providers' needs. Consistent with policy goals for advancing secure, interoperable access, exchange, and use of EHI, we would rather encourage use of standards-based and other generally available mechanisms whenever available to serve the access, exchange, or use need so that as many development resources as possible remain available to actors to focus on continuously improving generally available products' capabilities. The
The proposed § 171.204(a)(4)
(i) The actor could not reach agreement with a requestor in accordance with § 171.301(a)
(ii) The actor offered all alternative manners in accordance with § 171.301(b)
(iii) The actor does not provide the same access, exchange, or use of the requested electronic health information to a substantial number of individuals or entities that are similarly situated to the requester.
As is the case for a practice satisfying any of the conditions codified in § 171.204(a), an actor's practice satisfying the § 171.204(a)(4)
By creating an infeasibility condition that can be met without the actor needing to demonstrate they considered the resources available to the actor, we believe we would accomplish the objective of assuring actors who do not want to develop one-off solution(s) that where the requestor is unwilling to accept an alternative manner of access, exchange, or use of the requested EHI consistent with the § 171.301(b)
The second factor within the proposed § 171.204(a)(4)
• by offering to fulfill the request in two manners that use content and transport standards published by the Federal Government or a standards-developing organization accredited by the American National Standards Institute; or
• by offering fulfilment in at least one such manner
In seeking comment on the proposed new § 171.204(a)(4)
The third factor within the proposed § 171.204(a)(4)
The intent of the § 171.204(a)(4)(iii) factor is to provide a basic assurance that actors would not be able to misuse the § 171.204(a)(4)
The § 171.204(a)(4)(iii) factor is intended to ensure the condition cannot be satisfied where a manner (mechanisms, interoperability elements) is currently supported for a substantial number of individuals or entities but the responding actor wants to deny that mechanism to particular requestor(s) for inappropriate reasons, such as to discriminate against competitors, potential competitors, or those the responding actor may be concerned could use the resultant access, exchange, or use of EHI to furnish, develop, or facilitate development of products or services that could compete with those of the actor. We recognize that such practices are not reasonable and necessary, and therefore should not be covered by an exception to the definition of information blocking. The § 171.204(a)(4)(iii) factor is limited to actors providing the same manner of access, exchange, or use of the same EHI to a “substantial number” rather than a specific number to recognize variation in actors' operational contexts, including their organizational sizes. What may be a trivial number to a large health IT developer of certified health IT might be an important or consequential (“substantial”) number for a small HIN/HIE. However, we propose in the alternative that we would, and thus seek comment on whether we should, instead construct the factor with a simple fixed threshold of “more than one,” or more than another specific number between 1 and 10. Such fixed threshold would offer more simplicity to actors and potential requestors, while still assuring that an actor's practice would not fail to meet this factor on the basis of a single instance of a particular access, exchange, or use manner. For example, a health IT developer of certified health IT may have a single instance of a manner deployed that has been custom developed for a customer with highly unique needs, or a health care provider may have a custom interface established with its local public health authority, that would be impractical to replicate for other individuals or entities who may be legally permitted to access, exchange, or use the same EHI. These examples of one-off manners we would not consider to be consistent with the broad concept of general availability, and thus should not cause the actor's practice of declining requests for
The § 171.204(a)(4)(iii) factor includes whether the requestor is
We remind readers that the intent of this condition, as noted above, is for actors to provide requestors the same access they provide to a substantial number of their customers, preferred customers, owned or affiliated companies, or other non-competitors. In this regard, we request comment on whether we should provide more textual specificity or clarity as to the proposed text “a substantial number of individuals or entities that are similarly situated to the requester.” To further illuminate this question, if an actor provides a certain form of EHI access to health care providers, then that same form of EHI access should arguably be made available to individuals baring potential other considerations (
We believe this new § 171.204(a)(4)
In the ONC Cures Act Proposed Rule (84 FR 7552), we requested comments on whether we should propose, in a future rulemaking, a narrow exception to the information blocking definition for practices that are necessary to comply with the requirements of the Common Agreement. We stated that such an exception may support adoption of the Common Agreement and may encourage other entities to participate in trusted exchange through HINs that enter into the Common Agreement. We discussed that it would do so by providing protection if there are practices that are expressly required by the Common Agreement, or that are necessary to implement Common Agreement requirements, that might implicate the information blocking definition and would not qualify for another exception. We noted that such an exception would be consistent with the complementary roles of the information blocking provision and other provisions of the Cures Act that support interoperability and enhance the trusted exchange of EHI (including the interoperable network exchange provisions (42 U.S.C. 300jj-11(c)(9)), the definition of interoperability (42 U.S.C. 300jj(9)), and the conditions of certification in 42 U.S.C. 300jj-11(c)(5)(D)). We further noted that we expected that any proposal would be narrowly framed such that contract terms, policies, or other practices that are not strictly necessary to comply with the Common Agreement would not qualify for the exception. Similarly, we expected that any future proposal would provide that an actor could benefit from this exception only if the practice or practices that the actor pursued were no broader than necessary under the circumstances. We commented that these limitations would ensure that the exception would be narrowly tailored to practices that are most likely to promote trusted exchange without unnecessarily impeding access, exchange, or use of EHI.
Comments we received in response to the request for information (RFI) varied. There were generally two overarching themes in the comments. The first theme was that it was premature to establish an exception until TEFCA was finalized. The second theme focused on the need for an exception. A majority of commenters asserted that there should be some form of “safe harbor” for TEFCA participants, while other commenters contended that such an approach was unwarranted and that all actors should be subject to the same information blocking policies and requirements. Overall, comments received in response to the RFI that were in favor of an exception outnumbered those that were not in favor. Some commenters advocating for an exception covering or incentivizing TEFCA participation noted that such an exception would provide certainty and reduce the compliance burden for the market. The HITAC's recommendation
During the development of TEFCA and since the publication of the Common Agreement on January 19, 2022,
We propose to add a TEFCA condition to the proposed revised and renamed Manner Exception, to be codified in 45 CFR 171.301. The new condition, in proposed § 171.301(c), would read as follows: “If an actor who is a QHIN, Participant, or Subparticipant offers to fulfill a request for EHI access, exchange, or use for any permitted purpose under the Common Agreement and Framework Agreement(s) from any other QHIN, Participant, or Subparticipant using Connectivity Services, QHIN Services, or the specified technical services in the applicable Framework Agreement, then: (i) The actor is not required to offer the EHI in any alternative manner; (ii) Any fees charged by the actor in relation to fulfilling the request are not required to satisfy the exception in § 171.302; and (iii) Any license of interoperability elements granted by the actor in relation to fulfilling the request is not required to satisfy the exception in § 171.303.”
This proposal aligns with a foundational policy construct underpinning the Manner Exception in that it facilitates an actor reaching agreeable terms with a requestor to fulfill an EHI request and acknowledges that certain agreements have been reached for the access, exchange, and use of EHI (for example, by using standards consistent with the Common Agreement or applicable flow-down Framework agreements that the actor and requestor have agreed to abide by). Such TEFCA agreements could already fall under the current “manner requested” condition of the Manner Exception where the request is for EHI and is for an exchange purpose for which the QHIN, Participant, or Subparticipant is obligated to respond consistent with the Common Agreement or any applicable Participant-QHIN or Participant-Subparticipant Agreement(s). However, consistent with the information blocking regulations, we propose that this condition would apply for any and all EHI as defined in 45 CFR 171.102 and for exchange purposes beyond those required to be supported in the Common Agreement for Nationwide Health Information Interoperability, Version 1, as published on January 19, 2022, in the
Our proposal would offer actors certainty that fulfilling, or even attempting to fulfill, requests for EHI using Connectivity Services, QHIN Services, or the specified technical services in the applicable Framework Agreement (together referenced here as “TEFCA means,” solely for ease of discussion) are covered by the Manner Exception when requestors are parties to the Common Agreement or a Framework Agreement under the Common Agreement, even when the EHI may exceed the minimum data classes and elements
Another important feature of the proposed TEFCA condition is that it can be satisfied by the responding QHIN, Participant, or Subparticipant either fulfilling or
As discussed above regarding the ONC Cures Act Final Rule TEFCA RFI, this approach aligns with the Cures Act's goals for interoperability and the establishment of TEFCA by acknowledging the value of TEFCA in promoting access, exchange, and use of EHI in a secure and interoperable way. This approach furthers both of these goals (TEFCA adoption and interoperability) by offering actors subject to the Cures Act's information blocking provision that also choose to become QHINs, Participants, or Subparticipants certainty that their practice of declining to fulfill a request to access, exchange, or use EHI in other manners that a QHIN, Participant, or Subparticipant might initially seek will qualify for the exception so long as the responding actor fulfills (or at least offers to fulfill) the request using available TEFCA means. The proposed TEFCA condition also incorporates multiple aspects responsive to public comments and feedback received on the ONC Cures Act Proposed Rule (84 FR 7424). It recognizes and supports actors that choose to adopt and comply with the Common Agreement by providing certainty and burden reduction for those actors when it comes to information blocking and requests for access, exchange, or use of EHI by QHINs, Participants, or Subparticipants. The
Each QHIN, Participant, or Subparticipant has chosen to become a part of the TEFCA ecosystem. Where mechanisms consistent with TEFCA's technical framework and other requirements relevant to particular type(s) of EHI and purpose(s) of exchange
• for any and all EHI for which access, exchange, or use can be supported by TEFCA means for both the actor and requestor;
• so long as the requestor is a QHIN, Participant, or Subparticipant and the purpose of the access, exchange, or use is permitted under the TEFCA governing agreements;
• regardless of whether the request is initially made through TEFCA means or otherwise; and
• regardless of whether all of the particular data class(es) or exchange purpose(s) requested are yet
In providing a clear, efficient path to regulatory certainty that prioritizes exchange amongst QHINs, Participants, and Subparticipants in TEFCA using TEFCA means of sharing any and all EHI that TEFCA means can support will not be considered information blocking, we hope to incentivize (and accelerate) all QHINs, Participants, and Subparticipants to embrace and accelerate their use of the available, interoperable, and secure TEFCA technical services to support the access, exchange, and use of as much EHI as possible for as many purposes as are permitted under the TEFCA governing agreements. To provide clarity, we note that the establishment of this condition would identify such prioritization on TEFCA means of responding to other QHIN, Participant, or Subparticipant requests for access, exchange, or use of EHI as reasonable and necessary for those QHINs, Participants, and Subparticipants who choose that approach. The establishment of the TEFCA condition would not preclude a QHIN, Participant, or Subparticipant information blocking actor from making a different choice with respect to supporting non-TEFCA means in complement to TEFCA means of information sharing with others who choose to become QHINs, Participants, and Subparticipants.
In order to satisfy this condition, we are considering requiring that an actor would need to check an available directory of all QHINs, Participants, and Subparticipants under the TEFCA governing agreements in order see if the requestor is listed. As described in the QHIN Technical Framework, the “Directory Service will be the primary location for determining the HomeCommunityID and Responding QHIN for QHIN-to-QHIN data exchange. QHINs will be responsible for updating the RCE Directory Service with HomeCommunityIDs of their connected Participants and Subparticipants. QHINs are expected to maintain a local copy of the contents of the RCE Directory Service to support their Connectivity Services and facilitate query and message delivery transactions.” While the listing or non-listing of a requestor in such a directory would not be dispositive as to the truth of the matter, an actor checking the directory would likely improve the efficiency of such interactions (
We seek comment on whether we should consider proposing in future rulemaking any additional exclusions from the
We seek comment on whether any other particular practices that are not otherwise required by law but are required of an individual person or entity by virtue of their status as a QHIN, Participant, or Subparticipant pursuant to the Common Agreement pose a substantial concern or uncertainty regarding whether such practices
For more information on TEFCA, please visit:
ONC believes that data segmentation is an integral capability for enabling the access, exchange, and use of electronic health information (85 FR 25705). While initiatives such as security tagging capabilities represent an initial step towards enabling appropriate access, exchange, and use of health information in accordance with applicable law and patient preferences, many additional data segmentation challenges remain, including the prevalence of unstructured data, the sharing of image files, the use of sensitive health information (see section III.C.10 of this proposed rule and 85 FR 25702), and other technical and non-technical (
We have received public feedback indicating that there is significant variability in health IT products' capabilities to segment data, notably including enabling differing levels of access to data based on the user and purpose. There are, as also discussed in section III.C.10 of this proposed rule, many situations in which segmentation of data may be required or requested, including use cases where special handling or other restriction of access, exchange, or use of particular portion(s) of a patient's EHI is required by law or consistent with an individual patient's expressed preference regarding their own or others' access to their EHI. In section III.C.10 of this proposed rule, we propose a new certification criterion specifically focused on supporting patient preferences related to their right to request a restriction on certain uses and disclosures of their PHI under the HIPAA Privacy Rule (see 45 CFR 164.522). This proposed functionality is focused specifically on supporting one health IT enabled mechanism for a patient to request a restriction on disclosure and for a covered entity to honor that restriction using a certified Health IT Module (See section III.C.10 for further detail).
In addition to the specific right to request a restriction on disclosure consistent with 45 CFR 164.522, there are other use cases related to patient preferences—and specific nuances within use cases—which present challenges from a technical point of view. Through public forums and correspondence with ONC, interested parties in the healthcare community have conveyed that their certified health IT lacks capabilities to differentiate the timing of release of certain EHI based on patients' individual preferences. Some interested parties have also indicated that their certified health IT may have little or no ability to restrict a patient's personal representative's access to only some of the patient's EHI using electronic means such as a portal or API or to easily hold back only some pieces of the patient's EHI, in response to or at the patient's request, while honoring the patient's simultaneous preference for the rest of their EHI to be shared with another of their health care providers. One example of a reason an individual might request that some of their information be withheld from (not disclosed to or shared with) some of their health care providers while the rest of their information continued to be shared would be that the individual expects certain information could be associated with conditions or care that may be stigmatized by health care providers other than the one to whom the individual disclosed the information or who provided the specific care. A provider who knows a patient requested restrictions on (or expressed a preference not to share) specific information out of concern about potential stigmatization might want to honor the patient's request to as part of or in support of patient-provider confidentiality and patient trust, regardless of whether the health care provider shared the patient's concern about how other providers might react to the specific information the patient believes would be potentially stigmatizing. Out of respect for the patient's privacy and autonomy and fostering trust within patient-provider relationship, a provider might choose to honor a patient's request for restrictions on sharing of their EHI even if the provider did not
We seek comment to inform steps we might consider taking to improve the availability and accessibility of solutions supporting health care providers' and other information blocking actors' efforts to honor patients' expressed preferences regarding their EHI. For example, patients may express a preference for a delay in the availability of information to them (such as in a health care provider's patient portal). Or, for another example, actor could choose to honor a patient request that to the actor withhold certain information from particular access, exchange, or use consistent with the individual right to request restrictions under the HIPAA Privacy Rule and the information blocking Privacy Exception.
Based on questions and feedback we have received subsequent to the ONC Cures Act Final Rule, examples of situations (or “use cases”) include, but are not limited to:
• A heath care provider needs to prove or validate consent of the patient (by electronic or manual means) regarding EHI subject to the Confidentiality of Substance Use Disorder Patient Records regulations, 42 CFR part 2—or other federal law or applicable state or tribal law with specific consent requirements—prior to sharing it with another health care provider treating the same patient for other clinical concerns.
• A health care provider needs to identify and segment from particular access, exchange, or use by specific entities for specific purposes data subject to varying state laws requiring special handling or access restrictions in such situations—such as behavioral health information, HIV diagnosis and treatment, genetic testing, treatment of minors, or incidents of sexual violence.
• An actor's practice meets the conditions of the Preventing Harm Exception (§ 171.201) for withholding EHI for access, exchange, or use—such as access by the patient or by a particular personal representative of the patient—of
• A health care provider (or other actor) chooses to grant a patient's request to delay the release of certain EHI—such as new diagnoses or particular laboratory or imaging result(s)—to the patient or the patient's personal representative either for a particular period of time or until a particular event, such as communication between the patient and a clinician or patient educator, has occurred.
• A health care provider (or other information blocking actor) wants to respect an individual's request, per the individual's privacy preference, not to share
• The actor wishes to be certain their practices for respecting these patient privacy preferences will not be considered information blocking, so they set up their practices in accordance with § 171.202(e), the sub-exception to the privacy exception concerning respecting an individual's request not to share information.
• A health care provider needs to identify and segment data for research purposes, according to the conditions outlined in the HIPAA Privacy Rule
It is our impression that at least some health care providers and their patients sometimes encounter various challenges as they work to provide patients or their personal representatives with electronic access to the information they want when they want it. These challenges notably include, though they are not necessarily limited to, shortfalls in the technical capability of some health IT to segment and filter EHI for appropriate access, exchange, and use consistent with applicable law and patient preferences.
Examples of challenges or technical limitations to EHI segmentation and filtering to facilitate appropriate EHI access, exchange, or use that have been described to ONC include, but are not necessarily limited to:
• A certified EHR (certified health IT) currently in use by a health care provider that is, as implemented, capable only of “all or nothing” release of all EHI test results for all patients immediately to the patient portal, without offering the ordering clinicians or other healthcare professionals using the certified EHR any capability to flag or withhold individual EHI test results for an individual patient from the patient portal.
• A health care provider's current certified EHR is designed and implemented such that any test result the patient and health care provider want to have available to the patient in the portal must be manually pushed to the portal, result by result, by the ordering clinician.
• Existing segmentation tools or modalities (for example, implementation of segmentation capabilities only by broad data class rather than at the level of individual data point) not providing enough flexibility to address more complex use cases, such as honoring a patient's request to have immediate access to most of their EHI but to have electronic access to some EHI, such as test results, that are complicated to interpret or indicate a potential of a life-limiting diagnosis, only after such results have been explained to them in real time by an appropriately qualified healthcare professional.
• An existing certified EHR system does not have technical capacity to appropriately segment and share specific health information according to applicable laws, such as where a parent or legal guardian is legally permitted to obtain portions of a non-emancipated minor child's EHI regardless of the child's consent but not legally permitted to obtain other portions of the child's EHI without the child's consent.
• No health IT that a health care provider has or could implement includes the capability to automate the capture and execution of a patient's or patient's personal representative's unique individual preferences for when new EHI becomes available to them through electronic access.
In this proposed rule, we seek comment related to the capabilities of health IT products to segment data and support health care providers (and actors) in sharing information consistent with patient preferences and all laws applicable to the creation, collection, access, exchange, use and disclosure of EHI.
We also seek comment on experiences with the availability and utility of certified health IT products' capabilities to segment data in use cases including but not limited to the illustrative examples above. We also seek comment on how greater consistency in provider documentation practices could enhance the feasibility of technical segmentation solutions. Similarly, we seek comment on barriers to technical feasibility presented by local, state, and federal regulations. Further, we note our proposal in section III.C.10 and request comment on how else the Program could better support the other use cases described above either through functional or standards-based certification requirements.
The Office of the Federal Register has established requirements for materials (
To make the materials we intend to incorporate by reference reasonably available, we provide a uniform resource locator (URL) for the standards and implementation specifications. In many cases, these standards and implementation specifications are directly accessible through the URLs provided. In most of these instances, access to the standard or implementation specification can be gained through no-cost (monetary) participation, subscription, or membership with the applicable standards developing organization (SDO) or custodial organization. Alternatively, a copy of the standards may be viewed for free at the U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW, Washington, DC 20201. Please call (202) 690-7171 in advance to arrange inspection.
The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701
As required by § 51.5(a), we provide summaries of the standards we propose to adopt and subsequently incorporate by reference in the Code of Federal Regulations. We also provide relevant information about these standards and implementation specifications throughout the preamble.
We have organized the following standards and implementation specifications that we propose to adopt through this rulemaking according to the sections of the Code of Federal Regulations (CFR) in which they would be codified and cross-referenced for associated certification criteria and requirements that we propose to adopt. We note, in certain instances, that we request comment in this proposed rule on multiple standards or implementation specifications that we are considering for adoption
Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.
Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.
Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.
Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.
This is a direct access link.
This is a direct access link.
This is a direct access link.
This is a direct access link.
The code set can be accessed through this link.
This is a direct access link.
This is a direct access link.
Access requires registration, a user account, and license agreement. There is no monetary cost for registration, a user account, and license agreement.
This is a direct access link.
Access requires a user account and license agreement. There is no monetary cost for a user account and license agreement.
Access requires a user account and license agreement. There is no monetary cost for a user account and license agreement.
This is a direct access link.
This is a direct access link.
This is a direct access link.
Because of the large number of public comments normally received in response to
Under the Paperwork Reduction Act of 1995 (PRA), codified as amended at 44 U.S.C. 3501
1. Whether the information collection is necessary and useful to carry out the proper functions of the agency;
2. The accuracy of the agency's estimate of the information collection burden;
3. The quality, utility, and clarity of the information to be collected; and
4. Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.
Under the PRA, the time, effort, and financial resources necessary to meet the information collection requirements referenced in this section are to be considered. We explicitly seek, and will consider, public comment on our assumptions as they relate to the PRA requirements summarized in this section. To comment on the collection of information or to obtain copies of the supporting statements and any related forms for the proposed paperwork collections referenced in this section, email your comment or request, including your address and phone number to
We propose that response submissions related to the Insights Condition and Maintenance of Certification requirements as discussed in section III.F of this preamble would be submitted to an independent entity on behalf of ONC. Specifically, we intend to award a grant, contract, or other agreement to an independent entity as part of the implementation of the Insights Condition and Maintenance of Certification requirements and will provide additional details through subsequent information. We intend to make responses publicly available via an ONC website and intend to provide developers of certified health IT the opportunity to submit qualitative notes that would enable them to explain findings and provide additional context and feedback regarding their submissions.
For the purposes of estimating potential burden, we believe the independent entity would take approximately 5 minutes to review a response submission for completeness, and approximately 30 minutes to submit the completed response submission to ONC, based on how many products a health IT developer of certified health IT may be required to submit responses for. We also plan to minimize burden for the independent entity by automating parts of the response review and submission process via an online tool (estimated that ONC will spend approximately $1.5 million to develop and implement). We welcome comments if it is believed that more or less time should be included in our estimate.
We propose in 45 CFR 170.407 that a health IT developer of certified health IT must submit responses associated with the Insights Condition and Maintenance of Certification requirements to an independent entity twice a year. We plan to minimize burden for health IT developers of certified health IT by providing a web-based submission form and method to simplify the process for response submission. For the purposes of estimating potential burden, we are estimating 52 health IT developers of certified health IT will be required to report on the proposed measures within the Insights Condition and Maintenance of Certification requirements. We believe it will take approximately 21,136 to 44,900 hours on average for a health IT developer of certified health IT to collect and report on the proposed measures within the Insights Condition and Maintenance of Certification requirements. For the purposes of estimating the total potential burden for health IT developers of certified health IT, we estimate an average burden of 2,334,800 hours. However, this is a crude upper bound estimate as there are multiple measures with varying complexity associated with the Insights Condition and Maintenance of Certification, and the number of health IT developers of certified health IT required to report changes by each measure. For a more detailed discussion and the cost estimates of these new regulatory requirements associated with the Insights Condition and Maintenance of Certification, we refer readers to section VIII., Regulatory Impact Statement, of this proposed rule. We welcome comments if it is believed that more or less time should be included in our estimate.
We propose in § 170.315(b)(11)(vii)(B) that health IT developers compile documentation regarding the intervention risk management practices listed in § 170.315(b)(11)(vii)(A), and upon request from ONC, make available such detailed documentation for any predictive decision support intervention, as defined in § 170.102, that the certified Health IT Module enables or interfaces with. We believe ONC has the authority to conduct Direct Review consistent with § 170.580(a)(2) for any known non-conformity or where it has a reasonable belief that a non-conformity exists enabling ONC to have oversight of these requirements. The PRA, however, exempts these information collections. Specifically, 44 U.S.C. 3518(c)(1)(B)(ii) excludes collection activities during the conduct of administrative actions or investigations involving the agency against specific individuals or entities.
We propose in § 170.315(b)(11)(vii)(C) that a health IT developer that attests “yes” in § 170.315(b)(11)(v)(A) submit summary information of the intervention risk management practices listed in § 170.315(b)(11)(vii)(A)(
This proposed rule is necessary to meet our statutory responsibilities under the Cures Act and to advance HHS policy goals to promote interoperability and mitigate burden for health IT developers and users. Proposals that could result in monetary costs for health IT developers and users include the: (1) proposals to update ONC Certification Criteria for Health IT; (2) proposal for the Insights Condition and Maintenance of Certification requirements; and (3) proposals related to information blocking.
While much of the costs of this proposed rule will fall on health IT developers that seek to certify health IT under the Program, we believe the implementation and use of ONC Certification Criteria for Health IT, compliance with the Insights Condition and Maintenance of Certification requirements (“Insights Condition”), and the provisions related to information blocking proposed would ultimately result in significant benefits for health care providers and patients. We outline some of these benefits below. We emphasize in this regulatory impact analysis (RIA) that we believe this proposed rule would remove barriers to interoperability and EHI exchange, which would greatly benefit health care providers and patients.
We note in this RIA that there were instances in which we had difficulty quantifying certain benefits due to a lack of applicable studies, data, or both. However, in such instances, we highlight the significant non-quantified benefits of our proposals to advance an interoperable health system that empowers individuals to use their EHI to the fullest extent and enables health care providers and communities to deliver smarter, safer, and more efficient care.
If there are alternatives to our proposals, we have described them within each of the sections within this RIA. In some cases, we have been unable to identify alternatives that would appropriately implement our responsibilities under the Cures Act and support interoperability. We believe our proposals take the necessary steps to fulfill the mandates specified in the Public Health Service Act (PHSA), as amended by the Health Information Technology for Economic and Clinical Health (HITECH) Act and the Cures Act, in the least burdensome way. We are, however, open to less burdensome alternatives that meet statutory requirements and our goals. Accordingly, we welcome comments on our assessment and any alternatives we should consider.
We have examined the impact 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 (February 2, 2011), section 202 of the Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1532), and Executive Order 13132 on Federalism (August 4, 1999).
Executive Orders 12866 on Regulatory Planning and Review and 13563 on Improving Regulation and Regulatory Review 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). An RIA must be prepared for major rules with economically significant effects ($100 million or more in any one year). OMB has determined that this proposed rule is an economically significant rule as the potential costs associated with this proposed rule could be greater than $100 million per year. Accordingly, we have prepared an RIA that to the best of our ability presents the costs and benefits of this proposed rule.
We have estimated the potential monetary costs and benefits of this proposed rule for health IT developers, health care providers, patients, and the Federal Government (
Our cost calculations quantify health IT developers' time and effort to implement these proposals through new development and administrative activities. We recognize that the costs developer incur as a result of these proposals may be passed on to certified technology end-users. These end-users include but are not limited to the nearly 5,000 non-federal hospitals who provide acute, inpatient care and over 1 million clinicians who provide outpatient care to all Americans. Official statistics show that nearly all U.S. non-federal acute care hospitals (
The benefits, both quantifiable and not quantifiable, articulated in this impact analysis have the potential to remove barriers to interoperability and EHI exchange for all these health care providers. Though these proposals first require effort by health IT developers to engineer them into their software, they must then be implemented by end-users to achieve the stated benefits—to healthcare delivery and the overall efficacy of the technology to document, transmit, and integrate EHI across multiple data systems.
To this end, we acknowledge that these estimated costs may not be borne solely by the health IT developers and could be passed on to end-users through health IT developers' licensing, maintenance, and other operating fees and costs. We assume health IT developers may pass on up to the estimated costs of these proposals, but not amounts above those estimated totals.
However, we have limited data on the fees and costs charged by health IT developers and how those fees and costs are distributed across various customer organizations. Given the ongoing nature of updates made by ONC to certified EHR technology, EHR developers may have already built in the costs associated with making these updates in their existing contracts. To the extent the costs associated with the updates we have proposed have not been taken into account, these costs may be passed on to end-users in different ways by health IT developers and across different health care provider organization types. Large integrated healthcare systems may face different fees and other pricing than different sized or structured health care provider organizations. The incredible diversity of the healthcare system also limits our ability to accurately model how these costs could be passed on even if there were data available to estimate how these proposals might alter the pricing models and fee rates of the nearly 400 health IT developers we estimate will be impacted by these proposals.
What we can say with more certainty is the overall impact of these proposals on the healthcare system as a whole. These proposals affect the certified technology used by the providers who give care to a vast majority of Americans. Nearly all emergency room visits, hospital stays, and regular check-ups are documented and managed using certified health IT. These proposals affect the interoperability of EHI for these care events and patients' electronic access to their health information. Certified health IT is now a nearly ubiquitous part of U.S. healthcare, and the costs and benefits estimated here encompass the far reach of these technologies and their impact on all facets of care.
Overall, it is highly speculative to quantify benefits associated with new technologies and standards we are proposing given their novelty and limited use. Emerging technologies may be used in ways not originally predicted. For example, ONC helped support the development of SMART on FHIR, which defines a process for an application to securely request access to data, and then receive and use that data. ONC would not have predicted that it would not only be used to support major EHR products, but also be used by Apple to connect its Health App to hundreds of healthcare systems, and used for apps launch on the Microsoft Azure product. It is also speculative to quantify benefits for specific stakeholders because benefits associated with many of ONC's proposals, which advance interoperability, don't necessarily accrue to stakeholders making the investments in developing and implementing the technologies. Benefits related to interoperability are spread across the healthcare ecosystem and can be considered a societal benefit. We have sought to describe benefits for each of the specific proposals and we welcome comments on how to quantify these benefits across a variety of stakeholders.
We note that we have rounded all estimates to the nearest dollar and that all estimates are expressed in 2021 dollars as it is the most recent data available to address all cost and benefit estimates consistently. The wages used to derive the cost estimates are from the May 2021 National Occupational Employment and Wage Estimates reported by the U.S. Bureau of Labor Statistics.
For proposals where research supported direct estimates of impact, we estimated the benefits. For proposals where no such research was identified to be available, we developed estimates based on a reasonable proxy.
We note that interoperability can positively impact patient safety, efficacy, care coordination, and improve healthcare processes and other health-related outcomes.
We have made employee assumptions about the level of expertise needed to complete the proposed requirements in this section. Unless indicated otherwise, for wage calculations for federal employees and ONC-ACBs, we have correlated the employee's expertise with the corresponding grade and step of an employee classified under the General Schedule (GS) Federal Salary Classification, relying on the associated employee hourly rates for the Washington, DC, locality pay area as published by the Office of Personnel Management for 2021.
In this section, we describe the methodology used to assess the potential impact of new certification requirements on the availability of certified products in the health IT market. This analysis is based on the number of health IT developers that certified Health IT Modules for the 2015 Edition and the estimated number of developers that will participate in the future and the number of products these developers will certify.
These estimations are based on observed and expected conformance to 2015 Edition Cures Update requirements, market consolidation, and other voluntary and involuntary withdrawals from the Program. In Table 6 below, we quantify the number of participating developers and certified products for the 2011 Edition, 2014 Edition, and 2015 Edition. We found that the number of health IT developers certifying products between the 2011 Edition and 2014 Edition decreased by 22.1% and the number of products available decreased by 23.2%. Furthermore, we found that between the 2014 Edition and 2015 Edition the number of developers and products decreased by 38.3% and 33.9%.
We recognize that certification for 2015 Edition is ongoing and the number of health IT developers certifying products to the 2015 Edition is subject to change. The figures for 2015 Edition in Table 6 reflect certifications through 2021 to provide a fixed point for analysis. We have found it prudent to use certification data that represent entire calendar years, and not to use certification stats mid-year. Therefore, 2015 Edition counts do not account for all certificates as of the publication of this proposed rulemaking.
These figures give us insight into how participation in the Program and certification for individual certification editions has changed over time—the effect of both market and regulatory forces. Given historical trends and the asymmetric costs faced by developers of certified technology with large and small client bases, we must consider the effect of certification requirements going into effect and proposed in this rulemaking on future participation in the Program to make our best estimates of the cost and benefits of this proposed rulemaking.
Our proposed estimates of health IT developers and certified products specifically factor in a reduction in Program participation due to non-conformance with the 2015 Edition Cures Update criterion,
In the RIA for the ONC Cures Act Final Rule, we estimated that certified API products that did not support FHIR and must do so to meet regulatory requirements may face up to $1.9 million in development and other labor and maintenance costs to develop this technology for the first time (85 FR 25921). In 2018
Our model assumes that 1 in 4 certified API developers that do not currently support FHIR will not certify the
At the end of 2021, 414 health IT developers certified 569 products with active certificates for the 2015 Edition or 2015 Edition Cures Update. This is a 15% decrease in the number of health IT developers and a 20% decrease in 2015 Edition certified products, overall. Using our model of certification for the
For the purpose of this analysis, the population of end users impacted are the number of health care providers that possess certified health IT. Due to data limitations, our analysis is based on the number of hospitals and clinicians who participate in Medicare and who may be required to use certified health IT to participate in various Medicare programs, inclusive of those providers who received incentive payments to adopt certified health IT as part of the Medicare EHR Incentive Program.
One limitation of this approach is that we are unable to account for the impact of our provisions on users of health IT that were ineligible or did not participate in the CMS EHR Incentive Programs or current Medicare performance programs. For example, in 2017, 78 percent of home health agencies and 66 percent of skilled nursing facilities reported adopting an EHR (
Despite these limitations, these Medicare program participants represent an adequate sample on which to base our estimates. An analysis of the CMS Provider of Services file for Hospitals (
We understand there will likely not be a proportional impact of these costs across all health care providers. We can assume a hospital would face different costs than a physician practice, and no two hospitals would face the same costs, as those costs may vary based upon various characteristics, including but not limited to: staff size, patient volume, and ownership. The same is true for individual clinical practices, for which costs may vary across the same characteristics as hospitals. However, given our limited data, our proposed approach to model pass-through costs onto health care providers assumes that hospitals face the same average costs and that they face a higher average cost per site than an individual clinical practice. Furthermore, we assume that clinical practices face the same average costs and lower average costs per site than the average hospital.
Based upon our prior modeling work for the Cures Act Final Rule (
One issue to reiterate is that some of these costs may have already been incorporated within existing contracts and thus it is possible that the actual additional costs experienced by hospitals and clinicians may be lower
It's unknown if the estimated benefits would have the same distribution. A single clinician may not benefit the same as a single hospital, nor would one hospital benefit the same as another. However, given the same constraints to model costs across different provider types, we must assume a similar distribution for benefits as we propose for costs.
As discussed in section III.A of this preamble, we propose to rename § 170.315 as the “ONC Certification Criteria for Health IT” and replace all references throughout 45 CFR part 170 to the “2015 Edition” with this new description (this would impact §§ 170.102, 170.405, 170.406, 170.523, 170.524, and 170.550).
This proposal is not intended to place additional burden on health IT developers and does not require new development or implementation. We expect the costs associated with attesting to these criteria to be de minimis because we do not expect any additional effort on the part of health IT developers. We welcome comments on these expectations.
Maintaining a single set of “ONC Certification Criteria for Health IT” will create more stability for the health IT community and Program partners and make it easier for health IT developers of certified health IT to maintain their product certificates over time. For example, when new rules are released, unchanged certification criteria will remain exactly as they are, rather than being placed in a new CFR section and requiring health IT developers to seek an updated certificate attributed to the new CFR section. We welcome comments on this expectation and any potential approaches to quantifying these benefits.
As discussed in section III.C.1 of this preamble, we propose to update the USCDI standard in § 170.213 by adding the newly released USCDI v3 and by establishing an expiration date for USCDI v1 (July 2020 Errata) on January 1, 2025, for purposes of the Program. We propose to add USCDI v3 in § 170.213(b) and incorporate it by reference in § 170.299. We propose to codify the existing reference to USCDI v1 (July 2020 Errata) in § 170.213(a). We propose that as of January 1, 2025, any Health IT Modules seeking certification for criteria referencing § 170.213 would need to be capable of exchanging the data classes and data elements that comprise USCDI v3. Additionally, once the USCDI standard in § 170.213 is updated to include USCDI v3, we propose that in order for previously certified Health IT Modules to maintain certification, health IT developers would be required to update their certified Health IT Modules to be capable of exchanging the data classes and data elements that comprise USCDI v3 for all certification criteria referencing § 170.213 by December 31, 2024. USCDI, via cross-reference to § 170.213, is currently referenced in the following criteria, each of which would refer to USCDI v1 and USCDI v3 until December 31, 2024, and only to USCDI v3 thereafter, if we finalize our proposal:
• “Care coordination—Transitions of care—Create” (§ 170.315(b)(1)(iii)(A)(
• “Care coordination—Clinical information reconciliation and incorporation—Reconciliation” (§ 170.315(b)(2)(iii)(D)(
• “Patient engagement—View, download, and transmit to 3rd party—View” (§ 170.315(e)(1)(i)(A)(
• “Design and performance—Consolidated CDA creation performance” (§ 170.315(g)(6)(i)(A));
• “Design and performance—Application access—all data request—Functional requirements” (§ 170.315(g)(9)(i)(A)(
• “Design and performance—Standardized API for patient and population services—Data response” (§ 170.315(g)(10)(i)(A) and (B)).
We note that § 170.315(f)(5) also currently references § 170.213. However, we propose to rely on specific implementation guides for this certification criterion, rather than referencing § 170.213. As such, we do not expect Health IT Modules certified to § 170.315(f)(5) to certify using either USCDI v1 or USCDI v3 (through December 31, 2024) and USCDI v3 only after this date, if we finalize our proposal, as we do the above listed criteria.
The USCDI v3 adds five new data classes and 46 new data elements that were not in USCDI v1. This will require updates to the Consolidated Clinical Document Architecture (C-CDA) standard, the FHIR US Core Implementation Guide, and updates to the criteria listed above. We have estimated the proposed cost to health IT developers to add support for the additional data classes and data elements in USCDI v3 in C-CDA, and to make the necessary updates to the affected certification criteria. These estimates are detailed in Table 9 below and are based on the following assumptions:
1. Health IT developers will experience the assumed average costs of labor and data model use. Table 9 shows the estimated labor costs per product for a health IT developer to develop support for the additional data elements and data classes in USCDI v3 for each affected certification criteria. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will incur, on average, the costs noted in Table 9.
2. We estimate that 346 products certified by 269 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.
We estimate that, in total, 368 health IT developers will certify 502 health IT products impacted by this proposal. However, not all these developers and products certify USCDI applicable criteria and need to meet the USCDI update requirements. As of the end of 2021, 73% of developers and 69% of products certified to one of the USCDI applicable criteria, listed above. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the USCDI updates. In Table 10, we also applied separate modifiers for individual criteria, calculated from an analysis of certificates through 2021. This allows us to more accurately assess USCDI update costs for individual criteria.
3. According to the May 2021 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $58.17. As noted previously, we have assumed that other indirect costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including other indirect costs is $116.
The cost to a health IT developer to develop support for the additional USCDI data classes and elements vary by the number of applicable criteria certified for a Health IT Module. On average, the cost to update C-CDA creation to support the additional USCDI data elements range from $208,8000 to $417,600 per product. The cost to make updates to individual criteria to support the new data classes and elements range from $23,200 to $69,600 per product. Therefore, assuming 346 products overall and a labor rate of $116 per hour, we estimate that the total cost to all health IT developers would, on average, range from $111 million to $262 million. This would be a one-time cost to developers per product that is certified to the specified certification criteria and would not be perpetual.
We believe this proposal would benefit health care providers, patients, and the industry as a whole. The USCDI comprises a core set of structured and unstructured data needed to support patient care and facilitate patient access using health IT; establishes a consistent baseline of harmonized data elements that can be broadly reused across use cases, including those outside of patient care and patient access; and will expand over time via a predictable, transparent, and collaborative process, weighing both anticipated benefits and industry-wide impacts. In Standards Bulletin
In section III.C.4 of this preamble, we propose updates to the 2015 Edition certification criterion for “
This section describes the estimated costs of meeting the requirements in the updated “
•
•
•
Based on the stated assumptions and costs outlined in Tables 14-16, the total estimated cost for certified health IT products to meet the proposed eCR certification criterion requirements will range from $32.7 million to $99.6 million. Assuming 162 health IT developers, there would be an average cost per developer ranging from $201,926 to $614,628, with an average cost per product ranging from $232,000 to $540,560 for new products and $0 to $424,560 for currently certified products.
The primary benefit of adopting standards-based requirements for the eCR certification criterion is to improve consistency and promote interoperability over time. eCR is one of the pillars of ONC's and CMS' broader efforts to support effective healthcare data interoperability, which ensures that electronic health information is shared appropriately between healthcare organizations and public health agencies (PHAs) in the right format, through the right channel at the right time.
Potential benefits of a centralized approach to eCR have been assessed in an Association of State and Territorial Health Officials (ASTHO)-sponsored economic analysis of the efficiencies gained at PHAs by using centralized eCR services through the Association of Public Health Laboratories (APHL) Informatics Messaging Services (AIMS) platform, rather than using localized eCR solutions or manual, paper-based methods.
Benefits of eCR to the healthcare sector and public health that would be promoted through standards adoption:
• Automatic, complete, accurate data reported in real-time (faster and more complete than manual entry) facilitates evidence-based decision-making for public health.
• Directly benefits public health response efforts by supporting
• Helps improve public health efficiency for evaluation and follow-up by providing PHAs with higher quality patient and clinical data in a timely manner.
• Reduces reporting burden for health care providers without disrupting clinical workflow, which can result in time and cost savings for the healthcare sector.
• Fulfills legal reporting requirements as well as CMS PI Program requirements for eCR, meaning benefits to public health would not come at an additional cost to health care providers who are already required to report.
• Streamlines reporting to multiple jurisdictions.
Benefits of certification criterion update:
• Adoption of standards for eCR will improve consistency and interoperability over time.
• Consistency in the reporting of specific data elements will increase the efficiency of exchange (
• RCTC value set establishes a baseline for use in the Program and enables health IT developers of certified health IT to support newer or updated versions of RCTC value sets as soon as new releases are available.
We propose, in section III.C.5 of this preamble, a new certification criterion for “
Without such a certification criterion we are concerned that limited and asymmetric information will lead to the use of inaccurate, harmful, and biased models, and current evidence indicates that such undesirable use is already occurring widely.
We considered several alternative regulatory approaches but believe this approach implies the lowest burden of available options while having a high likelihood of impacting decision-making. Because we seek to address a market failure related to inadequate and asymmetric information, we propose an informational intervention. The approach is market-oriented and aimed at ensuring that model purchasers and users have sufficient information to select and use models responsibly. We believe that several alternative approaches, such as performance or design standards would imply substantially higher regulatory burden and are inappropriate given the ongoing research and development in this area and uncertainty inherent in predictive model development.
Rather than mandatory reporting, we considered the potential for a voluntary database to which model developers might report information on the quality of their models. However, we are concerned that such a database would achieve relatively low participation because of disincentives for some developers to make the performance of their models public. We believe that the current approach in which we have required reporting of a set of core source attributes that we strongly believe should be available for all models (
Given the national availability of many models, Federal regulation is beneficial to set a common set of expectations across the national market.
This section describes the estimated costs of the “Predictive Decision Support” certification criterion. The cost estimates are based on the following assumptions:
•
•
•
We request comment on the estimated number of hours associated with each task. In particular, we request comment on the range of hours associated with Task 4 and Task 5, which we believe will vary greatly depending on the number and types of models that developers include or interface with their products. Estimating the relevant time for these tasks is a challenge because there is limited information regarding the extent to which developers' current practices fall short of the proposed requirements.
We request comment on the estimate included above that 75% of developers of products that are currently certified to § 170.315(a)(9) and will be certified to § 170.315(b)(11) include predictive decision support interventions.
Predictive decision support interventions are common, with some individual interventions being applied to tens or hundreds of millions of individuals despite, in some cases, crucial insufficiencies in the performance of those models.
We believe that the most directly quantifiable benefits of the proposed changes to predictive decision support relate to increased use of more accurate and effective predictive decision support interventions.
Given the sheer number of algorithms and applicable conditions and uses, we have selected two relevant scenarios—sepsis onset and ambulatory care sensitive admission—which have a fair amount of supporting research, to show the potential benefits of our proposal. First, in patient populations in whom the risk of sepsis is moderate to high, risk-assessments based on patient factors and characteristics (
Existing evidence indicates that more advanced predictive models can provide substantial performance improvements over simpler, widely used models.
Transparency has the potential to shed light on the variation in performance across models and to drive uptake of higher performing models. A systematic review of predictive models designed to detect early onset of sepsis found that published evaluations demonstrated sensitivities ranging from 64% to 98%.
Makam, Anil N., Oanh K. Nguyen, and Andrew D. Auerbach. “Diagnostic accuracy and effectiveness of automated electronic sepsis alert systems: a systematic review.”
Given the heterogeneity in the literature, it is challenging to estimate the extent to which the availability of information that would be facilitated by our proposal would impact the average quality of predictive models used or how that average quality will evolve over time. Because models often perform less effectively in real-world implementation than in test environments, we believe the likely impact would be smaller than that implied by the literature but believe an impact on the average sensitivity of models used of 5 percentage points is reasonable. We note that in the cited systematic review, the median sensitivity of included models was 81% so that our assumption is that with the rule in place median sensitivity of available models would increase by 5 percentage points to 86%. Based on cost savings indicated in the available literature, we estimate that early detection of onset would result in cost savings of 50% for the incrementally more commonly detected patient event. We request comment on these estimates.
Beyond increases in the accuracy and effectiveness of models used, it is also challenging to estimate the extent to which the proposed certification criterion would result in increased use of more accurate decision support interventions. Findings on other transparency related public policies, such as nutrition labels, indicate that use of labels can have substantial impacts on consumers choices.
Another example we wish to highlight besides sepsis is the use of models to identify patients at risk for ambulatory sensitive conditions. Such conditions result in costs of $33.7 billion (bn) per year.
Seung Eun Yi, et al.,
We estimate all benefits on a 10-year time horizon. Because health IT
We examined the sensitivity of our estimated benefits based on uncertainty in the underlying rates. We varied two rates: the average increase in the sensitivity of models used and the increased rate at which more accurate models were used. Specifically, we recalculated benefits with an assumed sensitivity increase of 2.5%, 5% or 10% (with 5% representing our primary estimate) and an assumed increase in application of models of 1%, 2% and 3% (with 2% representing our primary estimate). In these analyses, we estimated that the 10-year undiscounted incremental impacts ranged from $259,650,000 to $3,115,800,000. We also estimated the annualized benefits of the incremental impacts using alternative modeling assumptions and present them in Table 20.
We have highlighted one condition and one event that would benefit from the more widespread use of more accurate predictive models under the proposed rule. There are numerous other conditions and events in which increased sensitivity could offer substantial cost savings. However, given uncertainty in the estimates around the included estimates, and important differences across various conditions and the extent to which predictive
We invite public comment on the extent to which these two use cases might relate to other use cases. We further invite public comment on additional benefits for which commenters believe there is an existing literature suitable to estimate potential benefits.
In addition to benefits associated with more sensitive models, we believe that there are numerous other potential benefits related to the more widespread use of more accurate predictive decisions support. However, many of the benefits associated with greater accuracy, and in particular more specific models, such as reduced inappropriate treatment or reduced burdens on providers are difficult to quantify and have, to date, been targeted by fewer predictive models. As salient examples, we note that false-positives for screening for breast cancer alone is associated with $4 bn per year and that more specific interventions could reduce the rates of false positive.
Beyond the benefits associated with greater use of accurate models, we believe there would be several other important benefits associated with the proposed transparency requirements. We believe that increased transparency into the intended use of models would increase the appropriate use of models. There is concern that models will be applied to populations, contexts or decisions for which they are not well suited to provide accurate information.
We believe increased transparency into models and practices would result in the selection and use of fairer models. Biased models are likely to deprioritize treatment for certain groups while also being more likely to recommend inappropriate treatment for those groups resulting in limited benefit and potential harm to some groups relative to those for whom models perform well. Greater transparency into the fairness of models would enable model users to select fairer models and reward producers of fairer models. This would lead to the selection of models that further rather than hinder the equitable delivery of healthcare to groups that have been marginalized. We request comment on the feasibility of quantitating benefits associated with increased model fairness, which may be identifiable through increased benefits to groups that have been marginalized.
We believe that increased transparency would lead to a better functioning market for predictive models that adequately incentivizes and rewards high quality models. In the current state, model developers have an information advantage relative to consumers, and consumers of models act under considerable uncertainty regarding the quality of the product they are acquiring. This market dynamic can lead to harmful choices by consumers and inadequate reward for high quality developers, potentially leading to a feedback loop through adverse selection that encourages market exit by high quality, high-cost model developers. However, adequately characterizing the benefits of a higher information market to the overall quality of models developed and sold is not feasible.
We request comment on approaches or additional data that would enhance the precision of our estimates of benefits, refine assumptions made related to benefits from more accurate models, and that would allow for quantitative reporting of benefits that we have described in a qualitative manner.
We propose in section III.C.6 of this preamble to remove the current named specification for clock synchronization, which is Network Time Protocol (NTP v4 of RFC 5905), in 45 CFR 170.210(g). However, we propose to maintain an expectation that Health IT Modules certified to applicable certification criteria continue to utilize any network time protocol (NTP) standard that can ensure a system clock has been synchronized and meets the time accuracy requirements as defined in the applicable certification criteria in § 170.315(d)(2), § 170.315(d)(3), § 170.315(d)(10), and § 170.315(e)(1).
This proposal is not intended to place additional burden on health IT developers as it does not require new development or implementation. Rather, a health IT developer's costs would be de minimis because we are providing flexibility to allow health IT developers to use any network time protocol standard that exists. We welcome comments on these expectations.
We believe leveraging existing network time protocol standards and not requiring a specific standard allows for more flexibility. We have heard from health IT developers that the current required functionality is in place but not fully used. This proposal allows for additional flexibility to meet the time accuracy requirements as defined in applicable certification criteria. For example, under this proposal, Microsoft-based certified health IT using Operating System to synchronize network time, may use Microsoft's version of Network Time Protocol (MS NTP) as an alternative to Network Time Protocol Version 4 (NTP v4) of RFC 5905 as specified in § 170.210(g), and must meet the time accuracy requirement as defined in the certification criteria. We welcome comments regarding potential approaches for quantifying these benefits.
As discussed in section III.C.7 of this preamble, we propose to update the certification criterion, “
We also propose to revise the requirement in § 170.315(g)(10)(vi) to specify that Health IT Modules presented for certification that allow short-lived access tokens to expire, in lieu of immediate access token revocation, must be able to revoke an authorized application's access at a
Additionally, we propose to amend the API Condition and Maintenance of Certification requirements by adding the requirement that Certified API Developers with patient-facing APIs must publish their service base URLs for all customers regardless of whether the certified Health IT Modules are centrally managed by the Certified API Developer or locally deployed by an API Information Source. We propose that these service base URLs must conform to a specific data format.
Finally, we propose to adopt the FHIR US Core Implementation Guide version 5.0.1 in § 170.215(b)(1)(ii). However, based on the annual US Core release cycle, we believe US Core IG v6.0.0 will be published before ONC issues a final rule. Therefore, it is our intent to consider adopting the updated US Core IG v6.0.0 that supports the data elements and data classes in USCDI v3 since we propose to adopt USCDI v3 in this rule. Health IT systems that adopt this version of US Core can provide the latest consensus-based capabilities for providing access to USCDI data classes and elements using a FHIR API.
We have estimated the proposed cost to health IT developers to make these updates. These estimates are detailed in Table 23 below and are based on the following assumptions:
•
•
•
The cost to a health IT developer to update the
We believe this proposal would benefit health care providers, patients, and the industry as a whole. The adoption of the US Core 5.0.1 IG would, with the additional data elements in USCDI v3, expand the baseline set of data available and provide more comprehensive health data for both providers and patients. Updates to the SMART App Launch Framework IG 2.0 would align the certified API functionality with current adopted standards-based methods to connect patients' health information to the app of their choice. Furthermore, updated requirements to the service-base URL publication API maintenance of certification requirement would provide a standard format for all published FHIR endpoints to be securely discovered and consumed by authorized applications. The standard publication format will reduce the burden on patients, app developers, and other third parties to find and connect to the appropriate FHIR endpoint to initiate data access. This would directly benefit the speed and efficiency of making these connections and reduce the level of effort on third parties to access and use these standards-based APIs.
We expect the resulting improvements to interoperable exchange of health information to significantly benefit providers and patients and improve the quality of healthcare provided. In the ONC Cures Act Final Rule (85 FR 25925), we estimated the total annual benefit of APIs, on average, to range from $0.34 billion to $1.43 billion. These proposed updates to the criterion ensure the benefits of APIs are maintained and the annual benefit due to improved health outcomes and patients having access to their online medical record is realized.
As described in previously, there are additional potential future benefits to the expanded availability of an interoperable API for patient and population services that are not quantifiable at this time. For some use cases there is a clear indication of future technical direction, but at this time, there is insufficient implementation to clearly quantify the scope. For example, CMS has identified an intent to leverage APIs for population services to modernize quality measurement and quality reporting under value-based payment programs.
As discussed in section III.C.8 of this preamble, we propose to rename the “
The proposed modifications to the “Patient Demographics and Observations” criterion would provide greater clarity and standardization to how a patient's sexual orientation and gender identity are recorded electronically in the electronic health record. The USCDI v3 standard includes new data elements for Sexual Orientation and Gender Identity. These data elements are required to be included as part of a patient's electronic health information and included in any record shared with the patient, the patient's caregiver, or health care provider.
The proposed modifications to the “Patient Demographics and Observations” criterion include 6 tasks: (1) Modify Sex, (2) Modify Sexual Orientation, (3) Modify Gender Identity, (4) Add Sex for Clinical Use, (5) Add Pronouns, and (6) Add Name to Use. These tasks have their own level of effort, and these estimates are detailed in Table 24 below and are based on the following assumptions:
1. Health IT developers will use the same labor costs and data models. Table 24 shows the estimated labor costs per product to modify the “Patient Demographics and Observations”
2. We estimate that 321 products certified by 261 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.
The estimate of 321 products certified by 261 developers is derived as follows. We estimate that, in total, 368 health IT developers would certify 502 health IT products impacted by this rulemaking. However, not all these developers and products certify the “Patient Demographics and Observations” criterion and need to meet the proposed requirements. As of the end of 2021, 71% of developers and 64% of products certified to the criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the proposed modifications to the criterion.
3. According to the May 2021 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $58.17. As noted previously, we have assumed that other indirect costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including other indirect costs is $116.
The cost to a health IT developer to make the proposed modifications to the “Patient Demographics and Observations” criterion for their certified Health IT Modules would range from $83,520 to $215,760 per product, on average. Therefore, assuming 321 products overall and a labor rate of $116 per hour, we estimate that the total cost to all health IT developers would, on average, range from $27 million to $69 million. This would be a one-time cost to developers per product that is certified to the specified certification criterion.
Improved recording of sexual orientation and gender identity in the medical record has multiple benefits. This has clinical benefits for patients in the immediate term as information related to gender identity and sexual orientation is critical for informing treatment. Additionally, advances in treatment may result from researchers having more reliable and accurate sexual orientation and gender identity data available. Not only would this benefit clinical care teams who are
The benefits of these modifications are not quantifiable at this time, but we expect the resulting improvements to interoperable exchange of health information to significantly benefit providers and patients and improve the quality of healthcare provided. Furthermore, having a patient's information recorded uniformly and available across their medical records would improve the patient's access to their information and ensure the information is available uniformly across technologies.
As discussed in section III.C.9 of this preamble, we propose to modify the “
1. IT developers will use the same labor costs and data models. Table 27 shows the estimated labor costs per product to modify the transitions of care criterion. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will incur the costs noted in Table 27.
2. We estimate that 281 products certified by 236 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.
The estimate of 281 products certified by 236 developers is derived as follows. We estimate that, in total, 368 health IT developers will certify 502 health IT products impacted by this rulemaking. However, not all these developers and products certify the transitions of care criterion and need to meet the proposed requirements. As of the end of 2021, 64% of developers and 56% of products certified to the transitions of care criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the proposed modifications to the criterion.
3. According to the May 2021 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $58.17. As noted previously, we have assumed that overhead costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including overhead costs is $116.
The cost to a health IT developer to make the proposed modifications to the transitions of care criterion for their certified Health IT Modules would range from $0 to $5,300 per product, on average. Therefore, assuming 281 products overall and a labor rate of $116 per hour, we estimate that the total cost to all health IT developers would, on average, range from $0 to $1.5 million. This would be a one-time cost to developers per product that is certified to the specified certification criterion.
There are multiple benefits associated with having more granular information available related to improved recording of sexual orientation and gender identity. This has clinical benefits for patients in the immediate term as information related to gender identity and sexual orientation is critical for informing treatment. Additionally, advances in treatment may result from researchers having more reliable and accurate sexual orientation and gender identity data available. Not only would this benefit clinical care teams who are treating patients within a particular clinical setting, this would improve the interoperability of this data when shared electronically with the patient or the patient's caregiver through the technology of their choosing or when shared electronically with a third-party elected by the patient, such as an application developer, health care provider, or other entity.
The benefits of these modifications are not quantifiable at this time, but we expect the resulting improvements to interoperable exchange of health information to significantly benefit providers and patients and improve the quality of healthcare provided. Furthermore, having a patient's information recorded uniformly and available across their medical records would improve the patient's access to their information and ensure the information is available uniformly across technologies.
As discussed in section III.C.10 of this preamble, we propose to adopt a new certification criterion in § 170.315(d)(14), to update the existing criterion in § 170.315(e)(1), and to add references for these criteria into the Privacy and Security Framework in § 170.550(h). These proposals are standards agnostic for the
In section III.C.10.b, we discuss a series of alternate proposals related to the primary proposals described for a new certification criterion in § 170.315(d)(14) and to update the existing criterion in § 170.315(e)(1). These alternate proposals would add standards and implementation specifications for the purposes of specifying security labels and related applicable actions to restrict the use or disclosure of EHI. We believe these options may address concerns associated with these criteria as described in our primary proposal. However, we do not believe it is appropriate to propose these options as the primary proposal, as the scope of the current specifications is beyond the core goal of the proposed functionality and additional constraints may be preferable to health IT developers and users. We further considered additional alternatives, such as proposing only a patient-directed workflow, but such an approach would be inadequate to address the needs of the responsible covered entity under the HIPAA Privacy Rules because it would not include capabilities for the covered entity to review the patient request and implement appropriate privacy workflows.
It is difficult to estimate or quantify the burden of this proposal because data segmentation for privacy is not widely implemented and has not generally been implemented for this use case. Specifically, while there are standards for security labels for document-based exchange, which ONC adopted in full in 2020 for the criteria in § 170.315(b)(7) and (b)(8), there are not standards which define the technical requirements for the actions described by the security label vocabularies. In other words, the standards exist to describe the policy and action that should be accomplished by a Health IT Module, but not how that action is implemented.
For these reasons, in our proposal, we did not specify how, or at what level of granularity that segmentation must occur. There is also not general industry consensus on what approach will be most cost-effective or how many types of actions would represent the minimum set. This means that in our proposal, we were also unable to define one specific option—or set of options—as a required or a minimum set of actions.
In the ONC Cures Act Final Rule, we estimated a cost of the certification criteria and standards adopted for security labels in § 170.315(b)(7) and (b)(8). We estimated developers would need 400 to 600 hours per criterion to make upgrades on systems that had previously been certified to a prior version of the criteria, or 720 to 1220 hours per criterion for systems that are implementing these criteria for the first time. We estimated the total cost to developers could range from $2,910,400 to $6,933,600. We noted that this would be a one-time cost (85 FR 25926). While this may be perceived to provide some context for an estimate of the scope of these standards if applied under our alternate proposal, these estimates are not readily applicable to the new criterion proposed in § 170.315(d)(14). Not only are the existing criteria lacking the implementation of technical specifications as described, the scope of the HL7 CDA DS4P IG referenced for the criteria in § 170.315(b)(7) and (b)(8) includes a wide range of additional use cases beyond the patient right to request a restriction under HIPAA Privacy Rules. In the ONC Cures Act Final Rule, we specifically noted our intent in adopting these voluntary certification criteria was to support known high priority use cases defined by state and federal privacy laws for specific privacy constraints for pediatric care and opioid use and substance disorder, including actions related to 42 CFR part 2 restrictions. We note that even in comparison to these high-priority and highly complex use cases, data segmentation workflows supporting patient preferences for data sharing are particularly challenging because of the significant range of potential variables based not only on the types of data but also on applicable law.
In section III.C.10.a, we specifically request public comment to assist in defining the scope of development and helping ONC better understand the potential cost of implementation. Specifically, we seek comment on clear methods by which we might quantify the development burden and costs for the new criterion in § 170.315(d)(14), the new functionality in the existing criterion in § 170.315(e)(1), and the addition to the Privacy and Security Framework in § 170.550(h). In our alternate proposals and request for information in section III.C.10.b and c, we seek comment on clear methods by which we might quantify the development burden and costs that could be associated with a standards-based approach as compared to adopting only a functional requirement. Finally, we seek comment on clear methods by which we might quantify the development burden and costs for this proposed alternative to constrain the USCDI referenced in the new proposed criterion in § 170.315(d)(14) and the proposed revisions to the existing criterion in § 170.315(e)(1).
In the ONC Cures Act Final Rule, we noted that the updated criteria in § 170.315(b)(7) and (b)(8) (Security tags—Summary of Care—send and Security tags—Summary of Care—receive) would benefit providers, patients, and ONC because it would support more complete records, contribute to patient safety, and enhance care coordination. We stated that implementing security tags enables providers to more effectively share patient records with sensitive information, thereby protecting patient privacy while still delivering actionable clinical content. We emphasized that health care providers already have processes and workflows to address their existing compliance obligations, which could be made more efficient and cost effective through the use of health IT. We were, however, unable to quantify these benefits at the time because we did not have adequate information to support quantitative estimates (85 FR 25927).
Since we issued the ONC Cures Act Final Rule, the number of developers certified to the voluntary criteria in § 170.315(b)(7) and (b)(8) has increased, but it remains a small percentage of the total products certified. While we believe there would be similar benefits to patients and other covered entities from our proposals in this rule to support privacy workflows, we similarly are limited in our ability to estimate such impact at this time.
As discussed in section III.F of this preamble, the “
Section 4002(c) of the Cures Act requires the creation of an Electronic Health Record (EHR) Reporting Program. We have chosen to implement the developer reporting through ONC's Health IT Certification Program to integrate this legislative mandate with other reporting requirements for health IT developers of certified health IT as a Condition and Maintenance of Certification requirement. This approach is aligned with how we have interpreted other similar provisions of the Cures Act, and it is intended to maximize participation among health IT developers of certified health IT while aligning participation with other requirements of the Program. Other alternatives to implementing this provision of the Cures Act could be to conduct a survey of health IT developers of certified health IT to report on measures; however, such an effort would reflect only those developers who participated in the survey, thus limiting the generalizability of the results. A survey approach would also complicate ONC's ability to standardize developer results reporting and thus the quality and the rigor of the data would be affected. Thus, in order to be consistent with ONC's implementation of other Cures Act condition and maintenance of certification requirements, to maximize the generalizability and accuracy of the data gathered through this effort, and to align it with other activities, we have chosen to implement the condition through ONC's Health IT Certification Program.
In calculating the cost of reporting each measure
The
The
For each measure, the estimated the number of health IT developers of certified health IT depended on whether developers' products certified to criteria associated with a particular measure (as shown in Table 29) and whether they meet the threshold requirement for a small developer. We note that given that both § 170.315(b)(10) and § 170.315(g)(10) won't be required until after the publication of this NPRM, § 170.315(b)(6) and § 170.315(g)(8), respectively, were used as proxies for the purposes of determining the threshold and related calculations, where the newer criteria were not yet certified to. We assumed developers who have certified to § 170.315(b)(6) and § 170.315(g)(8) shall also certify to § 170.315(b)(10) and § 170.315(g)(10), respectively.
We decided the small developer thresholds based upon analyses we conducted of the 2019 CMS PI Program and Certified Health IT Product List. We examined the various alternatives for setting user thresholds based on the percentage of users and developers that would be represented and reporting measures, respectively in the Program (
In calculating the aggregate cost of developing all measures we applied the concept of economies of scope, where the total cost of production is not incrementally increasing in the number of measures, but it is rather attenuating. Specifically, the aggregate cost in this application is governed by the following expression: The total cost (TC) of producing measures 1 and 2 is the sum of producing the two measures separately minus the cost of producing them together.
To calculate the cost of producing measures together, health IT developers of certified health IT were asked during discussions to provide an estimate on the extent to which there would be an overlap in developing infrastructure between the measures published by the Urban Institute and level of difficulty by measure.
Additionally, we assumed that there will be a 10% overlap of developing infrastructure across all measures. We applied these rates accordingly when calculating the total cost of developing measures for the Insights Condition.
Following this approach, the aggregate cost estimates are presented by different alternatives associated with thresholds in Table 32. The first row shows the total cost assuming developers have at least 50 hospital or 500 clinician users, which generates the cost between $103 and $218 million. In addition to estimating the costs associated with the 50 hospitals or 500 clinician user thresholds, we also present the cost for two alternatives where the number of users for hospitals is 100 and for clinicians ranges from 1000 to 2000. The total cost would be reduced by about a half compared to the previous specification because smaller number of developers would qualify for the program.
In Table 29, we present the estimated number of labor hours to develop and report by measure for each individual developer. This table served as the basis for the cost estimates, prior to adjusting as described above.
In Table 33, we present cost estimates for each individual measure by developer and across all developers. The measures vary in cost because we made adjustments based on synergies discussed above (
The ONC Cures Act Final Rule seeks to advance interoperability and support the access, exchange, and use of electronic health information. There is currently limited transparency and information regarding interoperability; this not only stymies informed decision-making by ONC but also others in the industry, including health care providers, and entities that enable exchange, including various types of health information networks and health app developers. ONC's measurement of interoperability is currently reliant primarily on self-reported survey data from end users of health information technology. While this information does provide some insights on interoperability from end-user perspectives, the insights derived are limited. The proposed measures will provide system-generated metrics on interoperability that will complement self-reported, user perspective data sources, such as surveys. Through the Insights Condition section of this proposed rule, we have identified where surveys have been limited in providing a clear picture of certain aspects of interoperability that these measures will elucidate. In addition, they will reach a greater number of health care providers than surveys, giving a more complete and representative national perspective. Greater transparency and information on interoperability of health IT products has the potential to benefit a number of interested parties, including ONC and other entities that enable exchange, including health app developers and health information networks. The proposed measures are also designed to identify areas that are working well and problems that we can monitor over time. This will help identify the need for technical and policy solutions as well as spur innovation that builds on successes and addresses gaps. While we currently do not have a means to quantify these benefits, we welcome any feedback on methods to better quantify the impact these measures can have for healthcare and health IT.
The proposed rule's measures for the Insights Condition would help improve and inform ONC programmatic and regulatory decision-making. ONC's programs and policies are designed to make direct and positive impacts on health IT use, care delivery, and patient health. ONC does this primarily through supporting standards development and the Program. The proposed measures would help ONC and others better understand the use, progress, and value of health IT standards. This has practical implications for improving the work ONC leads that increases the use of standards. For example, ONC has limited empirical information to provide guidance on the usage of standards associated with the Interoperability Standards Advisory. With the addition of the proposed measures, ONC can provide guidance to industry that is grounded in data from health IT developers rather than anecdotes. This has the potential to move industry to adopt standards more quickly, which has downstream impacts on improved interoperability. In addition, the proposed measures will increase transparency regarding the capability and usage of certified products. Through these measures ONC and other interested parties will be able to identify areas that are problematic and in need of further investigation, such as cross-cutting policy and technical issues. They will also provide needed data to develop solutions to these complex problems.
The proposed measures from the Insights Condition will focus on four key priority areas: individual access to electronic health information, clinical care information exchange, standards adoption and conformance, and public health information exchange. Under the individual access to electronic health information domain, the measures will inform on the ONC Cures Act Final Rule goal of increasing access of electronic health information to individuals, particularly through the use of third-party apps. Increased patient engagement has been associated with improved health outcomes, and improved ease of access to their own medical records can improve patient engagement.
The clinical care information exchange measures will help ONC and other interested parties better understand the effectiveness of current C-CDA document exchange mechanisms. By collecting data on the volume of exchange by patient encounters by exchange mechanism, ONC will be able to use that information to inform key policies that support exchange and interoperability, such as TEFCA, which seeks to facilitate exchange between transport mechanisms, such as health information networks. Understanding the volume of exchange flowing through these mechanisms will provide entities enabling exchange, in addition to ONC, with information on which mechanisms are the most frequently and least frequently used. Understand the rates of C-CDA document incorporation is valuable for interested parties supporting C-CDA document exchange (
Currently, ONC has limited data on the use of Certified API Technology in the app market. The ONC Cures Act Final Rule established the rules for the use of Certified API Technology in such a way to increase access to health information for both patients and health care providers. By understanding which apps are using FHIR-based APIs and the volume of transfer of FHIR resources, ONC and standards development organizations (SDOs) will be able to prioritize their work toward high use
The ONC Cures Act Final Rule also introduced certification criteria and policies for the exchange of bulk patient health information. The goal of these functionalities is to make patient data requests easier and less expensive as well as allowing health care providers a greater choice of health IT applications. Understanding how these functionalities are being used will allow ONC and others to assess the progress toward those goals and identify where there may be areas in need of refinement. It will provide interested parties, such as accountable care organizations (ACO), researchers, and others with interest in secondary use of certified health IT data with insights as to whether such data is easily moved out of health IT products to support a variety of use cases to advance patient care.
Finally, because of the COVID-19 epidemic, there has been increased attention on the capabilities of health care providers to share public health information with public health agencies (PHA).
We propose in section IV of this preamble several enhancements with respect to the information blocking provisions in the ONC Cures Act Final Rule. These include defining in regulation text what it means, and what it does not mean, to “offer” health IT. The enhancements also include updating the Infeasibility (45 CFR 171.204) and Manner (45 CFR 171.301, formerly known as the “Content and Manner”) Exceptions for clarity and to add more ways for actors' practices to satisfy these exceptions and thus not be considered “information blocking” for purposes of 45 CFR part 171.
We expect ONC to incur an annual cost for issuing educational resources related to the proposed information blocking enhancements. We estimate that ONC would issue educational resources each quarter, or at least four times per year. We assume that the resources would be provided by ONC staff with the expertise of a GS-15, Step 1 federal employee(s). The hourly wage with benefits for a GS-15, Step 1 employee located in Washington, DC is approximately $155.
Currently, ONC has limited data and research available to reasonably estimate the benefits of how often an actor may avail itself of one of the permitted exceptions or the costs for an actor to meet a condition to an exception.
We anticipate that the proposed information blocking enhancements will enable actors to determine more easily and with greater certainty whether their practices (acts or omissions) that may or do interfere with access, exchange, or use of EHI (as defined in 45 CFR 171.102) meet the conditions to be considered a “reasonable and necessary” activity under an information blocking exception. As such, we expect these proposals will further ease the burden and costs of complying with the information blocking regulations, while providing increased predictability. This predictability will permit regulated entities to more effectively plan and invest resources in developing and using interoperable technologies and services to improve healthcare efficiency and value. Additionally, we anticipate as a result of the proposed revised definitions and exceptions, there will be reduced interference with the access, exchange, and use of electronic health information because of the added clarity the proposals will provide the market regarding certain practices. Thus, we anticipate an increase in the overall benefits derived from reducing the prevalence of information blocking. We welcome comment on these conclusions and the supporting rationale.
We estimate that the total annual cost for this proposed rule for the first year after it is finalized (including one-time costs), based on the cost estimates outlined above and throughout this RIA, would result in $742 million. The total undiscounted perpetual cost over a 10-year period for this proposed rule (starting in year three), based on the cost estimates outlined above, would result in $712 million. We estimate the total costs to health IT developers to be $742 million while the government (ONC) costs to be between $62,000 to $124,000.
We estimate the total annual benefit for this proposed rule, based on the benefit estimates outlined above, would be on average $1.0 billion.
We estimate the total undiscounted perpetual annual net benefit for this proposed rule (starting in year three), based on the estimates outlined above, would result in a net benefit of $326 million.
When a rule is considered an economically significant rule under Executive Order 12866, we are required to develop an accounting statement indicating the classification of the expenditures associated with the provisions of the proposed rule. Monetary annual effects are presented as discounted flows using 3% and 7% factors in Table 35 below. We are not able to explicitly define the universe of all costs but have provided an average of likely costs of this proposed rule as
The Regulatory Flexibility Act (RFA) requires agencies to analyze options for regulatory relief of small businesses if a rule has a significant impact on a substantial number of small entities. The Small Business Administration (SBA) establishes the size of small businesses for Federal Government programs based on average annual receipts or the average employment of a firm.
While health IT developers that pursue certification of their health IT under the Program represent a small segment of the overall information technology industry, we believe that many health IT developers impacted by the requirements proposed in this proposed rule most likely fall under the North American Industry Classification System (NAICS) code 541511 “Custom Computer Programming Services.”
We estimate that the proposed requirements in this proposed rule would have effects on health IT developers, some of which may be small entities, that have certified health IT or are likely to pursue certification of their health IT under the Program. We believe, however, that we have proposed the minimum amount of requirements necessary to accomplish our primary policy goal of enhancing interoperability. Further, as discussed in this RIA above, there are very few appropriate regulatory or non-regulatory alternatives that could be developed to lessen the compliance burden associated with this proposed rule because at least a few of the proposals are derived directly from legislative mandates in the Cures Act.
We do not believe that the proposed requirements of this proposed rule would create a significant impact on a substantial number of small entities, but request comment on whether there are small entities that we have not identified that may be affected in a significant way by this proposed rule. Additionally, the Secretary proposes to certify that this proposed rule would not have a significant impact on a substantial number of small entities.
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 requirement costs on state and local governments, preempts state law, or otherwise has federalism implications. Nothing in this proposed rule imposes substantial direct compliance costs on state and local governments, preempts state law, or otherwise has federalism implications. We are not aware of any state laws or regulations that are contradicted or impeded by any of the proposals in this proposed rule. We welcome comments on this assessment.
Section 202 of the Unfunded Mandates Reform Act of 1995 requires that agencies assess anticipated costs and benefits before issuing any rule that imposes unfunded mandates on state, local, and tribal governments or the private sector requiring spending in any one year of $100 million in 1995 dollars, updated annually for inflation. The current inflation-adjusted statutory threshold is approximately $165 million in 2022. While the estimated potential cost effects of this proposed rule reach the statutory threshold, we do not believe this proposed rule imposes unfunded mandates on state, local, and tribal governments, or the private sector. We welcome comments on these conclusions.
OMB reviewed this proposed rule.
Computer technology, Electronic health record, Electronic information system, Electronic transactions, Health, Healthcare, Health information technology, Health insurance, Health records, Hospitals, Incorporation by reference, Laboratories, Medicaid, Medicare, Privacy, Reporting and record keeping requirements, Public health, Security.
Computer technology, Electronic health record, Electronic information system, Electronic transactions, Health, Healthcare, Health care provider, Health information exchange, Health information technology, Health information network, Health insurance, Health records, Hospitals, Privacy, Reporting and recordkeeping requirements, Public health, Security.
For the reasons set forth in the preamble HHS proposes to amend, 45 CFR subtitle A, subchapter D, as follows:
42 U.S.C. 300jj-11; 42 U.S.C. 300jj-14; 5 U.S.C. 553.
The additions read as follows:
(1) Includes patient demographic and clinical health information, such as medical history and problem lists;
(2) Has the capacity:
(i) To provide clinical decision support;
(ii) To support physician order entry;
(iii) To capture and query information relevant to health care quality;
(iv) To exchange electronic health information with, and integrate such information from other sources; and
(3) Has been certified to the certification criteria adopted by the Secretary in—
(i) Section 170.315(a)(1), (2), or (3); (a)(5), (a)(14), (b)(1), (c)(1), (g)(7), (9), (10), and (h)(1) or (2);
(ii) Section 170.315(a)(9) or (b)(11) for the period up to and including December 31, 2024; and
(iii) Section 170.315(b)(11) on and after January 1, 2025.
(1) Has added or changed the capabilities described in the existing criterion in 45 CFR part 170;
(2) Has an added or changed standard or implementation specification referenced in the existing criterion in 45 CFR part 170; or
(3) Is specified through notice and comment rulemaking as an iterative or replacement version of an existing criterion in 45 CFR part 170.
The revision and additions read as follows:
(a) * * *
(5)
(6)
(o) * * *
(2)
(t)
(2)
(3)
(4)
The revisions and additions read as follows:
(a) * * *
(1)
(c) * * *
(1)
(d) * * *
(1)
(4)
(e) * * *
(1)
(2)
(f) * * *
(3)
(m) * * *
(1) * * *
(2)
(n) * * *
(1)
(i) Male. M; (ii) Female. F; (iii) Unknown. nullFlavor UNK.
(2)
(3)
(o)
(i)
(ii)
(iii)
(iv)
(v)
(vi)
(2)
(i)
(ii)
(iii)
(iv)
(v)
(vi)
(vii)
(3)
(4)
(p) * * *
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(r) * * *
(2)
(s) * * *
(2)
(g)
The Secretary adopts the following versions of the United States Core Data for Interoperability standard:
(a)
(b)
The Secretary adopts the following standards and associated implementation specifications as the available standards for application programming interfaces (API):
(a)
(1)
(2) [Reserved]
(b)
(1)
(i)
(ii)
(2) [Reserved]
(c)
(1)
(2)
(d)
(1)
(2) [Reserved]
(e)
(1)
(2) [Reserved]
The revisions and additions read as follows:
(a) Certain material is incorporated by reference into this part with the approval of the Director of the Federal Register under 5 U.S.C. 552(a) and 1 CFR part 51. All approved incorporation by reference (IBR) material is available for inspection at the U.S. Department of Health and Human Services (HHS) and at the National Archives and Records Administration (NARA). Contact HHS at: U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW, Washington, DC 20201, call ahead to arrange for inspection at 202-690-7151. For information on the availability of this material at NARA, visit
(d) * * *
(17) HL7 Standard Code Set CVX—Vaccines Administered, updates through June 15, 2022, IBR approved for § 170.207(e).
(18) National Drug Code Directory (NDC)—Vaccine NDC Linker, updates through July 19, 2022, IBR approved for § 170.207(e).
(19) CDC Race and Ethnicity Code Set version 1.2 (July 15, 2021), IBR approved for § 170.207(f).
(e) * * *
(6) Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, October 29, 2021 IBR approved for § 170.207(r).
(f) Council of State and Territorial Epidemiologists, 2635 Century Parkway NE, Suite 700, Atlanta, GA 30345, 770-458-3811,
(1) Reportable Conditions Trigger Codes Value Set for Electronic Case Reporting. RCTC OID: 2.16.840.1.114222.4.11.7508, Release March 29, 2022, IBR approved for § 170.205(t).
(2) [Reserved]
(g) * * *
(35) HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 3—US Realm, May 12, 2022, IBR approved for § 170.205(a).
(36) HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR)—US Realm 2.1.0—STU 2 US (HL7 FHIR eCR IG), August 31, 2022. IBR approved for § 170.205(t).
(37) HL7 CDA® R2 Implementation Guide: Public Health Case Report—the Electronic Initial Case Report (eICR) Release 2, STU Release 3.1—US Realm (HL7 CDA eICR IG), July 20, 2022, IBR approved for § 170.205(t).
(38) HL7 CDA® R2 Implementation Guide: Reportability Response, Release 1, STU Release 1.1—US Realm (HL7 CDA RR IG), July 17, 2022, IBR approved for § 170.205(t).
(39) HL7 FHIR® US Core Implementation Guide STU 5.0.1, June 13, 2022, IBR approved for § 170.215(b).
(40) HL7 FHIR® SMART Application Launch Framework Implementation Guide, Release 2.0.0, November 26, 2021, IBR approved for § 170.215(c).
(41) HL7 FHIR® Data Segmentation for Privacy Implementation Guide: Version 1.0.0—current—ci-build, December 1, 2022, IBR approved for § 170.205(o).
(n) * * *
(6) United States Core Data for Interoperability (USCDI), October 2022 Errata, Version 3 (v3) IBR approved for § 170.213(b).
(p) * * *
(2) Public Health Data Standards Consortium Source of Payment Typology Code Set, Version 9.2 (December 2020), IBR approved for § 170.207(s).
(q) * * *
(5) Logical Observation Identifiers Names and Codes (LOINC®) Database Version 2.72, February 16, 2022, IBR approved for § 170.207(c).
(6) The Unified Code of Units of Measure, Revision 2.1, November 21, 2017, IBR approved for § 170.207(m).
(s) * * *
(8) International Health Terminology Standards Development Organization (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, Release March 2022, IBR approved for § 170.207(a).
(9) RxNorm, July 5, 2022, Release, IBR approved for § 170.207(d).
The revisions and additions read as follows:
The Secretary adopts the following certification criteria for health IT. Health IT must be able to electronically perform the following capabilities in accordance with applicable standards and implementation specifications adopted in this part. For all criteria in this section, a health IT developer with a Health IT Module certified to any revised certification criterion, as defined in § 170.102, shall update the Health IT Module and shall provide such update to their customers in accordance with the dates identified for each revised certification criterion and for each applicable standard in 45 CFR part 170 subpart B.
(a) * * *
(5)
(A) * * *
(
(
(C)
(D)
(E)
(F)
(G)
(H)
(9) * * *
(vi)
(12)
(b) * * *
(1) * * *
(iii) * * *
(A) * * *
(
(
(B) * * *
(
(G)
(
(2) * * *
(i)
(ii)
(iii) * * *
(D) Upon a user's confirmation, automatically update the list, and incorporate the following data expressed according to the specified standards:
(iv)
(6) * * *
(ii) * * *
(B) * * *
(
(9) * * *
(ii) The standard in § 170.205(a)(5) for the time period up to and including December 31, 2024; or § 170.205(a)(6).
(11)
(ii)
(B) Enable interventions:
(
(
(
(
(
(
(
(
(
(
(C) Enable end users to provide electronic feedback data based on information displayed through the intervention and make available such feedback data for export, in a computable format, including but not limited to the intervention, action taken, user feedback provided (if applicable), user, date, and location.
(iii)
(iv)
(
(
(B) For paragraph (b)(11)(iv)(A) of this section, technology must be able to identify for a user diagnostic or therapeutic reference information based on each one and at least one combination of the data referenced in paragraphs (b)(11)(ii)(B)(
(v)
(A) Yes—the Health IT Module enables or interfaces with one or more predictive decision support interventions as defined in § 170.102 based on any of the data expressed in the standards in § 170.213.
(B) No—the Health IT Module does not enable or interface with one or more predictive decision support interventions as defined in § 170.102 based on any of the data expressed in the standards in § 170.213.
(vi)
(A) For evidence-based decision support interventions under paragraph (b)(11)(iii) of this section:
(
(
(
(
(
(
(
(B) For linked referential DSI in paragraph (b)(11)(iv) of this section and drug-drug, drug-allergy interaction checks in paragraph (a)(4) of this section, the developer of the intervention, and where clinically indicated, the bibliographic citation of the intervention (clinical research or guideline).
(C) For Health IT Modules that enable or interface with one or more predictive decision support interventions, as described in paragraph (b)(11)(v)(A) of this section, source attributes in paragraph (b)(11)(vi)(A) of this section and the following:
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(D) A Health IT Module must clearly indicate when a source attribute listed in paragraphs (b)(11)(vi)(A), (B), or (C) of this section, as applicable, is not available for the user to review, including when:
(
(
(E) Enable a limited set of identified users to author and revise source attributes and information beyond source attributes listed in paragraphs (b)(11)(vi)(A) and (b)(11)(vi)(C) of this section, as applicable.
(vii)
(A) Employ or engage in the following intervention risk management practices for all predictive decision support interventions, as defined in § 170.102, that the Health IT Module enables or interfaces with:
(
(
(
(B) Compile detailed documentation regarding the intervention risk management practices listed in paragraph (b)(11)(vii)(A) of this section and upon request from ONC, make available such detailed documentation for any predictive decision support intervention, as defined in § 170.102, that the Health IT Module enables or interfaces with.
(C) Submit summary information of the intervention risk management practices listed in paragraph (b)(11)(vii)(A) of this section to its ONC-ACB via publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps.
(D) Review annually and, as necessary, update documentation described in paragraphs (b)(11)(vii)(B) and (b)(11)(vii)(C) of this section.
(c) * * *
(4) * * *
(iii) * * *
(C) Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(2).
(E) Patient insurance in accordance with the standard specified in § 170.207(s)(2).
(G) Patient sex in accordance with the version of the standard specified in § 170.207(n)(2).
(H) Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(3).
(I) Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(1).
(d) * * *
(14) Patient requested restrictions.
(i) For any data expressed in the standards in § 170.213, enable a user to flag whether such data needs to be restricted from being subsequently used or disclosed as set forth in 45 CFR 164.522; and
(ii) Prevent any data flagged pursuant to paragraph (d)(14)(i) of this section from being included in a use or disclosure.
(e) * * *
(1) * * *
(i) * * *
(A) * * *
(
(
(B) * * *
(
(
(
(
(iii)
(f) * * *
(1) * * *
(i) * * *
(B) At a minimum, the version of the standard specified in § 170.207(e)(1) for historical vaccines.
(C) At a minimum, the version of the standard specified in § 170.207(e)(2) for administered vaccines.
(3) * * *
(ii) At a minimum, the versions of the standards specified in § 170.207(a)(1) and (c)(1).
(4) * * *
(ii) At a minimum, the versions of the standards specified in § 170.207(a)(1) and (c)(1).
(5)
(A) Consume and maintain a table of trigger codes to determine which encounters may be reportable.
(B) Match a patient visit or encounter to the trigger code based on the parameters of the trigger code table.
(C) Create a case report for electronic transmission based on a matched trigger from paragraph (f)(5)(i)(B) of this section and including at a minimum:
(
(
(
(
(ii) Enable a user to create a case report for electronic transmission in accordance with the following:
(A) Consume and process electronic case reporting trigger codes and parameters and identify a reportable patient visit or encounter based on a match from the Reportable Conditions Trigger Code value set in § 170.205(t)(4) received from the eRSD profiles as specified in the HL7 FHIR eCR IG in § 170.205(t)(1).
(B) Create a case report consistent with at least one of the following standards:
(
(
(C) Receive, consume, and process a case report response that is formatted to either the reportability response profile of the HL7 FHIR eCR IG in § 170.205(t)(1) or the HL7 CDA RR IG in § 170.205(t)(3).
(D) Transmit a case report electronically to a system capable of receiving an electronic case report.
(g) * * *
(3) Safety-enhanced design. User-centered design processes must be applied to each capability technology includes that is specified in the following certification criteria: paragraphs (a)(1) through (5), (9), and (14), and (b)(2), (3), and (11) of this section.
(6) * * *
(i) * * *
(A) The data classes expressed in the standards in § 170.213 in accordance with § 170.205(a)(4) and (a)(5) and paragraphs (g)(6)(i)(C)(
(B) The data classes expressed in the standards in § 170.213, and in accordance with § 170.205(a)(4) and (6) and paragraphs (g)(6)(i)(C)(
(9) * * *
(i) * * *
(A) * * *
(
(
(10) * * *
(i) * * *
(A) Respond to requests for a single patient's data according to the standards and implementation specifications adopted in 170.215(a) and in § 170.215(b)(1), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standards adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported.
(B) Respond to requests for multiple patients' data as a group according to the standards and implementation specifications adopted in § 170.215(a), (b)(1), and (d), for each of the data included in the standards adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported.
(ii) * * *
(A) Respond to search requests for a single patient's data consistent with the search criteria included in the implementation specifications adopted in § 170.215(b)(1), specifically the mandatory capabilities described in “US Core Server CapabilityStatement.”
(iv) * * *
(A) Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(b)(1) and (c).
(v) * * *
(A) * * *
(
(
(
(
(vi)
(vii)
(a) * * *
(5) A health IT developer must not inhibit its customer's timely access to interoperable health IT certified under the Program.
(b) * * *
(3)(i)
(ii)
(iii)
(A) By no later than December 31 of the calendar year that falls 24 months after the effective date of the final rule adopting the revised criterion or criteria; or
(B) If the developer obtains new customers of health IT certified to the revised criterion after the effective date of the final rule adopting the revised criterion or criteria, then the health IT developer must provide the health IT certified to the revised criterion to such customers within whichever of the following timeframes that expires last:
(
(
(b) * * *
(2)
(i) Service base URLs must be publicly published in Endpoint resource format according to the standard adopted in § 170.215(a).
(ii) Organization details for each service base URL must be publicly published in Organization resource format according to the implementation specifications adopted in § 170.215(b)(1)). Each Organization resource must contain:
(A) A reference, in the Organization.endpoint element, to the Endpoint resources containing service base URLs managed by this organization.
(B) The organization's name, location, and provider identifier.
(iii) Endpoint and Organization resources must be:
(A) Collected into a Bundle resource formatted according to the standard adopted in § 170.215(a) for publication; and
(B) Reviewed quarterly and, as necessary, updated.
The revisions read as follows:
(a)
(b) * * *
(2) * * *
(ii) For real world testing activities conducted during the immediately preceding calendar year, a health IT developer must submit to its ONC-ACB an annual real world testing results report addressing each of its certified Health IT Modules that include certification criteria referenced in paragraph (a) of this section by a date determined by the ONC-ACB that enables the ONC-ACB to publish a publicly available hyperlink to the results report on CHPL no later than March 15 of each calendar year, beginning in 2023. For certified Health IT Modules included in paragraph (a) of this section that are updated using Inherited Certified Status after August 31 of the year in which the plan is submitted, a health IT developer must include the newer version of the certified Health IT Module(s) in its annual real world testing results report. The real world testing results must report the following for each of the certification criteria identified in paragraph (a) of this section that are included in the Health IT Module's scope of certification:
(a) * * *
(5) Section 170.405 if a health IT developer has one or more Health IT Modules certified to any one or more ONC Certification Criteria for Health IT in § 170.315(a)(9), (b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h).
(a)
(1)
(A) Any Health IT Module certified to sections 170.315(e)(1) or (g)(10); and
(B) Has at least 50 hospital users or 500 clinician users across its certified health IT products.
(ii) A health IT developer must submit a response that it does not meet the minimum reporting qualifications for this measure if:
(A) The health IT developer does not have at least one product that is certified to one or more of the applicable certification criteria specified in the measure requirements;
(B) The health IT developer does not have at least 50 hospital users or 500 clinician users across its certified health IT; or
(C) If the health IT developer's product does not have any users using the functionality specified by the certification criteria specified in the measure during the reporting period.
(2)
(A) Any Health IT Module certified to section 170.315(b)(2); and
(B) Has at least 50 hospital users or 500 clinician users across its certified health IT products.
(ii) A health IT developer must submit a response that it does not meet the minimum reporting qualifications for this measure if:
(A) The health IT developer does not have at least one product that is certified to the certification criterion specified in the measure requirements;
(B) The health IT developer does not have at least 50 hospital users or 500 clinician users across its certified health IT; or
(C) If the health IT developer's product does not have any users using the functionality specified by the certification criterion specified in the measure during the reporting period.
(3)
(A) Any Health IT Module certified to sections 170.315(b)(2); and
(B) Has at least 50 hospital users or 500 clinician users across their certified health IT products.
(ii) A health IT developer must submit a response that it does not meet the minimum reporting qualifications for this measure if:
(A) The health IT developer does not have at least one product that is certified to the certification criterion specified in the measure requirements;
(B) The health IT developer does not have at least 50 hospital users or 500 clinician users across its certified health IT; or
(C) If the health IT developer's product does not have any users using the functionality specified by the certification criterion specified in the measure during the reporting period.
(4)
(A) Any Heath IT Module certified to section 170.315(g)(10); and
(B) Has at least 50 hospital users or 500 clinician users across its certified health IT products.
(ii) A health IT developer must submit a response that it does not meet the minimum reporting qualifications for this measure if:
(A) The health IT developer does not have at least one product that is certified to the certification criterion specified in the measure requirements;
(B) The health IT developer does not have at least 50 hospital users or 500 clinician users across its certified health IT; or
(C) If the health IT developer's product does not have any users using the functionality specified by the certification criterion specified in the applicable measure during the reporting period.
(5)
(A) Any Health IT Module certified to section 170.315(g)(10); and
(B) Has at least 50 hospital users or 500 clinician users across its certified health IT products.
(ii) A health IT developer must submit a response that it does not meet the minimum reporting qualifications for this measure if:
(A) The health IT developer does not have at least one product that is certified to the certification criterion specified in the measure requirements;
(B) The health IT developer does not have at least 50 hospital users or 500 clinician users across its certified health IT; or
(C) If the health IT developer's product does not have any users using the functionality specified by the certification criterion specified in the applicable measure during the reporting period.
(6)
(A) Any Health IT Module certified to section 170.315(g)(10); and
(B) Has at least 50 hospital users or 500 clinician users across its certified health IT products.
(ii) A health IT developer must submit a response that it does not meet the minimum reporting qualifications for this measure if:
(A) The health IT developer does not have at least one product that is certified to the certification criterion specified in the measure requirements;
(B) The health IT developer does not have at least 50 hospital users or 500 clinician users across its certified health IT; or
(C) If the health IT developer's product does not have any users using the functionality specified by the certification criterion specified in the applicable measure during the reporting period.
(7)
(A) Any Health IT Module certified to section 170.315(b)(10); and
(B) Has at least 50 hospital users or 500 clinician users across its certified health IT products.
(ii) A health IT developer must submit a response that it does not meet the minimum reporting qualifications for this measure if:
(A) The health IT developer does not have at least one product that is certified to the certification criterion specified in the measure requirements;
(B) The health IT developer does not have at least 50 hospital users or 500 clinician users across its certified health IT; or
(C) If the health IT developer's product does not have any users using the functionality specified by the certification criterion specified in the applicable measure during the reporting period.
(8)
(A) Any Health IT Module certified to section 170.315(f)(1); and
(B) Has at least 50 hospital users or 500 clinician users across its certified health IT products.
(ii) A health IT developer must submit a response that it does not meet the minimum reporting qualifications for this measure if:
(A) The health IT developer does not have at least one product that is certified to the certification criterion specified in the measure requirements;
(B) The health IT developer does not have at least 50 hospital users or 500 clinician users across its certified health IT; or
(C) If the health IT developer's product does not have any users using the functionality specified by the certification criterion specified in the applicable measure during the reporting period.
(9)
(A) Any Health IT Module certified to section 170.315(f)(1); and
(B) Has at least 50 hospital users or 500 clinician users across its certified health IT products.
(ii) A health IT developer must submit a response that it does not meet the minimum reporting qualifications for this measure if:
(A) The health IT developer does not have at least one product that is certified to the certification criterion specified in the measure requirements;
(B) The health IT developer does not have at least 50 hospital users or 500 clinician users across its certified health IT; or
(C) If the health IT developer's product does not have any users using the functionality specified by the certification criterion specified in the applicable measure during the reporting period.
(b)
(i) A health IT developer must provide responses for measures specified in paragraphs (a)(1), (4), (8), and (9) of this section beginning April 2025;
(ii) A health IT developer must provide responses for measures specified in paragraphs (a)(2), (3), and (5) through (7) of this section beginning April 2026.
(2) [Reserved]
The revisions and addition read as follows:
(f) * * *
(1) For the ONC Certification Criteria for Health IT:
(xxi) Where applicable, all of the information required to be submitted by the health IT developer to meet intervention risk management requirements in § 170.315(b)(11)(vii)(C).
(g) * * *
(1) Retain all records related to the certification of Complete EHRs and Health IT Modules to the ONC Certification Criteria for Health IT beginning with the codification of those certification criteria in the Code of Federal Regulations through a minimum of 3 years from the effective date of the removal of those certification criteria from the Code of Federal Regulations; and
(k) * * *
(1) * * *
(i) The disclaimer “This Health IT Module is compliant with the ONC Certification Criteria for Health IT and has been certified by an ONC-ACB in accordance with the applicable certification criteria adopted by the Secretary of Health and Human Services. This certification does not represent an endorsement by the U.S. Department of Health and Human Services.”
(ii) For a Health IT Module certified to the ONC Certification Criteria for Health IT, the information specified by paragraphs (f)(1)(i), (vi) through (viii), (xv), and (xvi) of this section as applicable for the specific Health IT Module.
(u)
(f) * * *
(1) Retain all records related to the testing of Complete EHRs and/or Health IT Modules to the ONC Certification Criteria for Health IT beginning with the codification of those certification criteria in the Code of Federal Regulations through a minimum of three years from the effective date of the removal of those certification criteria from the Code of Federal Regulations; and
(g)
(h) * * *
(1)
(3) * * *
(iii) Section 170.315(b)(1) through (3) and (6) through (9) are also certified to the certification criteria specified in § 170.315(d)(1) through (3), (d)(5) through (8), (d)(12) and (13), and, by January 1, 2026, (d)(14);
(v) Section 170.315(e)(1) is also certified to the certification criteria specified in § 170.315(d)(1) through (3), (5), (7), (9), (12), (13), and, by January 1, 2026, (d)(14);
(viii) Section 170.315(g)(7) through (10) is also certified to the certification
(m)
42 U.S.C. 300jj-52; 5 U.S.C. 552.
The additions and revision read as follows:
(1) Donation and subsidized supply arrangements are not considered offerings when an individual or entity donates, gives, or otherwise makes available funding to subsidize or fully cover the costs of a health care provider's acquisition, augmentation, or upkeep of health IT, provided such individual or entity offers and makes such subsidy without condition(s) limiting the interoperability or use of the technology to access, exchange or use electronic health information for any lawful purpose.
(2) Implementation and use activities conducted by an individual or entity as follows:
(i) Issuing user accounts and/or login credentials for the individual's or organization's employees to use the individual's or organization's health IT to access, exchange, or use
(ii) Implementing, operating, or otherwise making available production instances of application programming interface (API) technology (whether certified or not) that supports access, exchange, and use of
(iii) Implementing, operating, and making available production instances of online portals for patients, clinicians, or other health care providers, or public health entities to access, exchange, and use
(iv) Issuing login credentials or user accounts for the individual's or entity's production, development, or testing environments to public health authorities or such authorities' employees as a means of accomplishing or facilitating access, exchange, and use of
(v) Issuing login credentials or user accounts for independent healthcare professionals who furnish services in a healthcare facility to use the facility's electronic health record or other health IT system(s) in furnishing, documenting, and accurately billing for that care.
(3) Consulting and legal services arrangements as follows:
(i) Legal services furnished by outside counsel—when furnishing legal services to a client in any matter or matters pertaining to the client's seeking, assessing, selecting, or resolving disputes over contracts or other arrangements by which the client obtains use of certified health IT. Outside counsel also does not offer health IT if or when facilitating limited access or use of the client's health IT or EHI within it to independent expert witnesses engaged by counsel, opposing parties' counsel and experts, and special masters and court personnel, as necessary or appropriate to legal discovery.
(ii) Health IT consultant assistance selection, implementation and use consultant—provided by an individual or firm when furnishing expert advice and consulting services to a health IT customer or user that help the customer or user, or on the customer's behalf, do any or all of the following with respect to any health IT product that the consultant does not sell or resell, license or relicense, or otherwise supply to the customer under any arrangement on a commercial basis or otherwise:
(A) define the customer or user business needs; evaluate or select health IT product(s);
(B) negotiate for the purchase, lease, license, or other arrangement under which the health IT product(s) will be used; or
(C) oversee configuration, implementation, or operation of health IT product(s).
(iii) Comprehensive and predominantly non-health IT clinician practice or other health care provider administrative or operations management services—provided by an individual or entity when furnishing a clinician practice or other health care provider administrative or operational management consultant services where the management consultant acts as the agent of the provider or otherwise stands in the shoes of the provider in dealings with the health IT developer or commercial vendor, and/or in managing the day-to-day operations and administrative duties for the health IT, as part of a comprehensive array of predominantly non-health IT administrative and operational functions that would otherwise fall on the clinician practice or other health care provider's partners, owner(s), or staff.
(a) Information blocking means a practice that except as required by law or covered by an exception set forth in subpart B or subpart C of this part, is likely to interfere with access, exchange, or use of electronic health information; and
(b) If conducted by:
(1) A health IT developer of certified health IT, health information network or health information exchange, such developer, network or exchange knows, or should know, that such practice is likely to interfere with access, exchange, or use of electronic health information; or
(2) A health care provider, such provider knows that such practice is unreasonable and is likely to interfere with access, exchange, or use of electronic health information.
(a) * * * (1)
(3)
(4)
(i) The actor could not reach agreement with a requestor in accordance with § 171.301(a) or was technically unable to fulfill a request for electronic health information in the manner requested;
(ii) The actor offered all alternative manners in accordance with § 171.301(b) for the electronic health information requested but could not reach agreement with the requestor; and
(iii) The actor does not provide the same access, exchange, or use of the requested electronic health information to a substantial number of individuals or entities that are similarly situated to the requester.
(5)
(A) The type of electronic health information and the purposes for which it may be needed;
(B) The cost to the actor of complying with the request in the manner requested;
(C) The financial and technical resources available to the actor;
(D) Whether the actor's practice is non-discriminatory and the actor provides the same access, exchange, or use of electronic health information to its companies or to its customers, suppliers, partners, and other persons with whom it has a business relationship;
(E) Whether the actor owns or has control over a predominant technology, platform, health information exchange, or health information network through which electronic health information is accessed or exchanged; and
(F) Why the actor was unable to provide access, exchange, or use of electronic health information consistent with the exception in § 171.301.
(ii) In determining whether the circumstances were infeasible under paragraph (a)(3)(i) of this section, it shall not be considered whether the manner requested would have:
(A) Facilitated competition with the actor.
(B) Prevented the actor from charging a fee or resulted in a reduced fee.
An actor's practice of limiting the manner in which it fulfills a request to access, exchange, or use electronic health information will not be considered information blocking when the practice follows the conditions of this section.
(a)
(2) If an actor fulfills a request for electronic health information in any manner requested:
(i) Any fees charged by the actor in relation to fulfilling the request are not required to satisfy the exception in § 171.302; and
(ii) Any license of interoperability elements granted by the actor in relation to fulfilling the request is not required to satisfy the exception in § 171.303.
(b)
(1) The actor must fulfill the request without unnecessary delay in the following order of priority, starting with paragraph (b)(1)(i) of this section and only proceeding to the next consecutive paragraph if the actor is technically unable to fulfill the request in the manner identified in a paragraph.
(i) Using technology certified to standard(s) adopted in part 170 that is specified by the requestor.
(ii) Using content and transport standards specified by the requestor and published by:
(A) The Federal Government; or
(B) A standards developing organization accredited by the American National Standards Institute.
(iii) Using an alternative machine-readable format, including the means to interpret the electronic health information, agreed upon with the requestor.
(2) Any fees charged by the actor in relation to fulfilling the request are required to satisfy the exception in § 171.302.
(3) Any license of interoperability elements granted by the actor in relation to fulfilling the request is required to satisfy the exception in § 171.303.
(c)
(i) The actor is not required to offer the EHI in any alternative manner;
(ii) Any fees charged by the actor in relation to fulfilling the request are not required to satisfy the exception in § 171.302; and
(iii) Any license of interoperability elements granted by the actor in relation to fulfilling the request is not required to satisfy the exception in § 171.303.
(d)
(1)(i)
(ii)
(iii)
(A) a Participant-Subparticipant Agreement to use the services of a Participant to send and/or receive information; or
(B) a Downstream Subparticipant Agreement pursuant to which the services of a Subparticipant are used of the Common Agreement to send and/or receive information.
(iv)
(v)
(2) QHIN Services means any technical services provided within a QHIN.
Securities and Exchange Commission.
Proposed rule.
The Securities and Exchange Commission (“Commission” or “SEC”) is proposing to require electronic filing or submission of certain forms and other filings or submissions that are required to be filed with or submitted to the Commission under the Securities Exchange Act of 1934 (“Exchange Act”) and the rules and regulations under the Exchange Act. The proposal would require the electronic filing or submission on the Commission's Electronic Data Gathering, Analysis, and Retrieval (“EDGAR”) system, using structured data where appropriate, for certain forms filed or submitted by self-regulatory organizations (“SROs”). The proposal would require the information currently contained in Form 19b-4(e) to be publicly posted on the SRO's website and remove the manual signature requirements for SRO proposed rule change filings. The Commission is also proposing that a clearing agency post supplemental material to its website. In addition, the proposal would amend rules under the Exchange Act and the Securities Act of 1933 (“Securities Act”) to require the electronic filing or submission on EDGAR, using structured data where appropriate, of certain forms, reports and notices provided by broker-dealers, security-based swap dealers and major security-based swap participants. The proposed amendments also would require withdrawal in certain circumstances of notices filed in connection with an exception to counting certain dealing transactions toward determining whether a person is a security-based swap dealer. Finally, the Commission is proposing to allow electronic signatures in certain broker-dealer filings, and is proposing amendments regarding the Financial and Operational Combined Uniform Single Report (“FOCUS Report”) to harmonize with other rules, make technical corrections, and provide clarifications.
Comments should be received on or before May 22, 2023.
Comments may be submitted by any of the following methods:
• Use the Commission's internet comment form (
• Send an email to
• Send paper comments to Secretary, Securities and Exchange Commission, 100 F Street NE, Washington, DC 20549-1090.
Studies, memoranda, or other substantive items may be added by the Commission or staff to the comment file during this rulemaking. A notification of the inclusion in the comment file of any such materials will be made available on the Commission's website. To ensure direct electronic receipt of such notifications, sign up through the “Stay Connected” option at
For Form 1—Justin Pica, Assistant Director, and David Remus, Special Counsel; for Form 1-N—David Dimitrious, Senior Special Counsel, and Michou Nguyen, Special Counsel; for Form 15A—Molly Kim, Assistant Director, and David Michehl, Special Counsel; for Form CA-1—Matthew Lee, Assistant Director, and Claire Noakes, Special Counsel; for Form 19b-4(e) and technical amendment to Form 19b-4—Cristie March, Senior Special Counsel, and Edward Cho, Special Counsel; for Rule 17a-22—Matthew Lee, Assistant Director, and Susan Petersen, Special Counsel; for Form X-17A-5 Part III and related annual filings, Form X-17A-5 Parts II, IIA, and IIC, Form 17-H, and Form X-17A-19—Raymond A. Lombardo, Assistant Director, Rose Wells, Special Counsel, and Valentina Minak Deng, Special Counsel; for notices provided pursuant to Exchange Act Rules 3a71-3(d)(1)(vi) and 15fi-3(c)—Carol McGee, Associate Director, and Russell Mancuso, Special Counsel; and for reports submitted pursuant to Rule 15fk-1(c)(2)(ii)(A), Kelly Shoop, Branch Chief, and Katherine Lesker, Special Counsel, Division of Trading and Markets, at (202) 551-5500, Securities and Exchange Commission, 100 F Street NE, Washington, DC 20549.
The Commission is proposing to require the electronic filing or submission, using structured data where appropriate, of certain forms and other filings,
Finally, the Commission is proposing to rescind:
In developing this proposal with regard to SBS Entities, the Commission has consulted and coordinated with the Commodity Futures Trading Commission (“CFTC”) and the prudential regulators in accordance with the Dodd-Frank Wall Street Reform and Consumer Protection Act (“Dodd-Frank Act”).
As part of its response to the COVID-19 pandemic, the Commission and its staff provided assistance and regulatory relief to market participants, as appropriate, to facilitate the continued orderly and fair functioning of the securities markets.
In general, electronic filing of Impacted Paper Submissions has been practical and efficient. It also has been the Commission's experience that electronic filing has been positively received by the various registrants that have used it. Based in part on these positive experiences with electronic filing during the COVID-19 pandemic, and as part of its efforts to modernize the methods by which it collects and analyzes information from registrants, the Commission is proposing to amend some of the rules and forms discussed in this release, as set forth in more detail below, to require that certain filings be submitted to the Commission electronically using the Commission's EDGAR system. As part of the effort to modernize its information collection and analysis methods, and as discussed more fully below, the Commission is proposing that a number of the filings submitted to the Commission electronically on EDGAR use structured data where appropriate.
The Commission is proposing to require that the following forms be filed electronically on EDGAR:
The
In particular, as required by 17 CFR 240.6a-1 (“Rule 6a-1”), 17 CFR 240.6a-2 (“Rule 6a-2”), and 17 CFR 240.6a-3 (“Rule 6a-3”) under the Exchange Act, a prospective exchange must file on 17 CFR 249.1 (“Form 1”) an application for registration as a national securities exchange (or for an exemption from the requirement to register as a national securities exchange based on limited volume), and, once registered, the exchange must file as an amendment to its Form 1 certain updating information, as well as certain supplemental material and reports. In addition, as required by 17 CFR 240.6a-4 (“Rule 6a-4”) under the Exchange Act, a prospective exchange may register as a Security Futures Product Exchange by filing 17 CFR 249.10 (“Form 1-N”) (“notice registration”) if it satisfies certain prerequisites, and must file amendments to its initial filing and certain supplemental materials on Form 1-N as well. An applicant for registration as a national securities association must file a registration statement with the Commission on Form X-15AA-1, and every association applying for registration or registered as a national securities association must file amendments and supplements to its registration statement with the Commission on Form X-15AJ-1 and annual supplements to its registration statement with the Commission on Form X-15AJ-2. Moreover, as required by Rule 17ab2-1 (“Rule 17ab2-1”) under the Exchange Act, a prospective clearing agency must file on Form CA-1 an application for registration as a clearing agency (or for an exemption from such registration), and both registered and exempt clearing agencies must file amendments to their Form CA-1 as necessary. In each of the foregoing situations, these forms are submitted to the Commission in a paper-based format. As a result, the prospective and existing SROs, exempt exchanges, and exempt clearing agencies must incur the costs of completing their respective paper-based forms, making the requisite number of copies, and submitting the original version and copies to the Commission.
The Commission also is proposing to rescind the following form and instead require that the information currently contained in the form be publicly posted on the relevant SRO's internet website:
Currently, 17 CFR 240.19b-4(e) (“Rule 19b-4(e)”) under the Exchange Act requires an SRO to submit to the Commission reports regarding the listing and trading of new derivative securities products on Form 19b-4(e) in a paper-based format. As with the forms discussed above in this section, SROs must incur the costs of completing the paper-based form, making the requisite number of copies, and submitting the original version and copies to the Commission.
Rule 17a-22 requires a registered clearing agency to file with the Commission three copies of any material within 10 days after issuing, or making generally available, such materials to its participants or to other entities with whom it has a significant relationship.
Since the Commission adopted Rule 17a-22 in 1980, technology has evolved significantly and the internet has played an increasingly vital role in information distribution.
During this period, the Commission has encouraged the dissemination of information electronically via the internet and other automated systems and services.
The Commission is now proposing to amend Rule 17a-22 to eliminate the paper filing requirement altogether and require registered clearing agencies to post any supplementary materials to its internet website, as discussed further below.
The Commission believes that the certain forms and other filings that are proposed to be filed on EDGAR by broker-dealers, OTC derivatives dealers, SBSDs, and MSBSPs are appropriate for electronic filing because many of them are voluminous (in number, size, or both) and some of them contain certain information that must be disclosed publicly.
The Commission is proposing to use the existing EDGAR system for certain filings because Form X-17A-5 Part III and Form 17-H are already permitted to be filed on EDGAR and the Commission believes that some of these filings may be readily transitioned to electronic filing on EDGAR.
The Commission is proposing to use the EDGAR system for the following notices, reports, and filings: (1) notices made pursuant to Rule 17a-19 under the Exchange Act and on accompanying Form X-17A-19; (2) notices made pursuant to Rule 3a71-3(d)(1)(vi) under the Exchange Act; (3) notices made to the Commission pursuant to Rule 15fi-3(c) under the Exchange Act; and (4) reports made pursuant to Rule 15fk-1(c)(2)(ii)(A) under the Exchange Act. Currently, the notices made pursuant to Rule 17a-19 under the Exchange Act and on accompanying Form X-17A-19 are submitted via paper.
The Commission is proposing to require certain of the disclosures required by the following filings to be provided in a structured, machine-readable data language: (1) the Covered SRO Forms; (2) the information required under Rule 19b-4(e); (3) Form X-17A-19; (4) the annual reports (and related annual filings) filed by broker-dealers (including OTC derivatives dealers) and SBS Entities on Form X-17A-5 Part III; (5) the risk assessment reports filed by certain broker-dealers on Form 17-H; and (6) the notices and reports provided to the Commission by SBS Entities under Exchange Act Rules 15fi-3(c) and 15fk-1(c)(2)(ii)(A), respectively (together, the “Proposed Structured Documents”).
Specifically, the Commission is proposing to require the report required by Exchange Act Rule 15fk-1(c)(2)(ii)(A) and portions of Form 1, Form CA-1, Form 17-H, and Form X-17A-5 Part III and related annual filings to be provided in the Inline eXtensible Business Reporting Language (“Inline XBRL”) structured data language. The Commission is also proposing to require Form X-17A-19, the notice to the Commission (and any amendments to the notices) required by Exchange Act Rule 15fi-3(c), and portions of Form 1-N, Form 15A, Form 1, Form CA-1, Form 17-H, and Form X-17A-5 Part III and related annual filings to be provided in machine-readable, eXtensible Markup Language (“XML”)-based data languages specific to those documents (“custom XMLs”). As noted, these structured documents would be filed or submitted on EDGAR.
In addition, the Commission is proposing to require SROs to electronically post the information required under Rule 19b-4(e) using a custom XML-based data language (also referred to as a “schema”) that the Commission would create and publish on its website for SROs to use.
As discussed in further detail below, the Commission believes the proposed structured data requirements would facilitate access to the disclosures by users (
The Commission is proposing some disclosures to be structured in Inline
Certain of the proposed structured documents also include requirements to attach copies of existing documents, such as copies of by-laws, written agreements, user manuals, and listing applications. The Commission is proposing to require affected entities to file these copies of documents as unstructured PDF attachments to the otherwise structured forms. The Commission believes requiring affected entities to retroactively structure such existing documents, which were prepared for purposes outside of fulfilling the Commission's disclosure requirements, could impose compliance burdens on affected entities that may not be justified in light of the commensurate informational benefits associated with having such documents in structured form.
Similarly, Forms 1-N and 15A (other than the cover pages—
Finally, the Commission is proposing amendments regarding the FOCUS Report to harmonize with other rules, make technical changes, and provide clarifications. In addition, the Commission is proposing to allow electronic signatures in Rule 17a-5, 17a-12, and 18a-7 filings, including the FOCUS Report.
The Commission proposes to amend certain Exchange Act rules and the Covered SRO Forms, including their instructions, to eliminate the current paper copy filing method and instead require electronic submission of the Covered SRO Forms. Changing from the current method of paper filing to electronic submission of the Covered SRO Forms ultimately should increase efficiencies and decrease costs for Filers with respect to their filing obligations.
The proposal would require the use of EDGAR to file the Covered SRO Forms. The Commission is proposing to use the existing EDGAR system for the Covered SRO Forms because the Commission believes that these filings are similar to other filings that are currently submitted on EDGAR. Furthermore, many of the Covered SRO Forms contain information that must be disclosed publicly, and electronic conversion and/or publication of these filings by Commission staff, to make them available to the public and Commission staff, is labor intensive and time consuming. The Commission believes that requiring the submission of these filings on EDGAR would facilitate more efficient transmission, analysis, dissemination, storage, and retrieval of information, and would benefit the Commission, the submitting entities, investors, and other market participants. As a result of the proposed amendments to relevant Commission rules and forms as described below, any Filer of the Covered SRO Forms who has not previously made an electronic filing on EDGAR would need to apply for EDGAR access pursuant to the EDGAR Filer Manual
For each of the Covered SRO Forms, the Commission is proposing to add technical requirements to the form's general instructions to specify when a form would be considered incomplete or deficient when filed. Specifically, each Filer would be required to provide all the information required by the form, including the exhibits, and a filing that is incomplete or otherwise deficient may be returned to the Filer. The proposed general instructions for each form also would set forth what comprises a complete filing. For instance, the proposed general instructions for Form 1 would state that a completed form filed with the Commission shall consist of Form 1, responses to all applicable items, and any exhibits required in connection with the filing.
The Commission also proposes that, for each of the Covered SRO Forms, the general instructions would require some or all of the information reported on the forms (including, where applicable, the exhibits to the forms) to be provided in a structured, machine-readable data language. For Form 1 and Form CA-1, the general instructions would require the submissions to be provided in part using Inline XBRL and in part using custom XML data languages specific to those Forms, with certain submissions that constitute copies of existing documents of a Filer (such as copies of governing documents or copies of contracts) to be included as text-searchable PDF attachments rather than structured data.
For Form CA-1, Schedule A and Exhibits C, F, H, J, K, L, M, O, R, and S would be filed in Inline XBRL.
For Form 1, Exhibits D, E (in part), and I would be filed in Inline XBRL.
Similarly, the information under proposed Rule 19b-4(e)(2)(ii) would be required to be provided on the listing SRO's website using a custom XML data language, thus making the information machine-readable.
The Commission believes that the proposed requirement that the Covered SRO Forms be filed, and information pursuant to Rule 19b-4(e) be posted, using structured data languages would allow the Commission and, if applicable, investors, market participants, and other interested parties, to efficiently review and analyze the information.
Based on the Commission's experience in reviewing the Covered SRO Forms and information posted pursuant to Rule 19b-4(e), the Commission also believes that the proposed requirement to electronically file the Covered SRO Forms and electronically post the information required pursuant to Rule 19b-4(e) would allow for more efficient use of Commission resources related to reviewing, assessing, and processing these filings and postings. In addition, information provided on the Covered SRO Forms would be captured automatically by EDGAR and would be text-searchable or machine-readable. The information posted pursuant to Rule 19b-4(e) would be machine-readable as well. As a result, the Commission believes that these features would facilitate its oversight of SROs.
Substantive changes would not be required to the information required to be filed on the Covered SRO Forms or the information required to be posted pursuant to Rule 19b-4(e). Rather, the proposal is intended simply to require and facilitate the electronic filing of the Covered SRO Forms and the disclosure of the information required under Rule 19b-4(e), which the SROs currently are required to provide to the Commission.
Section 6(a) of the Exchange Act states, “[a]n exchange may be registered as a national securities exchange . . . by filing with the Commission an application for registration in such form as the Commission, by rule, may prescribe containing the rules of the exchange and such other information and documents as the Commission, by rule, may prescribe as necessary or appropriate in the public interest or for the protection.”
Rule 6a-1 under the Exchange Act generally requires that an entity seeking to register as a national securities exchange, or seeking an exemption from such registration based on limited volume, file an application on Form 1 and correct any inaccuracy therein upon discovery.
Rule 6a-2 requires a registered national securities exchange or an exempt exchange
Pursuant to 17 CFR 240.6a-2(b) (“Rule 6a-2(b)”), on or before June 30 of each year, a national securities exchange or an exempt exchange
Pursuant to Rule 6a-3, a national securities exchange or an exempt exchange
Form 1 filings are currently made available to the public.
The Commission proposes to amend Rules 6a-1, 6a-2, and 6a-3 under the Exchange Act, as well as Form 1 and the instructions to Form 1, to require the electronic filing on EDGAR of all submissions required by the rules. As explained in section II above, the Commission believes that, among other benefits, these proposed amendments should increase efficiencies related to the filing of these forms and the review and analysis of the filed forms by the Commission and its staff as well as by investors, market participants, and other interested parties. In addition, the Commission proposes conforming changes to Rule 3(b)(2) of its Informal and Other Procedures,
The Commission proposes to add a new paragraph (e) to Rule 6a-1 to require the electronic filing on EDGAR of all Form 1 filings and amendments to such filings. The Commission also proposes to amend Rules 6a-2(a), (b), and (c) to mandate the electronic filing on EDGAR of the Form 1 amendments under those paragraphs by requiring the electronic filing of those amendments, in accordance with proposed 17 CFR 240.6a-1(e) (“Rule 6a-1(e)”).
As stated earlier in this section, Rule 6a-3 requires national securities exchanges and exempt exchanges to file certain supplemental material and reports with the Commission after registration or being granted an exemption from registration. The Commission proposes to amend Rule 6a-3 to require national securities exchanges and exempt exchanges to file on EDGAR such supplemental material and reports electronically on Form 1, in accordance with proposed Rule 6a-1(e).
In addition to the proposed revisions to Rules 6a-1, 6a-2, and 6a-3, the Commission proposes to revise and reformat Form 1, and the instructions thereto, to accommodate the electronic filing on EDGAR of initial applications, subsequent amendments, supplemental material, and reports that are made on Form 1. The proposed changes to Form 1 to permit electronic submission to the Commission would require minimal modifications to the form, as described below. The Commission also proposes to revise the Form 1 instructions to facilitate the electronic filing and machine-readability of Form 1.
The Commission proposes that electronic Form 1 would solicit information through prompts on the form. Proposed electronic Form 1 also would require an exchange to attach exhibits via a new exhibit table that would be part of electronic Form 1. Where Rule 6a-2 allows for alternative means of filing the information required under certain exhibits, the new exhibit table would permit an exchange to electronically provide the certifications and details necessary for an exchange to avail itself of those alternative means. The information required to be filed with the exhibits is not changing. Currently, Rule 6a-2 provides that in lieu of filing certain exhibits as part of a paper Form 1 submission, an exchange may: (i) identify where such information is published and certify its accuracy as of its publication date; (ii) certify that the information is available to the Commission and the public upon request; or (iii) indicate the location of the internet website where such information may be found and certify that the information available at such location is accurate as of its date.
For electronic Form 1, the Commission proposes to add prompts prior to Section I that would require the exchange to identify the basis for submitting the form. Specifically, proposed electronic Form 1 would require the exchange to check a box stating one of the following: (i) whether the filing is an initial Form 1 application and if it is, whether the exchange is applying to be a national securities exchange or an exempt exchange; (ii) whether the filing is an amendment to an initial Form 1 application prior to Commission action to grant registration or an exemption based on limited volume; (iii) whether the filing is to provide the exchange's consent to an extension of the time period within which the Commission must take action on an initial Form 1 application;
The proposed electronic Form 1 would also capture contact information for the exchange and certain individuals. Consistent with current Form 1, the proposed electronic Form 1 would require the exchange to identify contact information for the exchange, a contact employee, and counsel for the exchange. Unlike current Form 1, proposed electronic Form 1 would additionally require an email address for the contact employee. The Commission believes that the requirement to provide an email address for the exchange contact employee would expedite communications between Commission staff and the relevant exchange.
Proposed electronic Form 1 would require an exchange to electronically attach exhibits by using an exhibit table. The proposed exhibit table would contain columns for the name of the exhibit, information required by the exhibit, whether alternative means of satisfying the filing of an exhibit are available for that particular exhibit (
Furthermore, electronic Form 1 would continue to require an exchange to consent to service of any civil action brought by, or notice of any proceeding before, the Commission in connection with its activities. The current language under which the exchange consents to service via registered or certified mail at the main or mailing address provided on Form 1 would continue to be included in the electronic form.
In addition, the proposed electronic Form 1 would require the individual who is submitting the form to check a box on behalf of the exchange to represent that the information and statements contained in the Form 1, including exhibits, schedules, or other documents, are current, true, and complete. The requirement to sign and notarize the form would be eliminated because it is unnecessary, not compatible with, and not required for electronic filing on EDGAR.
Finally, electronic Form 1 would require exchanges to structure Exhibits D (unconsolidated financial statements of each of the exchange's subsidiaries or affiliates), E (description of the electronic trading system's manner of operation, except for the attached copy of the users' manual), and I (audited financial statements of the exchange) in Inline XBRL. The execution page, Exhibits C (information regarding each of the exchange's subsidiaries, affiliates, and entities with whom the exchange has an agreement relating to the operation of the exchange's electronic trading system, except for the copies of existing documents listed below), H (listing fee schedule and brief description of the criteria governing which securities may be traded on the exchange, except for the copies of existing documents listed below), J (list of officers, governors, standing committee members, or persons performing similar functions), K (list of significant shareholders or partners), L (description of criteria, conditions, and procedures governing membership in the exchange), M (list of members, participants, subscribers, or other users
Attached copies of existing documents, including those filed with Exhibits A (constitution, articles of incorporation or association, and existing by-laws or corresponding rules or instruments of the exchange), B (written rulings, settled practices having the effect of rules, and interpretations of the Governing Board or other committee of the exchange in respect of any provisions of the constitution, by-laws, rules, or trading practices of the exchange), C (written rulings, settled practices having the effect of rules, and interpretations of the Governing Board or other committee of the exchange in respect of any provisions of the constitution, by-laws, rules, or trading practices of the exchange's affiliates, subsidiaries, or entities with whom the exchange has an agreement related to the operation of the exchange's electronic trading system), E (listing applications and required agreements), F (forms pertaining to membership, participation, or subscription, application for approval as a person associated with a member, participant, or subscriber of the exchange, or any other similar materials), G (forms of financial statements, reports, or questionnaires required of members, participants, subscribers, or any other users relating to financial responsibility or minimum capital requirements for such members, participants, or any other users), H (listing applications and agreements required to be executed in connection with listing), and the information required under Rule 6a-3(a)(1) (supplemental materials issued or made available to members of, or participants or subscribers to, the exchange), would be filed as unstructured PDF documents.
The proposed structuring requirements could facilitate access to the exchange's disclosures (such as by enabling efficient retrieval of only those disclosures filed by a subset of exchanges over particular reporting periods) and their analysis (such as by enabling efficient comparisons of individual disclosures or sets of disclosures across different exchanges and reporting periods). This could benefit market participants through enhanced oversight of the exchanges. For example, Commission staff could leverage the machine-readability of Exhibit I to automatically flag any atypical fluctuations in particular financial line items across every exchange's financial statements, and assess whether closer examination of any such fluctuations would be warranted. Similarly, Commission staff could leverage the machine-readability of Exhibit E by retrieving automated redline comparisons of the manner of operations description disclosed by exchanges from prior reporting periods to the current reporting period, thus pinpointing any widespread operational changes for further assessment.
Market participants (such as issuers, analysts, and other exchanges) could also benefit from direct use of the machine-readable disclosures on Form 1. For example, the structuring requirement for Exhibit H could allow issuers to more efficiently compare listing fees charged by different exchanges as they determine the exchange on which they list their securities. Without the proposed structured data requirements, these analyses, to the extent they are done, need to be performed manually, such as by gathering the current and former financial statements for each exchange and entering all financial line items of interest into databases, resulting in a significantly less efficient and precise process. In addition, the proposed structured data requirement would enable EDGAR to perform technical validations (
The nature and extent of such benefits may vary based on the content of each Form 1 Exhibit. As discussed in the subsequent economic analysis, studies of XBRL requirements for public operating company financial statements indicate a number of benefits for investors and market participants.
The Commission is proposing to require Inline XBRL for certain exhibits to Form 1 and custom XML for others because the Commission believes each data language is better suited for particular types of disclosures. Exhibits D and I require disclosure of financial statements, and Inline XBRL was designed to accommodate financial statement information, including the particular metadata (
The execution page of Form 1, Exhibits C (in part), H (in part), J, K, L, M, and N to Form 1, and the Rule 6a-3(b) reports filed on Form 1 do not require such content. For these disclosures, the Commission believes the use of custom XML data languages would be preferable to Inline XBRL, because it would yield smaller file sizes and therefore enable more streamlined processing of the information.
The proposed approach of requiring Inline XBRL for some Form 1 exhibits and custom XML for others would entail drawbacks for users of the information (including Commission staff and market participants). Specifically, data users would be unable to incorporate the Inline XBRL disclosures filed on Form 1 into the same datasets and applications as the custom XML disclosures filed on Form 1, and run analyses across the differently formatted Form 1 disclosures, without undertaking data conversion processes that are frequently burdensome and imprecise. Similarly, any technical validations programmed into EDGAR would be unable to check for any inappropriate inconsistencies between disclosures on Inline XBRL exhibits and disclosures on custom XML exhibits on a given Form 1, thus reducing the benefit of improved data quality that would be likely to result from structured data requirements. Finally, some Form 1 filers may already be using Inline XBRL to structure similar data for internal business purposes, such as through the use of Enterprise Resource Planning (“ERP”) systems; these filers may prefer to use Inline XBRL for all proposed structured data requirements of Form 1, rather than using a combination of Inline XBRL and custom XML.
The Commission is proposing to require exchanges to file copies of existing documents, such as copies of by-laws, written agreements, and listing applications, as unstructured PDF attachments. The Commission believes an unstructured PDF requirement would be preferable to a structured data requirement for these documents, because requiring exchanges to retroactively structure these existing documents, which were prepared for purposes outside of fulfilling the Commission's disclosure requirements, would likely impose costly compliance burdens on exchanges that may not be justified in light of the commensurate informational benefits associated with more efficient disclosure use. Thus, the Commission does not believe structured data requirements are warranted for these copies of existing documents.
1. The Commission requests comment on all aspects of the proposed revisions to Form 1 to facilitate electronic filing on EDGAR. Are there any aspects of transitioning the form to electronic filing that the Commission has not addressed above? Please explain.
2. Would electronic filing of Form 1 on EDGAR and use of Inline XBRL and custom XML for certain elements of Form 1 filings improve the usefulness of Form 1 by members of the public? Would any market participants derive benefit from regulatory use of the Inline XBRL and custom XML disclosures on Form 1? Please explain why or why not.
3. What, if any, costs would be associated with preparing Form 1 filings for electronic filing through EDGAR? Are those costs more, less or the same as those currently expended under the current Form 1 filing process?
4. Form 1 filers would be required to prepare certain elements of Form 1 filings using Inline XBRL and custom XML. Would Form 1 filers experience practical difficulties or incur significant costs in preparing and submitting those elements of Form 1 using Inline XBRL and custom XML? If so, please explain the nature of those difficulties and costs as well as any alternative approaches the Commission should adopt.
5. Would requiring different structured data languages for different Exhibits of Form 1 provide benefits to data users or filers that justify any drawbacks associated such an approach? Please explain the nature of such benefits and drawbacks, and why the benefits would justify the drawbacks (or vice versa).
6. If a mix of structured data languages would be appropriate, should the specific data languages proposed for each Form 1 Exhibit be modified? For example, are there Form 1 Exhibits proposed as custom XML documents that would be better suited as Inline XBRL documents, or vice versa? Please explain why or why not.
7. Are there other structured data languages (
8. Would requiring exchanges to file copies of existing documents as unstructured PDF attachments, rather than requiring exchanges to retroactively structure those documents in machine-readable data languages, ease compliance burdens on exchanges? If so, would the reduced compliance burden on exchanges justify foregoing the benefits to data users of structuring these existing documents? Please explain why or why not.
Section 6 of the Exchange Act
Rule 6a-4 under the Exchange Act
The Commission proposes to amend Rule 6a-4 under the Exchange Act, as well as Form 1-N and the instructions to Form 1-N, to require the electronic filing on EDGAR of all submissions required by the rule and forms. As explained in section II above, the Commission believes that, among other benefits, these proposed amendments should increase efficiencies and decrease overall costs
The Commission proposes to add a new paragraph (d) to Rule 6a-4 to require the electronic filing of Form 1-N on EDGAR for exchange notice registrations and amendments made under Rule 6a-4 in accordance with the requirements of Regulation S-T.
The Commission also proposes changes to the text of Rule 6a-4 to accommodate electronic filing, as well as to make minor corrections and clarifications. Specifically, the Commission proposes to modify Rules 6a-4(a)(1) and 6a-4(c)(2) to resolve existing typographical errors and Rule 6a-4(b)(1)(i) to refer to the appropriate section of Form 1-N, rather than the “Execution Page,” to reflect the shift to electronic filing. The Commission proposes to modify Rules 6a-4(b)(5)(i), (ii) and (iii) to delete the phrase “satisfy this filing requirement by” because the language is superfluous. The Commission further proposes to make conforming changes to Rules 6a-4(b)(5)(i)(A) and (B), and 6a-4(b)(5)(ii) and (iii)(A) and (B) to make clear that certain certifications by the exchange and listing of websites containing information required by Rule 6a-4 would be required to be made on electronic Form 1-N. The Commission further proposes to update the due dates in Rules 6a-4(b)(3) and (4) for the next annual and triennial filings from June 30, 2002, and June 30, 2004, to June 30, 2023, and June 30, 2025, respectively. Finally, the Commission proposes to make non-substantive changes to Rules 6a-4(a)(1)(i), 6a-4(a)(1)(i)(B) and 6a-4(a)(1)(ii)(B) to update cross-references in those rules to the Commodities Exchange Act to reflect changes to the Commodities Exchange Act resulting from the Dodd-Frank Act.
In addition to the proposed revisions to Rule 6a-4, the Commission proposes to revise and reformat Form 1-N, and the instructions thereto, to accommodate the electronic filing of initial notices, subsequent amendments, supplemental material, and reports that are made on Form 1-N. The proposed changes to Form 1-N to permit electronic filing to the Commission would require minimal modifications to the form, as described below. The Commission also proposes to revise the Form 1-N instructions to facilitate the electronic filing of Form 1-N. As explained in the introduction to this section,
The Commission proposes that electronic Form 1-N would solicit information through prompts on the form that would better organize the information collected. Proposed electronic Form 1-N also would require an exchange to electronically attach exhibits (or provide website URL(s) where applicable) via a new exhibit table that would be part of electronic Form 1-N. The proposed exhibit table would contain columns for the name of the exhibit, information required by the exhibit, whether alternative means of satisfying the filing of an exhibit are available for that particular exhibit (
For electronic Form 1-N, the Commission proposes to add prompts prior to Section I that would require the exchange to identify the basis for submitting Form 1-N. Specifically, proposed electronic Form 1-N would require the exchange to check a box stating one of the following: (i) whether the filing is an initial notice of registration; (ii) whether the filing is an amendment to the notice of registration; (iii) whether the exchange is providing its annual filing for the year; (iv) whether the exchange is providing a triennial filing; (v) whether the exchange is providing supplemental materials; or (vi) whether the exchange is providing a report of security futures products traded during the prior calendar month.
The Commission also proposes to amend the instructions to Form 1-N to add a new section titled “When to Use the Form,” which would explain when Form 1-N filings are required, and which of the six types of Form 1-N filing is required (
The proposed electronic Form 1-N would also capture contact information for the exchange and certain individuals. Consistent with current Form 1-N, the proposed electronic Form 1-N would require the exchange to identify contact information for the exchange, a contact employee, and counsel for the exchange. Unlike current Form 1-N, proposed electronic Form 1-N would additionally require an email address for the contact employee and an email address for the exchange's counsel. The Commission believes that the requirement to provide an email address for the exchange contact employee and the exchange's counsel will expedite any subsequent communications between Commission staff and the relevant exchange.
In addition, to facilitate the electronic filing of the supplemental materials and monthly reports required under Rule 6a-4(c), the Commission proposes to add new Sections III and IV, respectively, to Form 1-N. Sections III and IV would require such materials and reports to be attached to Form 1-N via the new exhibit table in the same manner as exhibits to Form 1-N, and Section III would provide the exchange with the ability to enter URL(s) to the website location of the supplemental materials in lieu of its filing the supplemental materials via Form 1-N. Sections III and IV would not add new requirements beyond those currently included in Rule 6a-4(c). Currently, Rule 6a-4(c)(1) requires exchanges to file certain information with the Commission or in the alternative to indicate where such information can be found on an internet website controlled by the exchange. The proposed rule would require the filing of this information through Section III of electronic Form 1-N or, in the alternative, to provide through Section III of electronic Form 1-N the URL(s) of the location(s) on the internet website where such information can be found. Section III would also clarify that such website must be free and accessible (without any encumbrances or restrictions) by the general public. Likewise, Section IV would not change the substance of what must be reported; it would merely require the reporting of information required under Rule 6a-4(c) to be made on electronic Form 1-N instead of in paper format.
Furthermore, the Commission proposes that electronic Form 1-N would continue to require an exchange to consent to service of any civil action brought by, or notice of any proceeding before, the Commission in connection with its activities. The current language under which the Security Futures Product Exchange consents to service via registered or certified mail at the main or mailing address provided on Form 1-N would continue to be included in the electronically filed form.
In addition, the proposed electronic Form 1-N would require the individual who is submitting the form to check a box on behalf of the Security Futures Product Exchange to represent that the information and statements contained in the Form 1-N, including exhibits, schedules, or other documents, are current, true, and complete. The requirement to sign and notarize the form would be eliminated because it is unnecessary, not compatible with, and not required for electronic for electronic filing through EDGAR.
Finally, the proposed electronic Form 1-N would require filers to submit the execution page in a custom XML data language specific to Form 1-N. As with the other Covered SRO Forms, filers would be able to input their execution page disclosures into a fillable web form that EDGAR would subsequently convert to custom XML. The Commission believes structuring the execution page in custom XML would improve the ability to sort, filter, and otherwise organize Form 1-N filings without creating significant additional burden on Form 1-N filers. The remainder of Form 1-N would not be structured, however, because the very limited number of Form 1-N filers and filings could mitigate much of the benefit derived from machine-readability of the disclosures contained therein.
9. The Commission requests comment on all aspects of the proposed revisions to Form 1-N to facilitate electronic filing on EDGAR. Are there any aspects of transitioning the form to electronic filing that the Commission has not addressed above? Please explain.
10. Would allowing for the attachment of exhibits electronically on Form 1-N or to provide through Section III of electronic Form 1-N the internet website where such information can be found offer the most efficient means of complying with the requirements of Form 1-N and Rule 6a-4?
11. Do commenters agree with the Commission's belief that the proposed amendments would increase efficiencies and decrease costs compared to current requirements?
12. What, if any, costs would be associated with preparing Form 1-N filings for electronic filing through EDGAR? Are those costs more, less or the same as those currently expended under the current Form 1-N filing process?
13. Do commenters agree with the Commission's belief that structuring the execution page in custom XML would improve the ability to sort, filter, and otherwise organize Form 1-N filings without creating significant additional burden on Form 1-N filers?
14. Should the Commission require structuring other portions of Form 1-N (or the entirety of Form 1-N) rather than
Section 15A of the Exchange Act sets forth the statutory standards for registration as a national securities association or as an affiliated securities association.
Furthermore, under Exchange Act Rule 15Aj-1(a), every association applying for registration or registered as a national securities association must file with the Commission an amendment to its registration statement or any amendment or supplement thereto promptly after discovering any inaccuracy therein. Similarly, under Exchange Act Rule 15Aj-1(b), every association applying for registration or registered as a national securities association, promptly after any change which renders no longer accurate any information contained or incorporated in its registration statement or in any amendment or supplement thereto, must file with the Commission a current supplement to its registration statement setting forth such change.
Finally, under Exchange Act Rule 15Aj-1(c), every association applying for registration or registered as a national securities association must file annual amendments to its registration statement with the Commission.
An applicant for registration as a national securities association is required to file a registration statement and exhibits with the Commission on Form X-15AA-1 in triplicate.
Currently, the information collected by these forms is substantially similar: Form X-15AA-1, the registration statement for registration as a national securities association, requests 29 items of information and includes 3 exhibits;
As discussed in detail below, the Commission proposes to amend Rule 15Aa-1 and redesignate it as Rule 15aa-1,
To facilitate electronic filing of proposed Form 15A, the Commission is proposing to amend Rule 15Aa-1 to require electronic filing. The proposed amendments to Rule 15Aa-1 would require that filing submitted pursuant to Rule 15Aa-1 be filed electronically on EDGAR in accordance with the requirements of Regulation S-T (17 CFR part 232). The proposed amendments to Rule 15Aa-1 would align the electronic filings requirements with changes being proposed under Rule 6a-1 (regarding Form 1 submissions) as well as the proposed amendments to Rule 17ab2-1, which would set forth the proposed electronic filing requirements for Form CA-1 submissions.
The Commission proposes to redesignate Form X-15AA-1 as Form 15A and to incorporate in proposed Form 15A information related to amendments and supplements to the registration statement currently filed on Form X-15AJ-1 and information related to the annual consolidated supplement to the registration statement currently filed on Form X-15AJ-2. The Commission proposes that new Form 15A would solicit information through prompts on the form that would better organize the information that is currently collected through Forms X-15AA-1, X-15AJ-1, and X-15AJ-2, which would make it easier for respondents to comply with the filing requirements. Furthermore, exhibits would be required to be electronically uploaded to EDGAR. The Commission believes that, among other benefits as detailed in the Economic Analysis,
Proposed Form 15A would contain eleven sections. Preceding Section I of proposed Form 15A, the proposed form would contain prompts that would require the association to note the basis for submitting the form. The prompts would indicate whether the submission is an initial application filed pursuant to Rule 15aa-1 or an amendment or supplement—which currently would be filed on Form X-15AJ-1 or X-15AJ-2, respectively—pursuant to proposed Rule 15aa-2. Section I would be titled “Organization,” and it would solicit the following information about the association: (i) its name; (ii) its statutory address, principal executive office address, and the addresses of its branch or district offices (or if there are no such branch or district offices, the association would check the “Not Applicable” box); (iii) the contact information of each person authorized to receive service of process and notices on behalf of the association from the Commission; (iv) the contact information for the association's counsel; (v) the association's form of organization (
Section I also would require the association to attach Exhibits A through D. Exhibit A would require the association to attach copies of its corporate governance documents (
Sections II through IX of proposed Form 15A would solicit information about specific association rules and other information that is currently solicited on Form X-15AA-1. Section II would be titled “Membership” and require the association to cite the specific rule(s) of the association addressing membership requirements, such as any rule restricting membership. Section II would pose the same questions about the association's membership rules as Items 7 through 10 of current Form X-15AA-1. Section III would be titled “Representation of Membership” and require the association to cite the specific rule(s) of the association that assures fair representation of its members, which information is currently solicited in Item 11 of Form X-15AA-1. Section IV would be titled “Dues and Expenses” and require the association to cite the specific rule(s) of the association that provides for the equitable allocation of dues among its members to defray reasonable expenses of administration, which information is currently solicited in Item 12 of Form X-15AA-1.
Section V would be titled “Business Conduct and Protection of Members.” This section would require the association to cite specific rule(s) of the association addressing the protection of members and member conduct with regard to principles of fair trade and
Section VI would be titled “Disciplining of Members” and would require the association to cite the specific rule(s) of the association that addresses member discipline. Section VI would pose the same questions about member discipline as Items 24 and 25 of current Form X-15AA-1. Section VII would be titled “Affiliated Associations” and would require the association to cite the specific rule(s) of the association that provide for the admission of registered affiliated securities associations. Section VII would pose the same question as Item 26 of current Form X-15AA-1. Section VIII would be titled “Miscellaneous” and require the association to cite the specific rule(s) of the association that (i) regulate the dealings of a member with any nonmember broker or dealer and (ii) provide a method for enforcing compliance on the part of its members with the rules of the association. Section VIII of proposed Form 15A would pose the same questions as Items 27 and 28 of current Form X-15AA-1. Section IX would be titled “Additional Information for Registration as an Affiliated Securities Association” and would apply only to applications submitted for registration as an affiliated securities association. Section IX would require the applicant to provide the registered national securities association with which it seeks to be affiliated, its reasons for believing that such affiliation will be granted, and the estimated dollar volume of transactions effected by members of the applicant. Section IX of proposed Form 15A would pose the same questions as Items 29 and 30 of current Form X-15AA-1.
Section X would require the association to provide the contact information for its contact employee, and Section XI would provide the signature block and attestation. Consistent with the proposed amendments to Form 1, Form 1-N, and Form CA-1, the entity filing the proposed Form 15A would consent to service of process to the individuals listed in Section I, item 3, which service of process could be via registered or certified mail. Section XI would also require the filer to represent that the information and statements contained in the form, including exhibits, schedules, or other documents, are current, true, and complete.
In addition, the Commission proposes to amend the instructions for proposed Form 15A to include general directions for preparing and filing the form, describe the seven types of submissions that may be made under proposed Rules 15aa-1 and 15aa-2, and set forth the items, exhibits, and schedules required to be filed for each type of submission.
Finally, proposed Form 15A would require the execution page to be filed in a custom XML data language specific to Form 15A. As with the other Covered SRO Forms, filers would be able to input their execution page disclosures into a fillable web form that EDGAR would subsequently convert to custom XML. The Commission believes structuring the execution page in custom XML would improve the ability to sort, filter, and otherwise organize Form 15A filings, enhancing the ability of the Commission to compare filings from year to year without creating significant additional burden on filers. The remainder of Form 15A would not be structured, however, because the very limited number of Form 15A filers and filings could mitigate the benefit derived from machine-readability of the disclosures contained therein.
15. The Commission requests comment on all aspects of the proposed revisions to Form 15A to facilitate electronic filing in EDGAR. Are there any aspects of transitioning the form to electronic filing that the Commission has not addressed above? Please explain.
16. Do commenters agree with the Commission's belief that the proposed amendments would increase efficiencies and decrease costs compared to current requirements?
17. Do commenters agree that the additional ways that the association could satisfy its filing obligations under the rule would be beneficial? Are there additional methods of satisfying the filing obligation that the Commission should adopt?
18. Do commenters agree with the Commission's belief that structuring the execution page in custom XML would improve the ability to sort, filter, and otherwise organize Form 15A filings without creating significant additional burden on filers?
19. Should the Commission require structuring other portions of Form 15A (or the entirety of Form 15A) rather than only structuring the execution page? Please explain why or why not. If so, which structured data language or languages should be used for structuring the other portions of Form 15A?
Section 17A of the Exchange Act governs the establishment of a national system for the prompt and accurate clearance and settlement of securities transactions.
Rule 17ab2-1(a) states that an application for registration or for exemption from registration as a clearing agency or an amendment to any such application shall be filed with the Commission on Form CA-1, in accordance with the instructions thereto.
Rule 17ab2-1(e) requires that if responses to items 1-3 of Form CA-1 become inaccurate, misleading or incomplete, the registrant shall promptly file an amendment on Form CA-1 to correct the inaccurate, misleading or incomplete information.
The Commission is proposing to revise certain aspects of Rule 17ab2-1, Form CA-1, and the instructions to Form CA-1 to require electronic filing of applications on Form CA-1 and subsequent amendments thereto by applicants, registered clearing agencies, and exempt clearing agencies. The proposed revisions therefore would require: (i) an applicant to file electronically its initial application on Form CA-1 for registration or for an exemption from registration and any subsequent amendments thereto; (ii) a registered clearing agency to file electronically any amendments to its Form CA-1 after being granted registration as a clearing agency; and (iii) an exempt clearing agency to file electronically any amendments to its Form CA-1 after being granted an exemption from registration as a clearing agency. As explained above in the introduction to Section II, the Commission believes that the proposed rule and form revisions should increase efficiencies and decrease costs related to the filing of Form CA-1 and amendments thereto by both registered and exempt clearing agencies, and the Commission's review of filed Forms CA-1 and amendments thereto.
To facilitate electronic filing of Form CA-1, the Commission is proposing to revise Rule 17ab2-1 to require electronic filing. Specifically, the Commission is proposing to revise paragraphs (a), (d), (e), and (f) to reference the method of filing as being electronic, and is adding paragraph (g) to provide specific instructions on the method of filing electronically, including a requirement for an electronic signature (defined as an electronic entry in the form of a magnetic impulse or other form of computer data compilation of any letter or series of letters or characters comprising a name, executed, adopted or authorized as a signature). Additionally, new paragraph (g) would specify a cutoff time of 5:30 p.m. eastern standard time or eastern daylight saving time for purposes of deeming which business day (defined to exclude certain days of the week, holidays, and closures) that a filing occurred. It would also specify that a filing would be deemed timely filed if it is required to be filed on a day that is not a business day and is filed on the next available business day. As stated above in the introduction to Section II, the Commission believes that, among other benefits, its proposal to revise the forms relating to registration as a clearing agency should increase efficiencies and decrease costs incurred by applicants for registration as a clearing agency.
The Commission proposes that electronic Form CA-1 would solicit information through prompts on the form that would better structure the information collected. In addition, the Commission proposes that electronic Form CA-1 would require exhibits to be attached through a new exhibit table that would be part of electronic Form CA-1. The Commission further proposes that all information posted on a website pursuant to electronic Form CA-1 must be free and accessible (without any encumbrances or restrictions) by the general public. The Commission proposes to add prompts prior to Section I of the form that would require the registrant to note the basis for submitting Form CA-1. Specifically, proposed electronic Form CA-1 would require the registrant to check a box stating one of the following: (i) whether the filing is an application pursuant to Rule 17ab2-1(a) and if it is, whether the registrant is applying for registration as a clearing agency
The Commission also proposes to modify Form CA-1 to add a requirement for information about a contact employee. The proposed Form CA-1 would require the name, title, email address and telephone number of an employee prepared to respond to questions about the Form CA-1 submission. The Commission believes that including information about a contact employee would facilitate communication between the registrant and the Commission. Similarly, the Commission proposes to require the email address of the person in charge of the registrant's clearing agency activities. The Commission believes that obtaining that individual's email address would also facilitate communication between the registrant and the Commission.
In addition, the proposed Form CA-1 would require a registrant to electronically attach exhibits by using an exhibit table for all of the exhibits required by the current form, broken down into sections.
The Commission also is proposing to omit item 7(b) from the current Form CA-1. Item 7(b) solicits the following information: as of September 30, 1975, the dollar amount of the potential exposure of registrant, if any, as a result of differences (without offsetting long differences against short differences and without offsetting any suspense account items) in its clearing agency activities not resolved after 20 business days. On December 1, 1975, it became unlawful for any clearing agency—not subject to temporary exemptive relief under Rule 17ab2-1(b) that has since expired—to perform the functions of a clearing agency unless registered or exempt.
The Commission also is proposing to revise the instructions to Form CA-1 to facilitate the electronic filing of Form CA-1. The proposed form instructions would not contain the language in paragraph 2 under Part I of the current form stating that clearing agencies are required to file four completed copies of Form CA-1 with the Commission, or the language in paragraph 4 under Part I of the current form providing instructions relating to the requirements for copies of Form CA-1. Further, the proposed instructions would not contain the language of paragraph 3 under Part I of the current form, which states that “[t]he date on which a Form CA-1 is received by the Commission shall be the date of filing thereof if all the requirements with respect to filing have been complied with.” This language would be inconsistent with the proposed date-of-filing provision to be added to Rule 17ab2-1, which would provide for a 5:30 p.m. eastern standard time or eastern daylight saving time, whichever is currently in effect, on a business day, cutoff for a filing to be deemed filed on the day on which it is submitted.
In addition, existing paragraph 13 under Part III of the current form states that, if an item is amended, the registrant must repeat all unamended items as they last appeared on the page on which the amended item appears and must file four copies of the new page, each with updated and properly completed cover and execution pages. The requirement to repeat unamended items on certain pages relates solely to the filing of amended paper copies and, therefore, the Commission believes it would not be relevant to the proposed electronic filing process. The Commission believes that requiring a registered or exempt clearing agency to electronically file a full exhibit would help facilitate the performance of the Commission's regulatory functions because the Commission would be able to review an amended exhibit to Form CA-1 in its entirety and more easily compare the revised exhibit against the prior version, particularly if numerous, non-consecutive pages are being amended. The proposed Inline XBRL requirement for certain Form CA-1 exhibits would further facilitate this comparison process, because Inline XBRL would allow reviewers to create automated redline comparisons of an exhibit (or specific portion thereof) to a prior version of the same exhibit (or specific portion thereof). Accordingly, the Commission proposes to delete the reference to pagination that is currently in Item III, paragraph 13.
In addition, Form CA-1 and the instructions to Form CA-1 would continue to require a registered or exempt clearing agency to consent to the service of notice of a proceeding under sections 17A or 19 of the Exchange Act involving the registrant. The current language under which the registrant consents to service via registered or certified mail at the address provided on Form CA-1 would continue to be
Finally, Form CA-1 would require a registered or exempt clearing agency to structure Schedule A (descriptive responses complementing the clearing agency's execution page disclosures) and Exhibits C (description of organizational structure), F (description of material pending legal proceedings), H (financial statements), J (description of services and functions), K (description of security measures and procedures), L (description of safeguarding measures and procedures), M (description of backup systems), O (description of, and reasons for, criteria governing access to services), R (prohibitions and limitations on access to services), and S (explanation of requested exemption) in Inline XBRL. The execution page and Exhibits A (persons controlling management or policies, but not the copies of written agreements with such persons), B (officers, managers, and individuals occupying similar positions), D (persons controlled by or under common control with the clearing agency, and description of control relationship), E (dues, fees, and other charges for clearing activities, but not the copies of the constitution, articles of incorporation or association, by-laws, rules procedures, and instruments corresponding thereto), I (office addresses and activities performed in each office), N (participants or applicants for participation), and Q (schedule of fees for services rendered by participants) would also be structured, albeit in a custom XML data language specific to Form CA-1 rather than in Inline XBRL.
The copies of existing documents filed with Exhibits A (copies of written agreements with control persons), E (copies of the constitution, articles of incorporation or association, by-laws, rules, procedures, and instruments corresponding thereto), G (copies of contracts with exchanges, national securities associations, and securities markets), P (copies of contracts governing subscription terms), and T (submissions to the Commission required as directed in any approval order) would be filed as unstructured PDF documents.
The Commission believes the proposed structuring requirements would facilitate access to the clearing agency's disclosures (enabling, for example, more efficient retrieval of only those disclosures filed by a subset of clearing agencies over particular reporting periods) and analysis (such as by comparing individual disclosures or sets of disclosures across clearing agencies and time periods). This could benefit market participants through enhanced oversight of clearing agencies. Market participants (such as broker-dealers, analysts, and other clearing agencies) could also benefit from direct use of the machine-readable disclosures on Form CA-1. For example, institutional investors could leverage the machine-readability of Exhibit J to run automated redlines of a clearing agency's safeguarding procedure descriptions from prior periods, thereby detecting any significant procedural changes that could raise concern.
Without the proposed structured data requirements, performing these types of analyses would need to be done manually, such as by gathering the current and former descriptions of safeguarding procedures for each exchange and entering them all into databases, resulting in a significantly less efficient and precise process. In addition, the proposed structured data requirement would enable EDGAR to perform technical validations (
The nature and extent of such benefits may vary based on the content of each Form CA-1 Exhibit. As discussed in the Economic Analysis, studies of XBRL requirements for public operating company financial statements indicate a number of benefits for investors and market participants.
The Commission is proposing to require Inline XBRL for certain exhibits to Form CA-1 and custom XML for others, because the Commission believes each data language is better suited for particular types of disclosures. Exhibit H requires disclosure of financial statements, and Inline XBRL was designed to accommodate financial statement information, including the particular metadata (
The execution page of Form CA-1, Exhibits A (in part), B, D, E (in part), I, N, and Q do not require such content. For these disclosures, the Commission believes the use of custom XML data languages would be preferable to Inline XBRL, because it would yield smaller file sizes and therefore enable more streamlined processing of the information.
The proposed approach of requiring Inline XBRL for some Form CA-1 exhibits and custom XML for others would entail drawbacks for users of the information (including Commission staff and market participants). Specifically, data users would be unable to incorporate the Inline XBRL disclosures on Form CA-1 into the same datasets and applications as the custom XML disclosures on Form CA-1, and run analyses that incorporate both types of information, without undertaking data conversion processes that are frequently burdensome and imprecise. Similarly, any technical validations programmed into EDGAR would be unable to check for any inappropriate inconsistencies between disclosures on Inline XBRL exhibits and disclosures on custom XML exhibits on a given Form CA-1, thus reducing the benefit of improved data quality that would be likely to result from structured data requirements. Finally, some Form CA-1 filers may already be using Inline XBRL to structure similar data for internal business purposes, such as through the use of ERP systems; these filers may prefer to use Inline XBRL for all proposed structured data requirements of Form CA-1, rather than using a combination of Inline XBRL and custom XML.
The Commission is proposing to require clearing agencies to file copies of existing documents, such as copies of by-laws, written agreements, and contracts governing subscription terms, as unstructured PDF attachments. The Commission believes requiring clearing agencies to retroactively structure these existing documents, which were prepared for purposes outside of fulfilling the Commission's disclosure requirements, would likely impose costly compliance burdens on clearing agencies that may not be justified in light of the commensurate informational benefits associated with more efficient disclosure use. Thus, the Commission does not believe structured data requirements are warranted for these copies of existing documents.
20. The Commission requests comment on all aspects of the proposed revisions to Form CA-1 to facilitate electronic filing in EDGAR. Are there any aspects of transitioning the form to electronic filing that the Commission has not addressed above? Please explain.
21. The Commission has proposed new Section IX to address the submission of any conditions, reports, notices or other submissions to the Commission required as directed in any Order approving an application for exemption from registration as a clearing agency, under Exhibit T. Do the proposed modifications, as described above, appropriately address the wide range of submissions that these types of materials encompass, or is there a type of submission under any Order that would be technologically infeasible to require to be submitted under Section IX in EDGAR? Please explain why or why not.
22. Clearing agencies would be required to prepare certain elements of Form CA-1 filings using Inline XBRL and custom XML. Would clearing agencies experience practical difficulties or incur significant costs in preparing and submitting those elements of Form CA-1 using Inline XBRL and custom XML? If so, please explain the nature of those difficulties and costs as well as any alternative approaches the Commission should adopt.
23. Would requiring different structured data languages for different Exhibits of Form CA-1 provide benefits to data users or filers that justify any drawbacks associated such an approach? Please explain the nature of such benefits and drawbacks, and why the benefits would justify the drawbacks (or vice versa).
24. If a mix of structured data languages would be appropriate, should the specific data languages proposed for each Form CA-1 Exhibit be modified? For example, are there Form CA-1 Exhibits proposed as custom XML documents that would be better suited as Inline XBRL documents, or vice versa? Please explain why or why not.
25. Are there other structured data languages (
26. Would requiring clearing agencies to file copies of existing documents as unstructured PDF attachments, rather than requiring clearing agencies to retroactively structure those documents in machine-readable data languages, ease compliance burdens on clearing agencies? If so, would the reduced compliance burden on clearing agencies justify forgoing the benefits to data users of structuring these existing documents? Please explain why or why not.
Section 19(b) of the Exchange Act, as amended, requires each SRO to file with the Commission, in accordance with such rules as the Commission may prescribe, copies of any proposed rule, or any proposed change in, addition to, or deletion from the rules of such SRO (collectively, a “proposed rule change”) accompanied by a concise general statement of the basis and purpose of such proposed rule change.
As discussed above, Rule 19b-4(e)(1) under the Exchange Act provides that the listing and trading of a new derivative securities product
For purposes of Rule 19b-4(e)(1), SROs have submitted, and the Commission has approved pursuant to section 19(b)(2) of the Exchange Act, trading rules, procedures, and listing standards for several types of new derivative securities products including, for example, exchange-traded funds, index-linked securities and other exchange-traded structured products, and narrow and broad-based index options.
As expressed in the Rule 19b-4(e) Adopting Release, the Commission adopted Form 19b-4(e) in order for the Commission to maintain an accurate record of all new derivative securities products traded on the SROs in order to notify the Commission when an SRO begins to trade a new derivatives securities product not required to be submitted as a proposed rule change to the Commission for approval.
Under Rule 19b-4(e)(2)(ii), SROs are required to submit Form 19b-4(e)
The Commission proposes to amend Rule 19b-4 to rescind Form 19b-4(e) and instead require SROs to post on their internet websites the information currently included on Form 19b-4(e). More specifically, under the proposal, an SRO would be required to post on its public internet website, within five business days after commencing the trading of a new derivatives securities product, the information required in current Part I, Items 2 through 9 of Form 19b-4(e) for that product:
As is required currently in Part II of Form 19b-4(e), an SRO would be required to provide on its website a representation by a duly authorized SRO official that the governing body of the SRO has duly approved, or has duly delegated its approval to such official for, the listing and trading of the new derivative securities product according to its relevant trading rules, procedures, surveillance programs, and listing standards to assure that such products are being listed and traded in accordance with the SRO's obligations under Rule 19b-4(e), as well as an email address to contact that official. The Commission believes that the requirement to provide an email address for the exchange contact employee will expedite communications between Commission staff and the relevant exchange. Any SRO that relies on Rule 19b-4(e) to list and trade a new derivative securities product would continue to be subject to Rule 19b-4(e)(2)(i), which requires the SRO to maintain at its principal place of business a file, available to Commission staff for inspection, of all relevant records and information pertaining to each new derivatives securities product traded pursuant to Rule 19b-4(e) for a period of not less than five years, the first two years in an easily accessible place, as prescribed in Rule 17a-1 under the Exchange Act.
The Commission believes that its proposal will provide the same information for the Commission and the public as is provided via current Form 19b-4(e) without necessitating the additional steps of submitting a paper form containing that information with the Commission. The Commission believes that, among other benefits, this proposal should increase efficiencies and decrease costs related to both the submission of Form 19b-4(e) by an SRO and the Commission's processing of submitted Forms 19b-4(e). As discussed above, since the Commission adopted
27. Would it be appropriate to require the information submitted on current Form 19b-4(e) instead to be posted on the relevant SRO's publicly available internet website? Would there be particular compliance or oversight concerns such a requirement would raise even though the relevant SRO publication of that information would remain subject to existing books and records requirements and the Commission's examination and inspection authority? If so, explain what those concerns are, and why.
28. Should the Commission instead amend Rule 19b-4(e), Form 19b-4(e), and the instructions thereunder to require Form 19b-4(e) to be submitted electronically on EDGAR? If so, explain why.
29. Is there an alternative method for submitting Form 19b-4(e) that the Commission should use instead? If so, explain what such an alternative method would be, and why.
30. What, if any, costs would be associated with posting the information required under proposed Rule 19b-4(e) on the SRO's website? Are those costs more, less, or the same as those currently expended under the current Form 19b-4(e) filing process? Similarly, what costs would be associated with requiring SROs to post Rule 19b-4(e) information using a custom XML data language and associated PDF renderer? Would such costs not justify the benefits associated with such requirements? Please explain why or why not.
31. Would requiring a different structured data language, such as Inline XBRL, for the Rule 19b-4(e) information provide benefits to data users justify any drawbacks associated such an approach? If so, please identify the more appropriate data language, explain the nature of such benefits and drawbacks, and why the benefits would not justify the drawbacks (or vice versa).
32. Should the Commission also amend Rule 19b-4(e) to require that the information submitted on current Form 19b-4(e) be posted on the relevant SRO's publicly available internet website sooner than five business days after commencement of trading a new derivative securities product? Please explain why or why not. Are there any issues, concerns or burdens with shortening the timeframe? If so, please describe. Is there another timeframe earlier than five business days (
Section 19(b) of the Exchange Act, as amended, requires each SRO to file with the Commission, in accordance with such rules as the Commission may prescribe, copies of any proposed rule, or any proposed change in, addition to, or deletion from the rules of such SRO (collectively, a “proposed rule change”) accompanied by a concise general statement of the basis and purpose of such proposed rule change.
The Commission proposes to remove the requirement under 17 CFR 240.19b-4(j) (“Rule 19b-4(j)”)
33. Should the Commission retain the requirement under Rule 19b-4(j) that the signatory to an electronically submitted Form 19b-4 manually sign a signature page or other document authenticating, acknowledging, or otherwise adopting his or her signature that appears in typed form within the electronic filing, execute that document before or at the time the rule filing is electronically submitted, and retain that document for its records in accordance with Rule 17a-1? If so, explain why.
34. Should the Commission retain the related language in Form 19b-4 and the instructions to Form 19b-4 that a duly authorized officer of the SRO manually sign one copy of the completed Form 19b-4 and that the manually signed signature page be maintained pursuant to section 17 of the Exchange Act? If so, explain why.
35. What, if any, costs would be associated with removing the manual signature requirement? Are those costs more, less, or the same as those currently expended under the current Form 19b-4 filing process?
As noted above, the Commission proposes a technical amendment to conform its Informal and Other Procedures to the changes proposed herein to Rules 6a-1, 6a-2, and 6a-3 with respect to Form 1 filings and to Rule 6a-4 with respect to Form 1-N filings. Specifically, the Commission proposes conforming changes to Rules 202.3(b)(2) and (b)(3) of its Informal and Other Procedures
Current Exchange Act Rule 17a-22 requires that within 10 days after issuing, or making generally available, to its participants or to other entities with whom it has a significant relationship, such as pledgees, transfer agents, or SROs, any material (including, for example, manuals, notices, circulars, bulletins, lists or periodicals), a registered clearing agency shall file three copies of such material with the Commission.
In adopting Rule 17a-22 in 1980, the Commission established for clearing agencies a filing requirement that generally paralleled the filing requirements imposed under Exchange Act Rules 6a-3, 15Aj-1, and 17a-21—rules applicable to national securities exchanges, registered securities associations, and the MSRB, respectively, that required the filing of certain supplemental materials.
Since the Updated Staff Statement was issued, registered clearing agencies have been submitting electronic copies of filings required under Rule 17a-22 to the Commission through a dedicated email inbox, rather than submitting paper copies.
The Commission is now proposing to amend Rule 17a-22 to: (i) replace the requirement to file supplementary materials with the Commission or an ARA in paper form with a requirement to post such materials on the clearing agency's internet website; and (ii) reduce the timeframe for compliance with the rule from 10 days to 2 business days for the posting requirement.
Specifically, proposed Rule 17a-22 would require that within 2 business days after issuing, or making generally available, to its participants or other entities with whom it has a significant relationship, any material (including, for example, manuals, notices, circulars, bulletins, lists or periodicals) that is not otherwise required to be posted on its internet website pursuant to any requirement under section 19(b) of the Exchange Act or the rules thereunder, a registered clearing agency shall prominently post such material on its internet website.
The Commission believes reducing the notice timeframe from 10 days to 2 business days is reasonable and appropriate for three reasons. First, the timeframe of 2 business days helps ensure the timely dissemination of information to affected market participants and is consistent with a registered clearing agency's obligation under Rule 19b-4(m) to update its internet website to post any rule changes filed pursuant to Exchange Act Rule 19b-4 within two business days.
Rule 17a-22, as proposed to be amended, does not change the scope of supplemental materials to which the rule applies. Accordingly, the proposed rule retains the language that any supplemental material issued or made generally available to a clearing agency's participants or other entities with whom it has a significant relationship would be subject to Rule 17a-22. The proposed rule retains the list of illustrative examples of types of supplemental materials. In addition, copies of any material issued or made generally available to participants or other entities with whom the clearing agency has significant relationships (
Because the significant relationships vary across clearing agencies, the Commission is proposing to delete the list of examples of such relationships from the proposed rule text. However, the removal of these examples from the text of the proposed rule is not an indication that these entities are no longer considered within the scope of the rule. Rather, the Commission is proposing to eliminate this list to ensure that clearing agencies consider appropriately the universe of entities with whom they have a significant relationship, which varies by registered clearing agency because they serve different markets or offer different services and may also change over time as market practices evolve. The Commission continues to believe that issuers, transfer agents, custodians, service providers, and other non-participant entities that use the clearing agency's services are examples of the types of entities to whom a clearing agency may provide supplementary materials under the rule, and the revisions are intended to avoid confusion because certain types of relationships, such as issuers and transfer agents, exist in some markets but not others. A clearing agency generally should consider the markets it serves, the services it offers, and the universe of entities with whom it has a significant relationship when addressing its compliance with the rule.
While the scope of supplemental materials subject to the rule remains unchanged under the proposed rule, the Commission is adding new rule text to expressly exclude any materials subject to section 19(b) of the Exchange Act or rules thereunder from the supplemental materials posting requirement, and thereby specify that the materials subject to proposed Rule 17a-22 are distinct from any posting requirements required under section 19(b) and Rule 19b-4 thereunder. This proposed added text is consistent with the Commission's stated purpose of Rule 17a-22 in 1980,
Specifically, in the Rule 17a-22 Adopting Release, the Commission also amended, among other things, the requirements applicable to the filing by SROs of proposed rule changes and certain other materials under Rule 19b-4 and Form 19b-4.
The existing requirement under Rule 17a-22 to post only those materials that the clearing agency is “making generally available” would remain unchanged. Any document that is made “generally available” to a wide or diverse group of individuals or entities should be considered supplemental material and as such, posted to the clearing agency's website. Because of the “generally available” component in Rule 17a-22, the Commission does not envision that documents of a confidential or sensitive nature, or that would cause harm if publicly disclosed, would fall within the scope of the rule. Accordingly, the Commission believes that amending Rule 17a-22 to require the posting of supplemental material on an internet website should not create concerns from a clearing agency's perspective regarding privacy or confidentiality of materials because such material would not be in scope of the rule. In the Commission's experience, most, if not all, of the filings required by current Rule 17a-22 are already being posted on a registered clearing agency's website.
Finally, in the proposed amendment to Rule 17a-22 that would require the clearing agency to “prominently post” any supplemental material subject to the amended rule on the clearing agency's website, the Commission is proposing to interpret “prominently” to mean that the supplemental materials will be readily identifiable and accessible on the website for as long as the information remains applicable to affected parties. If access to the supplemental materials requires in-depth familiarity with the website or is not readily apparent because it requires searching through multiple layers to access the information, the supplemental materials generally would not be considered prominently posted. The Commission believes generally that supplemental materials should be available at a prominently posted hyperlink on the clearing agency's website that is free and accessible (without any encumbrances or restrictions) by the general public. To the extent one does not already exist, a registered clearing agency generally should consider creating a specific web page that identifies and catalogues (such as through a list of hyperlinks) the supplemental materials that it maintains pursuant to Rule 17a-22.
36. Would the proposal to replace the requirement to file paper copies with a requirement to post supplemental materials on a clearing agency's website benefit or harm the clearing agencies, market participants or the general public? If so, please describe any benefits or harms. The Commission particularly is interested in comments or analysis related to costs on both a qualitative or quantitative basis.
37. Does the two-business day requirement to post supplemental materials allow for sufficient time to prepare and post the materials? If not, why not? What alternative timeframe would be appropriate and why?
38. The proposed amendment to the rule would require that materials issued or made generally available to clearing agency participants or other entities with whom the clearing agency has a significant relationship to be posted to the clearing agency's internet website. Is the rule as proposed to be amended clear in terms of which participants or entities would be included? Should this group of persons or entities be expanded, contracted or otherwise modified? If so, why, and how? Are there any other concerns related to this requirement, such as with respect to documents that may be confidential or non-public? If so, please describe.
39. The Commission is proposing to require supplemental materials to be “prominently” posted on the clearing agency's website. Is this proposed requirement clear? Should it be modified, and if so, why and how?
40. Should the Commission provide registered clearing agencies with the opportunity to continue the alternate arrangements established pursuant to the Updated Staff Statement, rather than requiring internet posting under the rule? If so, why?
41. What, if any, costs would be associated with preparing documents for posting on the clearing agency's internet website? Are those costs more, less or the same as those currently expending under the current Updated Staff Statement processes? Would the proposed two business day timeframe to post supplemental materials cause any change in the costs associated with complying with the rule? If so, please provide as much detail as possible as to whether such costs increase or decrease, and the underlying reasons for the change.
The Commission proposes that the following forms and reports be filed in electronic format on EDGAR:
Paragraph (d) of Exchange Act Rule 17a-5 generally requires a broker-dealer registered with the Commission to file annual reports with the Commission not more than 60 calendar days after the fiscal year end of the broker-dealer.
Approximately 3,218 broker-dealers file annual reports with the Commission, and the reports vary in size from approximately 20 pages for smaller firms to approximately 100 pages for larger firms. Rule 17a-5 currently provides for paper filing of the annual reports, and paper filings are processed manually by Commission staff. However, the Commission has prepared EDGAR to receive broker-dealer annual reports electronically, and Commission staff issued a no-action letter
Paragraph (e)(2) of Rule 17a-5 provides that the broker-dealer must attach to the financial report an oath or affirmation that, among other things, the financial report is true and correct.
The first sentence of paragraph (e)(3) of Rule 17a-5 provides that the annual reports are not confidential, except that, if the Statement of Financial Condition in a format that is consistent with Part II or Part IIA of Form X-17A-5
Paragraph (k) of Rule 17a-5 requires a broker-dealer that has been approved to use internal models when computing net capital pursuant to Appendix E of Exchange Act Rule 15c3-1
Paragraph (c) of Rule 18a-7, which was modeled on paragraph (d) of Rule 17a-5, generally requires an SBSD or a MSBSP for which there is no prudential regulator and which is not a broker-dealer to file annual reports with the Commission not more than 60 calendar days after the fiscal year end of the entity.
Paragraph (d)(1) of Rule 18a-7 provides that the SBSD or MSBSP must attach to the financial report an oath or affirmation that, among other things, the financial report is true and correct.
The first sentence of paragraph (d)(2) of Rule 18a-7 provides that the annual reports are not confidential, except that, if the Statement of Financial Condition in a format that is consistent with Part II of Form X-17A-5
Paragraph (b) of Rule 17a-12 requires that every OTC derivatives dealer annually file audited financial statements.
Paragraph (c)(2) generally provides that the OTC derivatives dealer must attach to the audited financial statements an oath or affirmation that, to the best knowledge and belief of the person making the oath or affirmation, among other things, the audited financial statements and required schedules are true and correct.
Paragraph (c)(3) of Rule 17a-12 provides that all of the statements filed pursuant to paragraph (b) of Rule 17a-12 are confidential,
Paragraphs (k), (l), and (m) of Rule 17a-12 require that the accountant's report on material inadequacies and reportable conditions, accountant's report on management controls, and accountant's report on inventory pricing and modeling, respectively, be filed concurrently with the annual audit report.
The Commission is proposing amendments to Rules 17a-5, 18a-7, and 17a-12 that would require that the annual reports and related annual filings that firms must file under Rules 17a-5, 18a-7, and 17a-12 be filed with the Commission electronically on EDGAR in a structured data language.
The Commission is proposing to amend paragraph (e)(2) of Rule 17a-5 to add a new paragraph (e)(2)(iii). The new paragraph would provide that the notarized oath or affirmation must be kept “for a period of not less than six years, the first two years in an easily accessible place and in accordance with the requirements of Rule 17a-4.”
In light of the proposed requirement that the annual reports and related annual filings under Rules 17a-5 and 18a-7 be filed electronically on EDGAR, the Commission is proposing amendments to the confidentiality provisions of the first sentence of paragraphs (e)(3) of Rule 17a-5 and (d)(2) of Rule 18a-7. Those sentences contain requirements that certain parts of the reports be “bound separately” and that certain pages be “stamped confidential,” which do not apply to the process of designating portions of the annual reports confidential when filing them on EDGAR.
The Commission is proposing to replace “deemed confidential to the extent permitted by law” with “deemed confidential for the purposes of section 24(b) of the Act” for consistency with the language used in other rules (
The phrase “for which confidential treatment may be requested,” in proposed paragraph (e)(3)(ii)(B) is not in the current rule. This proposed new language is intended to clarify that an EDGAR filer may request confidential treatment, but that ultimately whether any filed material is confidential is determined pursuant to applicable law, including but not limited to the Freedom of Information Act,
Currently, a firm filing annual reports with the Commission under Rules 17a-5, 18a-7, and 17a-12 using EDGAR submits the information contained in a “facing page” to the annual reports by completing an electronically fillable form on the EDGAR system.
Under the proposal, firms filing annual reports or annual supplemental reports with the Commission under Rules 17a-5, 18a-7, and 17a-12 would be required to apply machine-readable Inline XBRL data “tags” to the disclosures contained in those documents before filing them through EDGAR. These data tags can include numerical detail tags (which are used for tagging individual data points) for individual reported numeric values, such as line items on a financial statement, or text block tags for textual narratives, such as the discussions in the notes to financial statements. In complying with the proposed Inline XBRL requirements, filers could use Inline XBRL tagging software to apply Inline XBRL tags to their reports before submitting them to EDGAR, or could employ a tagging service provider to apply the Inline XBRL tags to their reports on their behalf. The Commission expects the proposed structuring requirements would provide informational benefits to users of the disclosures provided in the reports. Specifically, the Commission believes requiring the annual and supplemental reports to be structured would make the information included on the reports more readily accessible for retrieval, aggregation, and comparison across different broker-dealers, OTC derivatives dealers, SBSDs, and MSBSPs, and across different time periods, as compared to an unstructured PDF, HTML, or ASCII format requirement for the reports.
For example, Commission staff could leverage the machine-readability of the computational schedules to automatically flag any mathematical inconsistencies or calculation errors therein. Market participants (such as customers, analysts, or other broker-dealers) could also benefit from direct use of the machine-readable disclosures; for example, analysts could leverage the machine-readability of financial statements to determine which broker-dealers have comparatively high proportions of liabilities due to affiliates. Without the proposed structured data requirements, performing these types of analyses would need to be done manually, such as by gathering the current and former financial statements for each broker-dealer and entering all financial line items of interest into databases, resulting in a significantly less efficient and precise process.
The proposed Inline XBRL requirement would apply to all disclosures required by Form X-17A-5 Part III other than disclosures required on the facing page. Inline XBRL was designed to accommodate financial statement information, including the particular metadata (
The facing page of Form X-17A-5 Part III is currently a fillable form that EDGAR converts into a custom XML data language, and would remain so under the proposal. As a result, data users would be unable to incorporate the custom XML disclosures on the facing page into the same datasets and applications as the Inline XBRL disclosures on the rest of Form X-17A-5 Part III, and run analyses across the differently formatted Form X-17A-5 Part III disclosures, without undertaking data conversion processes that are frequently burdensome and imprecise. Similarly, any technical validations programmed into EDGAR would be unable to check for any inappropriate inconsistencies between disclosures on Inline XBRL exhibits and disclosures on custom XML exhibits on a given Form X-17A-5 Part III, thus reducing the benefit of improved data quality that would be likely to result from structured data requirements. Finally, some Form X-17A-5 Part III filers may already be using Inline XBRL to structure similar data for internal business purposes, such as through the use of ERP systems; these filers may prefer to use Inline XBRL to file the entirety of Form X-17A-5 Part III.
Under section 17(h) of the Exchange Act and Rule 17h-2T, broker-dealers that are part of a holding company structure and that maintain capital of at least $20 million must file quarterly and annual risk assessment reports with the Commission.
Paragraph (a)(2) of Rule 17h-2T requires that the reports be filed with the Commission at its principal office in Washington, DC. The reports must be filed within 60 calendar days of the end of each fiscal quarter, but the year-end financial statements included in the reports may be filed separately from the remainder of the broker-dealer's fiscal fourth quarter report within 105 calendar days of the end of that quarter. Presently, broker-dealers may choose to file these reports on EDGAR.
The Commission proposes amending paragraph (a)(2) of Rule 17h-2T to require that the quarterly and annual risk assessment reports be filed with the Commission electronically through EDGAR. The process used to access EDGAR would be the same used by those broker-dealers voluntarily using EDGAR for their respective quarterly and annual risk assessment reports. As proposed to be amended, the paragraph would also provide that the financial statements required by Item 4 of Form 17-H must be submitted in Inline XBRL.
The Commission believes requiring Form 17-H to be structured would make the information filed on Form 17-H more readily accessible for retrieval, aggregation, and comparison across different broker-dealers. For example, Commission staff could leverage the machine-readability of the financial statements to automatically flag broker-dealers with current asset ratios lower than a certain value, and assess whether any such broker-dealers warrant further examination. Without the proposed structured data requirements, performing these types of analyses would need to be done manually, such as by gathering the current and former financial statements for each Form 17-H filer and entering all financial line items of interest into databases, resulting in a significantly less efficient and precise process. In addition, the proposed structured data requirement would enable EDGAR to perform technical validations (
The proposed Inline XBRL requirement would apply specifically to the financial statements required by Item 4 of Form 17-H. The Commission believes an Inline XBRL would be appropriate for the financial statements, because Inline XBRL was designed to accommodate financial statement information, including the particular metadata (
By contrast, the facing page and Part II of Form 17-H are currently fillable forms that EDGAR converts into a custom XML data language, and would remain so under the proposal. As a result, data users would be unable to incorporate the custom XML disclosures on the facing page and Part II into the same datasets and applications as the Inline XBRL disclosures on Item 4, and run analyses across the differently formatted Form 17-H disclosures, without undertaking data conversion processes that are frequently burdensome and imprecise. Similarly, any technical validations (
The Commission is proposing to require Form 17-H filers to file copies of existing documents, such as copies of organizational charts and risk management procedures, as unstructured PDF attachments. The Commission believes requiring Form 17-H filers to retroactively structure these existing documents, which were prepared for purposes outside of fulfilling the Commission's disclosure requirements, would likely impose costly compliance burdens on broker-dealers without justifying the commensurate informational benefit associated with more efficient disclosure use. Thus, the Commission does not believe structured data requirements would be warranted for these copies of existing documents.
42. Would it be appropriate to require the annual reports or annual supplemental reports that must be filed with the Commission under Rule 17a-5, Rule 18a-7, and Rule 17a-12 to be submitted electronically with the Commission on the EDGAR system? If so, explain why. If not, explain why not. If the Commission requires that the annual reports or annual supplemental reports that must be filed with the Commission under Rule 17a-5, Rule 18a-7, and Rule 17a-12 be submitted electronically with the Commission on the EDGAR system, would it be appropriate to require those annual reports or annual supplemental reports to be filed in a structured data language? If so, explain why. If not, explain why not.
43. Would broker-dealers, OTC derivatives dealers, SBSDs, MSBSPs, or certain of these firms, experience practical difficulties or incur significant costs in preparing and submitting these reports electronically on EDGAR in a structured data language? If so, explain why they would experience difficulties and quantify the costs. What, if any, costs would be associated with requiring these firms to file their annual reports electronically on EDGAR in a
44. Does the current requirement to file annual reports and annual supplemental reports either in paper or via email or on EDGAR (where they are generally uploaded as PDF documents) provide flexibility to broker-dealers, OTC derivatives dealers, SBSDs, or MSBSPs that could be lost if these filings were required to be made electronically on EDGAR in a structured data language? Explain why or why not. Should the Commission instead require that all of the annual reports or annual supplemental reports be filed electronically on EDGAR as PDF documents, as broker-dealers have the option of doing currently under the Annual Reports No-Action Letter? Explain, and identify the costs of these two alternatives.
45. If the Commission requires the annual reports and annual supplemental reports to be filed in a structured data language, should the Commission require broker-dealers, OTC derivatives dealers, SBSDs, and MSBSPs to use Inline XBRL or a custom XML data language for the reports or another structured data language? If not, which data language, if any, should the Commission permit or require and why? If certain firms were not required to file their annual reports and annual supplemental reports using Inline XBRL or a custom XML data language, should they be required to file these reports electronically using PDF format? Would a requirement to file these reports in a structured data language impose additional costs on or create cost efficiencies for these firms as compared to other languages? Would a requirement to file these reports in a structured data language enable the public to analyze the public information in the reports more efficiently and effectively? If yes, how would this efficiency and effectiveness affect investors, securities markets, broker-dealers, OTC derivatives dealers, SBSDs, or MSBSPs? Would a requirement to file these reports in a non-structured data language result in similar benefits for lower costs as compared to a structured data language? Even if the proposal to require these reports to be filed electronically on EDGAR in a structured data language would provide greater benefits as compared to the current requirement to file via paper or on EDGAR in an unstructured data language, would an alternative manner of filing provide even more benefits than the Commission's proposal relative to the costs of the alternative approach? If so, identify the alternative approach and explain why or why not.
46. If the Commission requires the annual reports or annual supplemental reports to be filed in a structured data language on EDGAR, should the Commission apply these requirements to all broker-dealers, OTC derivatives dealers, SBSDs, and MSBSPs? Explain why or why not. If not, identify an alternative and provide empirical support for the alternative. If the structured data requirement should not apply to all of these firms, should the Commission exempt certain firm types? For example, should the Commission apply the structured data requirement to a subset of broker-dealers consisting of some or all of the following types of broker-dealers: (1) broker-dealers that carry customer accounts and receive or hold customer cash and securities; (2) broker-dealers that are OTC derivatives dealers; (3) broker-dealers with a net capital requirement below a certain amount (
47. Would it be appropriate to require ANC broker-dealer and OTC derivatives dealer supplemental reports to be submitted electronically on EDGAR? If so, explain why. If not, explain why not. Would it be appropriate to require ANC broker-dealer and OTC derivatives dealer supplemental reports to be submitted in Inline XBRL? If so, explain why. If not, explain why not. If a different structured data language should be required, explain why. If there should be no structured data language requirement for the ANC broker-dealer and OTC derivatives dealer supplemental reports, explain why not.
48. Would it be appropriate to require Form 17-H to be submitted electronically with the Commission on the EDGAR system? If so, explain why. If not, explain why not. If the Commission requires Form 17-H to be submitted electronically with the Commission on the EDGAR system, would it be appropriate to require Form 17-H to be filed in a structured data language? If so, explain why. If not, explain why not.
49. Would Form 17-H filers experience practical difficulties or incur significant costs in preparing and submitting these reports electronically on EDGAR in a structured data language? If so, explain why they would experience difficulties and quantify the costs. What, if any, costs would be associated with requiring these firms to file Form 17-H electronically on EDGAR in a structured data language? Are those costs more, less or the same as those currently expended to file Form 17-H?
50. Does the current requirement to file Form 17-H either in paper or via email or on EDGAR provide flexibility to Form 17-H filers that could be lost if these filings were required to be made electronically on EDGAR in a structured data language? Explain why or why not. Should the Commission instead require that the entirety of Form 17-H be filed electronically on EDGAR as PDF documents? Explain, and identify the costs of these two alternatives.
51. Would requiring different structured data languages for different Items of Form 17-H provide benefits to data users or filers that justify any drawbacks associated such an approach? Please explain the nature of such benefits and drawbacks, and why the benefits would justify the drawbacks (or vice versa).
52. If a mix of structured data languages would be appropriate, should the specific data languages proposed for each Form 17-H Item be modified? For example, are there Form 17-H Items proposed as custom XML documents that would be better suited as Inline XBRL documents, or vice versa? Please explain why or why not.
53. Would requiring Form 17-H filers to file copies of existing documents as unstructured PDF attachments, rather than requiring filers to retroactively structure those documents in machine-readable data languages, ease compliance burdens on Form 17-H filers? If so, would the benefits to data users of structuring these existing documents justify the reduced compliance burden on Form 17-H filers? Please explain why or why not.
54. Rules 15c3-1, 15c3-3, 17a-4, 17a-5, 17a-11, and 17a-12 require a broker-dealer to send notices to the
The Commission proposes that the following forms, reports and notices be filed or submitted on EDGAR:
Generally, before commencing business activities, a broker-dealer must become a member of an SRO. SROs assist the Commission in regulating the activities of broker-dealers. Rule 17a-19 requires every national securities exchange and registered national securities association to file a Form X-17A-19 with the Commission at its principal office in Washington, DC and with the Securities Investor Protection Corporation (“SIPC”) within five business days of the initiation, suspension, or termination of any member and, when terminating the membership interest of any member, to notify that member of its obligation to file financial reports as required by paragraph (b) of Rule 17a-5.
The instructions to Form X-17A-19 provide that the original of the form must be mailed to the Commission at its principal office and a copy of the form must be mailed to SIPC. Both the original and the copy must be “executed by a manual signature.” Upon the Commission's receipt of a Form X-17A-19 filing, the information is entered into a database, which is regularly shared with the SROs. Commission staff use the information contained in Form X-17A-19 to assign the appropriate SRO as the designated examining authority for the member firms. This information is also used by SIPC in determining which SRO is the collection agent for the SIPC Fund.
The Commission proposes to amend this requirement to provide that Form X-17A-19 must be filed with the Commission electronically on EDGAR in accordance with the EDGAR Filer Manual, as defined in Rule 11 of Regulation S-T, and in accordance with the requirements of Regulation S-T. Accordingly, Form X-17A-19 would be filed in a custom XML-based data language.
The Commission expects the proposed custom XML requirement for filing Form X-17A-19 would provide similar benefits to those described for the proposed Inline XBRL requirements for Form X-17A-5 Part III.
The Commission also proposes making conforming amendments to the “General Instructions” to Form X-17A-19. Instruction 2 would be amended to replace the instruction to mail the original of the form to the Division with an instruction to file the original “electronically on EDGAR in accordance with the EDGAR Filer Manual, as defined in Rule 11 of Regulation S-T (§ 232.11) and in accordance with the requirements of Regulation S-T.” Instruction 2 would also be amended to instruct filers to send copy number 1 of Form X-17A-19 to SIPC at SIPC's updated address. Instruction 3 would be amended to replace the words “shall be executed with a manual signature” with the words “shall be signed.” Instruction 4 would be deleted (and subsequent instructions would be renumbered accordingly), because the instruction about what to do if there is insufficient space in the form is unnecessary if the filing is submitted on EDGAR. Renumbered instruction 6 (formerly instruction 7) would be amended to provide that copies of the form may be obtained “on the Commission's website” instead of “from the main office of the Securities and Exchange Commission in Washington, DC”
55. Would it be appropriate to require Form X-17A-19 to be filed with the Commission electronically on EDGAR? If so, explain why. If not, explain why not. Would it be appropriate to require Form X-17A-19 to be filed in a custom XML-based data language? If so, explain why. If not, explain why not. What alternative approaches would be appropriate instead?
The Commission's rules under the Exchange Act define when a person is an SBSD.
One of the conditions to the ANE Exception is that all ANE Activity for which the non-U.S. person is relying on the exception (the “Relying Entity”) be conducted by the U.S. personnel in their capacity as persons associated with a majority-owned affiliate
The ANE Exception also is subject to a cap on the amount of certain inter-dealer security-based swaps positions.
The Commission is proposing an amendment to Exchange Act Rule 3a71-3(d)(1)(vi) to change the method of filing the ANE Exception Notice. Instead of filing the notice via email to an electronic mailbox specified on the Commission's website, the proposed amendment would require the Registered Entity to file the notice electronically through the Commission's EDGAR system. For all Registered Entities, only the manner of filing an ANE Exception Notice, and not its content, would change. The ANE Exception Notice would continue to consist of the name of the Registered Entity whose associated persons may conduct activity covered by the ANE Exception, the fact that those associated persons may conduct such activity, and the date. ANE Exception Notices filed electronically on EDGAR also would be permitted, but not required, to include contact details of a person or department at the Registered Entity that counterparties may contact regarding the ANE Exception. Each ANE Exception Notice thus contains a minimal amount of information. As of January 31, 2023, only three Registered Entities had filed an ANE Exception Notice, and the Commission estimates that up to 24 entities that engage in security-based swap dealing activity may rely on the ANE Exception.
The proposed change would require the Registered Entity to have EDGAR access credentials and the ability to file electronically via EDGAR. The Commission believes that requiring submission of ANE Exception Notices electronically through EDGAR is appropriate because most Registered Entities should already have access to EDGAR by virtue of having used the system to register or file information with the Commission,
The Commission believes that requiring an ANE Exception Notice to be filed electronically on the Commission's established EDGAR filing system would, among other things, facilitate more efficient and timely transmission and dissemination of information and would benefit the Commission, the Registered Entities, the Relying Entities, and other market participants.
The proposed amendment to Exchange Act Rule 3a71-3(d)(1)(vi) would include a new mechanism for withdrawing the ANE Exception Notice filed through EDGAR. Currently, a Registered Entity whose associated persons will no longer conduct ANE Activity pursuant to the ANE Exception and who wishes to withdraw a filed ANE Exception Notice may contact the Commission to request that the notice be manually removed from the ANE Exception Notices web page.
The Commission's proposal to move the ANE Exception Notice to EDGAR would require the Registered Entity to file any withdrawal electronically via EDGAR. If the original ANE Exception Notice was filed on EDGAR, it would not be removed from EDGAR; rather, a withdrawal filing on EDGAR would identify the notice as no longer active.
56. Should the Commission require ANE Exception Notices, and withdrawals of ANE Exception Notices, to be filed electronically on EDGAR? Explain why or why not.
57. Does the current requirement to file this information via email provide flexibility to Registered Entities, or promote efficiency for Relying Entities and other market participants who use the information in the ANE Exception Notices, that could be lost if these filings were required to be made electronically on EDGAR? Explain why or why not.
58. Would Registered Entities experience any practical difficulties in preparing and filing an ANE Exception Notice or withdrawal of an ANE Exception Notice on EDGAR as proposed? Explain why or why not.
59. Does any market participant that acts, or expects to act, as a Registered Entity for purposes of the ANE Exception not have, or expect not to have, EDGAR access credentials? If yes, describe any burdens that the Registered Entity would face in obtaining EDGAR access credentials and explain whether the benefits of mandatory EDGAR filing—for the Registered Entity, the Relying Entity, other users of the ANE Exception Notices, and the Commission—justify those burdens.
60. Would Relying Entities and/or other market participants that use the information in the ANE Exception Notices experience any practical difficulties in accessing or utilizing information in ANE Exception Notices and withdrawals of ANE Exception Notices on EDGAR? Explain why or why not. Would Relying Entities and/or other market participants that use the information in the ANE Exception Notices experience greater efficiency in identifying currently active ANE Exception Notices on EDGAR? Would these users find it helpful to be able to search for previously filed and withdrawn ANE Exception Notices? Explain why or why not.
61. Should an alternative manner of filing ANE Exception Notices and withdrawals of ANE Exception Notices be required? Even if the proposal to require these filings to be made electronically on EDGAR would provide greater benefits as compared to filings made via email, would an alternative manner of filing provide even more benefits than the proposal? Please describe any alternative manner in detail and assess how the alternative would impact Registered Entities, Relying Entities, other market participants, and the Commission. For example, should the Commission instead permit, but not require, ANE Exception Notices to be filed electronically on EDGAR? Should the Commission instead retain the current email-based filing system? Should the Commission implement another method for filing ANE Exception Notices and withdrawals of ANE Exception Notices?
62. Should the Commission require or allow a specific unstructured or structured data format for ANE Exception Notices and withdrawals of ANE Exception Notices? If yes, describe the format and why it is appropriate. If no, explain why not.
63. Should the Commission require a Registered Entity to promptly withdraw its ANE Exception Notice if it becomes unregistered or otherwise ineligible to serve as the Registered Entity for purposes of the ANE Exception? If yes, explain how this withdrawal information would be useful to Registered Entities, Relying Entities and/or other market participants. If no, explain how Relying Entities and other market participants could use other methods to determine that any particular Registered Entity is eligible or ineligible, particularly if the Registered Entity is a broker who must comply with certain capital requirements to maintain eligibility.
64. Should the Commission allow Registered Entities to file ANE Exception Notices and/or withdrawals of ANE Exception Notices on paper in case of a temporary or continuing hardship in accordance with Rules 201 and 202 of Regulation S-T?
65. What, if any, costs would be associated with preparing ANE Exception Notices and withdrawals for filing on EDGAR? Are those costs more, less or the same as those under the current filing processes?
66. How does the cost of the proposed amendments to Rule 3a71-3(d)(1)(vi) compare to the cost of current requirements and the cost of the alternatives described above or other alternatives?
Rule 15fi-3 under the Exchange Act generally requires SBS Entities to: (1) engage in periodic portfolio reconciliation activities with counterparties who are also SBS Entities; and (2) establish, maintain, and follow written policies and procedures reasonably designed to ensure that they engage in periodic portfolio reconciliation with counterparties who are not SBS Entities with respect to their outstanding (and uncleared) security-based swaps.
Rule 15fi-3 also contains a reporting requirement. Specifically, Rule 15fi-3(c) requires each SBS Entity to promptly
SBS Entities are also required to notify the Commission and any applicable prudential regulator if the amount of any security-based swap valuation dispute that was the subject of a previous notice increases or decreases by more than $20,000,000 (or its equivalent in any other currency), at either the transaction or portfolio level.
Rule 15fi-3(c) requires that the notices to the Commission be submitted “in a form and manner acceptable to the Commission.” When the Commission first proposed Rule 15fi-3(c), the Commission explained that including the phrase “in a form and manner acceptable to the Commission” was intended to provide SBS Entities with flexibility to determine the most efficient and cost-effective means of making such submissions, so long as it is deemed to be acceptable by the Commission.
Security-based swap valuation dispute notices are not required to include specific fields. However, SBS Entities are encouraged to include in the notice basic information about the security-based swap valuation dispute, including: (1) identifying information about both counterparties (including each party's Legal Entity Identifier); (2) the date of the dispute (or the termination date, if applicable); (3) the type of dispute; (4) disclosure about which counterparty is the receiver and which is the payer; and (5) the disputed amount, in U.S. Dollars (“USD”).
Based on the Commission's experience over the course of implementing Rule 15fi-3(c), the Commission believes that it is now appropriate to require that the security-based swap valuation dispute notices be submitted to the Commission electronically on EDGAR using a structured data language. Accordingly, the Commission is now proposing to amend Rule 15fi-3(c) to affirmatively require SBS Entities to submit these notices electronically in EDGAR using a custom XML-based data language specific to the notices.
The Commission believes that requiring submission of security-based swap valuation dispute notices electronically on EDGAR and in a structured data language is appropriate at this time for at least three reasons. First, an SBS Entity should already have access to EDGAR (and have already
Second, the Commission understands that the security-based swap valuation dispute notices may contain information that is sensitive to one or both of the counterparties. The Commission does not intend for these notices to operate as a means for providing public disclosure of security-based swap valuation disputes. To the extent that the notices provided to the Commission include confidential information that is otherwise not publicly available, the SBS Entity can request the confidential treatment of the information.
Third, the Commission expects that the proposed requirement to submit security-based swap valuation dispute notices in a structured data language would enable the Commission to analyze the information in those notices more efficiently and effectively. Under the current requirements, should Commission staff seek to analyze the dispute notice information (such as to identify trends in the incidence and magnitude of disclosed valuation disputes across SBS Entities or a given population thereof), the analysis would require significant manual effort because the notices are not machine-readable. In addition, the proposed structured data requirement would enable EDGAR to perform technical validations (
Under the proposal, SBS Entities would no longer be permitted to submit PDF versions of dispute notices to the Commission. SBS Entities currently may email or submit on EDGAR PDF versions of dispute notices, and in some cases these notices may have been prepared using systems that were designed also to comply with NFA swap valuation dispute notice requirements. The proposal to require SBS Entities to submit security-based swap valuation dispute notices to the Commission in a structured data language would not allow SBS Entities to continue to upload notices in a non-machine-readable, unstructured data language, and instead would require SBS Entities to format these notices using a custom XML-based data language.
As a general matter, the Commission believes that the type of information that Swap Entities are currently required to include in the valuation dispute notices pursuant to the NFA Swap Valuation Dispute Guidance should generally satisfy what the Commission believes to be one of the primary objectives of Rule 15fi-3(c), which is to inform the Commission and its staff that such a dispute has arisen, allowing the Commission and staff to consider whether additional follow-up is warranted. Accordingly, as a general matter, the Commission believes it is likely that a timely notice provided to the Commission with respect to a security-based swap valuation dispute would satisfy Rule 15fi-3(c), as proposed to be amended, if it continued to contain the information currently required by the NFA Swap Valuation Dispute Guidance (but for the fact that such notice pertains to a security-based swap).
Consistent with this approach, the Commission's custom XML-based data language would include discrete XML elements for each of the encouraged disclosures listed above, and the associated fillable web form on EDGAR would contain discrete fields mirroring those XML elements. However, to provide the flexibility inherent to the Commission's approach to dispute notices, the custom XML data language (and associated fillable web form) would also contain an XML element (and fillable field) to capture any information provided by SBS Entities that does not fall within the encouraged disclosures listed above. For the same reason, the custom XML data language for dispute notices would permit SBS Entities to refrain from populating one or more of the XML elements (and associated fillable fields) that reflect the encouraged disclosures if responsive information is not needed to report the dispute.
67. Should the Commission require security-based swap valuation dispute notices and amendments, including
68. Does the current requirement to submit security-based swap valuation dispute notices and amendments to the Commission via either email or EDGAR provide flexibility to SBS Entities that could be lost if these submissions were required to be made electronically on EDGAR in a structured data language? Explain why or why not.
69. Would SBS Entities experience practical difficulties in preparing and submitting these notices electronically on EDGAR in a structured data language? If so, explain why.
70. What, if any, costs would be associated with valuation dispute notices for submission on EDGAR? Are those costs more, less or the same as those currently expending under the current submission processes?
71. Should the Commission instead require that security-based swap valuation dispute notices, and amendments (including dispute termination notices) be submitted through a different process, such as by email to a dedicated mailbox? If so, explain why and whether such process should be adopted in lieu of requiring the notices to be submitted electronically on EDGAR system in a structured data language, or as a non-exclusive alternative (as is currently the case). How would that process affect costs and implementation of the proposed amendment to Rule 15fi-3(c) as compared to the current requirements?
72. Even if the proposal to require these notices to be submitted to the Commission electronically on EDGAR in a structured data language would provide greater benefits as compared to the current requirement to submit via email or EDGAR in an unstructured data format, would an alternative manner of submission provide even more benefits than the proposal, or be more appropriate? Why would an alternative manner of submission be appropriate or more appropriate? Please describe any alternative manner in detail and assess how the alternative would impact SBS Entities, security-based swap markets and the Commission. For example, should the Commission instead permit, but not require, security-based swap valuation dispute notices to be submitted electronically on EDGAR in structured data language? Should the Commission instead retain the current email-based submission system and/or the current unstructured data format for these reports made on EDGAR? Should the Commission implement another method for submitting security-based swap valuation dispute notices and amendments, including notices of dispute termination? How would these or other alternatives affect costs and implementation of the proposed amendment to Rule 15fi-3(c) as compared to the current requirements?
73. Should the Commission require security-based swap valuation dispute notices, and amendments, including notices of dispute termination, to be made in a structured data language? If yes, should the Commission require SBS Entities to use a custom XML data language for these reports or another structured data language? If no, which data language should the Commission permit these reports to use and why? Would a requirement to submit these reports in a structured data language impose additional costs on, or create cost efficiencies for, SBS Entities as compared to other (non-structured) data languages? Please explain the benefits and costs of a requirement to submit these reports in a non-structured data format, as compared to the benefits and costs of requiring them in a structured data language.
Rule 15fk-1(c) requires that the chief compliance officer (“CCO”) of an SBS Entity prepare and sign an annual compliance report (“CCO report”) that must be submitted to the Commission within 30 days following the deadline for filing the SBS Entity's annual financial report with the Commission pursuant to section 15F of the Exchange Act and the rules and regulations thereunder.
To facilitate submission of the CCO reports, the Commission has prepared the EDGAR system to receive the reports electronically. The Commission is proposing to amend Rule 15fk-1(c)(2)(ii)(A) to require the CCO report to be submitted electronically in Inline XBRL (
74. Should the Commission require CCO reports to be submitted electronically with the Commission through the EDGAR system in a structured data language? Explain why or why not.
75. Would SBS Entities experience practical difficulties in preparing and submitting CCO reports electronically on EDGAR in a structured data language? If so, explain why.
76. Should the Commission instead require that CCO reports be submitted through a different process or format? If so, explain why and whether such process or format should be adopted in lieu of requiring CCO reports to be submitted electronically on EDGAR system in a structured data language.
77. Even if the proposal to require CCO reports to be submitted electronically on EDGAR in a structured data language would provide greater benefits as compared to submitting via email or on EDGAR in an unstructured data language, would an alternative manner of submitting provide even more benefits than the proposal, or be more appropriate? Please describe any alternative manner in detail and assess how the alternative would impact SBS Entities, security-based swap markets and the Commission. For example, should the Commission instead permit, but not require, CCO reports to be submitted electronically on EDGAR in structured data language? Should the Commission require a different structured data language, such as custom XML, for the CCO reports? Should the Commission implement another method for filing CCO reports?
78. Would a requirement to submit CCO reports in a structured data language impose additional costs on, or create any benefits for, SBS Entities as compared to other (non-structured) data languages? How would the benefits and costs of a requirement to submit CCO reports in an unstructured data language compare to the benefits and costs of a requirement to submit in a structured data language?
Until 2021, broker-dealers were the only entities required to file Parts II and IIA of Form X-17A-5, the FOCUS Report, which are used to report unaudited financial and operational information on a monthly or quarterly basis. In 2019, as part of a new regime to regulate security-based swap activity, the Commission amended FOCUS Report Part II to: (1) elicit additional information about the security-based swap activities of broker-dealers that file Part II; (2) add OTC derivatives dealers and SBS Entities that are not dually registered as broker-dealers (“stand-alone SBS Entities”) as additional filers for FOCUS Report Part II; and (3) adopt new FOCUS Report Part IIC to be filed by SBS Entities with a prudential regulator (“bank SBS Entities”).
In the Calculation of Minimum Net Capital Requirement in the Computation of Minimum Regulatory Capital Requirements section of the FOCUS Report Part II, firms have noted that Rule 15c3-1
The Commission is also proposing amendments to the FOCUS Report Part II income statement. Currently, the income statement only provides fields for reporting revenue from securities commissions, even though firms may generate revenue from other types of commissions (
CFTC rules permit a firm that is registered with the CFTC as an introducing broker, an FCM, or a swap dealer, and also registered with the Commission as a broker-dealer or SBS Entity, to file the FOCUS Report in lieu of the unaudited financial reports required under the CFTC regulations.
While CFTC FCMs are required to complete the Computation of CFTC Minimum Capital Requirements section of FOCUS Report Part II, the FOCUS Report does not instruct CFTC introducing brokers or swap dealers not also registered as an FCM (“stand-alone introducing brokers” or “stand-alone swap dealers,” respectively) to complete this section of the form. Therefore, the Commission proposes to require CFTC-registered introducing brokers and swap dealers (that are also registered with the Commission as a broker-dealer or SBS Entity) to complete the Computation of CFTC Minimum Capital Requirements section of FOCUS Report Part II.
In 2019, the Commission adopted FOCUS Report Part IIC, a new unaudited financial report to be filed by bank SBS Entities.
However, since FOCUS Report Part IIC was adopted, FFIEC Form 031 has been updated to, among other things, reflect changes in the prudential regulators' capital rules and generally accepted accounting principles.
Most broker-dealers file the FOCUS Report electronically on the FINRA eFOCUS system developed by the Financial Industry Regulatory Authority, Inc. (“FINRA”). These broker-dealers file the FOCUS Report pursuant to a plan established by the broker-dealer's SRO, the procedures and provisions of which have been submitted to and declared effective by the Commission pursuant to paragraph (a)(3) of Exchange Act Rule 17a-5.
OTC derivatives dealers are a type of broker-dealer that engages in limited securities activities and is exempt from SRO membership.
The cover pages of Parts II, IIA, and IIC of the FOCUS Report include signature lines for the filer's principal executive officer, principal financial officer, and principal operations officer (or their comparable officers).
The Commission also proposes to allow signatories on Rule 17a-5, 17a-12, and 18a-7 filings to choose between providing either manual or electronic signatures.
The Commission proposes that the signing process for an electronic signature would need to, at a minimum: “(1) Require the signatory to present a physical, logical, or digital credential that authenticates the signatory's individual identity; (2) Reasonably provide for non-repudiation of the signature; (3) Provide that the signature be attached, affixed, or otherwise logically associated with the signature page or document being signed; and (4) Include a timestamp to record the date and time of the signature.”
79. Are there any lines in the FOCUS Report Parts II, IIA, or IIC that should be added or removed because they result in inaccuracies or inconsistencies with other portions of the FOCUS Report? If so, identify the lines and explain why they should be added or removed. For example, should the Commission update Line 10 (Market risk exposure—for Basel 2.5 firms) of the Computation of Net Capital (Filer Authorized to Use Models) section of FOCUS Report Part II to reflect that firms are now using Basel 3? If so, explain why how Line 10 should be updated, and why. Are there any lines in the FOCUS Report that require further clarification or instruction? If so, identify the lines and explain the needed clarification or instruction.
80. The Commission is proposing amendments to FOCUS Report Part II. Do commenters agree or disagree with these proposed amendments? Explain why or why not. Should the Commission adopt its proposal to amend the Calculation of Minimum Net Capital Requirement subsection to include 4% of funds required to be segregated under the CFTC's rules even though the CFTC's rules no longer include the 4% of segregated funds ratio requirement? If so, what should the 4% of segregated funds be defined with respect to? If not, what standard should be used, and should Rule 15c3-1 be amended for consistency with the FOCUS Report? Explain. What, if any, costs would be associated with adopting the proposed amendments to FOCUS Report Part II? Are those costs more, less or the same as not amending the FOCUS Report? How do firms currently complete the Calculation of Minimum Net Capital Requirement subsection, and why? Should the reference to the CFTC's ratio net capital requirement be added to the Commission's ratio net capital requirement, or should firms be instructed to apply the greater of the CFTC or Commission ratio net capital requirements? Explain.
81. Please address whether the proposed amendments would be appropriate, and discuss any potential alternatives to the proposed amendments. For instance, as an alternative to amending the FOCUS
82. As a second alternative to amending the FOCUS Report to include the 4% of segregated funds ratio amount, should the Commission replace the references to the CFTC's segregated ratio requirement with the ratio requirement currently used in the CFTC rules? For example, should the capital requirements for FCMs referenced in existing paragraph (a)(1)(iii) of Rule 15c3-1 be modified to refer to “the FCM's risk-based capital requirement pursuant to the Commodity Exchange Act (7 U.S.C. 1
83. Should the Commission amend FOCUS Report Part IIC to align with FFIEC Form 031? Explain why or why not. If the prudential regulators make further amendments to FFIEC Form 031 before the Commission issues an adopting release, if any (
84. The Commission is proposing four minimum standards that an electronic signature must satisfy. Should the Commission specify standards for electronic signatures? Explain why or why not. Instead of proposing the four minimum standards, should the Commission instead rely the E-Sign Act's more general definition of a digital signature (which is consistent with the four minimum standards)?
85. The Commission is proposing to require two of the three signature lines to be signed on the cover page of the FOCUS Report. Do commenters agree? Explain, and if not, identify an alternative approach. Should the Commission require all three signature lines to be signed? Should the Commission require two of the three signature lines to be signed as a general rule, but allow only one of the three signature lines to be signed when FINRA permits a single person at the broker-dealer to fill two of the roles identified on the signature lines? Explain why or why not. What, if any, costs would result from adopting the proposal to require two of the three signature lines to be signed on the cover page of the FOCUS Report?
86. The Commission is proposing to require OTC derivatives dealers to file their FOCUS Reports on the SEC eFOCUS system. What would be the burden of requiring OTC derivatives dealers to file their FOCUS Reports on the SEC eFOCUS system maintained by FINRA? Explain. Should the Commission require OTC derivatives dealers to file their FOCUS Reports on another electronic platform, such as the Commission's EDGAR system? Explain why or why not. What, if any, costs would result from requiring OTC derivatives dealers to file their FOCUS Reports on the SEC eFOCUS system, as compared to allowing these firms to file by paper or on EDGAR?
The Commission is proposing to amend Rule 101(a) of Regulation S-T to designate Form X-17A-5 Part III, broker-dealer supplemental reports filed pursuant to paragraph (k) of Rule 17a-5, OTC derivatives dealer supplemental reports filed pursuant to paragraphs (k), (l), and (m) of Rule 17a-12, Form 17-H, Form X-17A-19, notices (and withdrawals of notices) filed pursuant to Rule 3a71-3(d)(1)(vi), notices (and amendments, including notices of dispute termination) submitted to the Commission pursuant to Rule 15fi-3(c), and compliance reports submitted with the Commission pursuant to Rule 15fk-1(c)(2)(ii)(A) (“Covered EDGAR Documents”) as mandated electronic
Regulation S-T, in conjunction with the EDGAR Filer Manual and other applicable rules, regulations, and forms, governs the electronic submission of documents filed with or otherwise submitted to the Commission on EDGAR.
These proposed amendments would incorporate the new electronic submission requirements into the existing structure of Regulation S-T and would ensure that the EDGAR rules in Regulation S-T apply to the forms and other documents proposed to be submitted electronically on EDGAR.
The Commission is also proposing amendments to Rule 405 of Regulation S-T to implement the proposed Inline XBRL requirements. Rule 405 sets forth the Interactive Data File requirements for Commission filings, and specifies that Inline XBRL is the structured data language that must be used for Interactive Data Files.
For Form CA-1, Schedule A and Exhibits C, F, H, J, K, L, M, O, R, S would be filed in Inline XBRL.
In 2009, the Commission adopted rules requiring operating company financial statements (including footnotes and schedules thereto) and mutual fund risk return summaries to be provided in a structured, machine-readable data language using eXtensible Business Reporting Language (“XBRL”).
The Commission is proposing to require some or all of each Covered SRO Form, the information required by Exchange Act Rule 19b-4(e), Form X-17A-19, Form X-17A-5 Part III, Form 17-H, and the notices to the Commission (and any amendments to the notices) required by Exchange Act Rule 15fi-3(c) to be provided in custom XML-based data languages rather than in Inline XBRL.
In addition to the custom XML documents that the Commission currently requires registrants to file on EDGAR, the Commission separately requires broker-dealers to post reports on order routing and execution on their own websites (
The Commission believes that requiring the Proposed Structured Documents to be filed or submitted in a structured data language would provide the same benefits to data users that have been observed from other structured data requirements in Commission rules. For example, structured data requirements for the aforementioned broker-dealer order routing disclosures have been leveraged by financial academics to compare execution quality across broker-dealers.
Structuring each Proposed Structured Document would enable functionality that would vary based on the type of disclosures included in each document. As discussed further in the discussion of individual proposed forms above, and the discussion of economic benefits below, structured numeric disclosures lend themselves to mathematical functionality, such as the identification of statistical outliers within a given disclosed metric to screen for potential areas of greater scrutiny.
The Commission is proposing Inline XBRL for certain affected documents and portions or portions thereof, rather than proposing Inline XBRL for all affected documents, because the Commission believes Inline XBRL is more suitable for certain types of content than other types. Specifically, the Commission believes Inline XBRL is most suitable for financial statement disclosures (including footnotes and schedules thereto), for narrative disclosures (other than brief descriptions), and for disclosures of numeric details nested within narrative disclosures. From a technical standpoint, Inline XBRL was designed to accommodate financial statement information, including the particular metadata (
For those affected documents where filers are required to attach copies of
Because the very limited number of Form 1-N and Form 15A filers and filings could mitigate the benefit derived from machine-readability of the disclosures contained therein, structured data would not be required for Forms 1-N and 15A (other than the execution pages of those Forms). Similarly, structured data for ANE Exception Notices would not be required, because the limited number of data points on such notices may lessen the utility of any functionality enabled by structured data (such as efficient retrieval of individual data points from structured documents).
For each proposed structured data requirement, the Commission is specifying the particular structured data language that filers or submitters must use, rather than leaving the data language requirement open-ended. By contrast, an open-ended data language requirement would allow different filers or submitters of the same document to provide their disclosures in different structured data languages. In such instances, data users such as Commission staff and market participants would be unable to incorporate disclosures from filers or submitters using one data language into the same datasets and applications as disclosures of other filers or submitters using different data languages without undertaking data conversion processes that are frequently burdensome and imprecise. This may hinder investors, the Commission, and market participants from efficiently comparing disclosures across the comprehensive set of entities comprising a given entity population, and could therefore dampen the benefits that would otherwise accrue from requiring the disclosures to be machine-readable.
Rule 24b-2 provides procedures that are the exclusive means for requesting confidential treatment of information required to be filed under the Exchange Act.
The Commission is also proposing to add a new paragraph (k) to Rule 24b-2. The new paragraph would provide that an entity shall not omit the confidential portion from the material filed in electronic format on Form CA-1 pursuant to Rule 17ab2-1, but rather may request confidential treatment of information provided on Form CA-1 by completing Section X of Form CA-1. The proposed amendment to Rule 24b-2 will facilitate the filing of any information for which confidential treatment is requested.
87. The Commission is requesting comments on all aspects of this proposal. As stated above, the Commission believes that replacing the current paper copy and email filing and submission methods with a requirement to post the required supplemental materials on the clearing agency's website should result in enhanced efficiency for both the affected filers and the Commission. The Commission also believes that rescinding Form 19b-4(e) and instead requiring the information currently contained in Form 19b-4(e) to be publicly posted on the listing SRO's internet website should result in enhanced efficiency for both SROs and the Commission. The Commission specifically requests comment on whether the proposal would reduce the costs associated with providing these forms and information, or would they create additional costs or burdens associated with these forms and information.
88. In addition to the proposed amendments to Regulation S-T, should the Commission amend any of the other requirements of Regulation S-T given the filings and submissions proposed to be added to Rule 101(a) of Regulation S-T? If so, why should the requirements be revised, and how should they be revised?
89. The Commission also requests comment on how long filers or submitters of Covered SRO Forms, Forms 19b-4(e), supplementary materials under Rule 17a-22 and Covered EDGAR Documents should have to come into compliance with the proposed amendments. In addressing this issue, specific comment, data, or other information is requested regarding the amount of time that filers or submitters would need to come into compliance in an orderly manner. Would filers or submitters be able to comply with some of the proposed amendments more quickly than they would be able to comply with other proposed amendments? Please identify the aspects of the proposed amendments that would require relatively more or less time to comply. Would a particular segment of filers or submitters need more or less time to comply with one or more of the proposed amendments? Please identify with specificity the segment of filers or submitters and the aspects of the proposed amendments that would require more or less time to comply. Would any alternatives identified in the proposal or by commenters allow filers or submitters to come into compliance more quickly or require additional time to implement?
90. Beyond the forms captured in this current proposed rule, would other forms or filings required under the Exchange Act and its associated rules and regulations benefit from a Commission requirement that they be submitted through the EDGAR system in a structured data language? Explain which forms would benefit from this requirement and why.
91. Commenters should, when possible, provide the Commission with empirical data to support their views. Commenters suggesting alternative approaches should provide comprehensive proposals, including any conditions or limitations that they
Certain provisions of the proposal contain “collection of information” requirements within the meaning of the Paperwork Reduction Act of 1995 (”PRA”).
• Form ID (OMB Control No. 3235-0328)
• Rules 6a-1 and 6a-2, Form 1 (OMB Control No. 3235-0017);
• Rule 6a-3 (OMB Control No. 3235-0021);
• Rule 6a-4, Form 1-N (OMB Control No. 3235-0554);
• Rules 15aa-1 and 15aa-2, Form 15A (OMB Control No. 3235-0030);
• Rule 17ab2-1, Form CA-1 (OMB Control No. 3235-0195);
• Rule 19b-4(e), Form 19b-4(e) (OMB Control No. 3235-0504);
• Rule 19b-4, Form 19b-4 (OMB Control No. 3235-0045);
• Rule 17a-22, 17 CFR 240.17a-22 (OMB Control No. 3235-0196);
• Rule 3a71-3(d)—Conditional Exception from De Minimis Counting Requirement in Connection with Certain Transactions Arranged, Negotiated or Executed in the United States (OMB Control No. 3235-0771);
• Rules 15Fi-3 to 15Fi-5—Risk Mitigation Techniques for Uncleared Security-Based Swaps (OMB Control No. 3235-0777);
• Rule 15fk-1(c)(2)(ii)(A) (OMB Control No. 3235-0732);
• Rule 17a-5—Reports to be Made by Certain Brokers and Dealers (OMB Control No. 3235-0123);
• Rule 17a-12—Reports to be Made by Certain OTC Derivatives Dealers (OMB Control No. 3235-0498);
• Rule 17a-19 and Form X-17A-19—Report by National Securities Exchanges and Registered National Securities Associations of Changes in the Membership Status of Any of Their Members (OMB Control No. 3235-0133);
• Rule 17h-2T—Reporting Requirements of Risk Assessment Information for Brokers and Dealers (OMB Control No. 3235-0410);
• Rule 18a-7—Reports to be Made by Certain Security-Based Swap Dealers and Major Security-Based Swap Participants (OMB Control No. 3235-0749);
• Regulation S-T—General Rules and Regulations for Electronic Filing (OMB Control Number 3235-0424).
The Commission is submitting these requirements to the Office of Management and Budget (“OMB”) for review and approval in accordance with the PRA and its implementing regulations.
Form ID must be completed and filed with the Commission by all individuals, companies, and other organizations who seek access to file electronically on EDGAR.
Rule 6a-1 under the Exchange Act generally requires that an applicant seeking to register as a national securities exchange, or seeking an exemption from such registration based on limited volume, file an application on Form 1 and correct any inaccuracy therein upon discovery of such inaccuracy.
The Commission proposes to amend Rules 6a-1, 6a-2, and 6a-3 under the Exchange Act, as well as Form 1 and the instructions to Form 1, to make certain non-substantive changes and to require
Rule 6a-4
The Commission proposes to amend Rule 6a-4 under the Exchange Act, Form 1-N and the instructions to Form 1-N, as well as to make clarifying changes to Rule 202.3(b)(3) to the Commission's Informal and Other Procedures, to make certain non-substantive changes and to require the electronic filing of all submissions required by Rule 6a-4.
Under Exchange Act Rule 15Aa-1, an applicant for registration as a national securities association must file a registration statement with the Commission on Form X-15AA-1.
The Commission is proposing to amend Rule 15Aa-1 and redesignate it as Rule 15aa-1,
The Commission proposes to redesignate Form X-15AA-1 as Form 15A and to incorporate in proposed Form 15A information related to amendments and supplements to the registration statement currently filed on Form X-15AJ-1 and information related to the annual consolidated supplement to the registration statement currently filed on Form X-15AJ-2. New Form 15A would solicit information through prompts on the form that would better organize the information that is currently collected through Forms X-15AA-1, X-15AJ-1, and X-15AJ-2.
Proposed Form 15A would contain eleven sections. Preceding Section I of proposed Form 15A, the proposed form would contain prompts that would require the association to note the basis for submitting the Form 15A. The prompts would indicate whether the submission is an initial application filed pursuant to Rule 15aa-1 or an amendment or supplement. Section I would be titled “Organization,” and it would solicit information about the association itself and would require the association to attach Exhibits A through D. Sections II through IX of proposed Form 15A would solicit information about specific association rules and other information.
Section X would require the association to provide the contact information for its contact employee, and Section XI would provide the consent to service and attestation.
Rule 17ab2-1(a) states that an application for registration or for exemption from registration as a clearing agency or an amendment to any such application shall be filed with the Commission on Form CA-1, in accordance with the instructions thereto.
The Commission is proposing to revise certain aspects of Rule 17ab2-1, Form CA-1, and the instructions to Form CA-1 to make certain non-substantive changes and to require electronic filing of applications on Form CA-1 and subsequent amendments thereto submitted by applicants, registered clearing agencies, and exempt clearing agencies.
Rule 19b-4(e) provides that the listing and trading of a new derivative securities product by an SRO shall not be deemed a proposed rule change if the Commission has approved, pursuant to section 19(b) of the Exchange Act,
The Commission proposes to amend Rule 19b-4(e)
Section 19(b) of the Exchange Act, as amended, requires each SRO to file with the Commission, in accordance with such rules as the Commission may prescribe, copies of any proposed rule, or any proposed change in, addition to, or deletion from the rules of such SRO (collectively, a “proposed rule change”) accompanied by a concise general statement of the basis and purpose of such proposed rule change.
Rule 19b-4(j) requires that the signatory to an electronically submitted rule filing manually sign a signature page or other document authenticating, acknowledging, or otherwise adopting his or her signature that appears in typed form within the electronic document, execute that document before or at the time the rule filing is electronically submitted, and retain that document for its records in accordance with Rule 17a-1.
Rule 17a-22 currently requires a registered clearing agency to file with the Commission three paper copies of any material (including, for example, manuals, notices, circulars, bulletins, lists, or periodicals) issued, or made generally available, to its participants or other entities with whom it has a significant relationship, such as pledgees, transfer agents, or self-regulatory organizations, within 10 days after issuing, or making generally available, such material.
The proposed amendments to Rule 17a-22 would not change the scope of supplemental materials that are currently subject to the rule. However, the proposed amendments would replace the requirement to file multiple copies of supplemental materials with the Commission and, where applicable, the ARA in paper form with a requirement to prominently post such materials on a registered clearing agency's internet website.
The Commission is proposing to amend Rules 17a-5, 18a-7, and 17a-12 to require broker-dealers, SBS Entities, and OTC derivatives dealers to electronically file with the Commission in Inline XBRL through the Commission's EDGAR system annual audited reports and related annual filings. The filings are currently made either in paper, via email, or voluntarily on the EDGAR system as PDF documents.
In addition, the Commission is proposing to amend Rule 17a-12 to require OTC derivatives dealers to file the unaudited FOCUS Report Part II electronically through the SEC eFOCUS system instead of in paper.
The Commission is also proposing to allow electronic signatures in Rule 17a-5, 17a-12, and 18a-7 filings, which includes the FOCUS Report.
Broker-dealers, SBS Entities, and OTC derivatives dealers file FOCUS Reports Part II, IIA, or IIC, which are periodic unaudited reports about their financial and operational condition. The Commission is proposing corrective and clarifying amendments to FOCUS Report Part II and amendments to FOCUS Report Part IIC for consistency with FFIEC Form 031.
The Commission proposes amending paragraph (a)(2) of Rule 17h-2T to require that the quarterly and annual risk assessment reports be filed with the Commission electronically through EDGAR as an Interactive Data File in accordance with Rule 405 of Regulation S-T. The materials filed under the rule would not change, but the materials filed would be filed on EDGAR, and the financial statements required by Item 4 of the Form would be structured in Inline XBRL.
In general, Rule 17a-19 requires national securities exchanges and associations to file with the Commission certain information required on Form X-17A-19 within five business days of the occurrence of the initiation of membership, change in membership, or termination of membership of any member. The Commission proposes amending Rule 17a-19 and Form X-17A-19 to require that filings providing such notifications be made on EDGAR, in a custom XML-based data language.
The ANE Exception is conditioned in part on the Registered Entity filing with the Commission an ANE Exception Notice, which is a notice that personnel of the Relying Entity or its agent located in a branch or office in the United States may conduct ANE Activity in their capacity as persons associated with the Registered Entity in reliance on the ANE Exception. Currently, Exchange Act Rule 3a71-3(d)(1)(vi) requires the Registered Entity to file the ANE Exception Notice by submitting it to the electronic mailbox specified on the Commission's website. The Commission is proposing to amend the manner of filing to require the Registered Entity to file the ANE Exception Notice electronically through the Commission's EDGAR filing system, but is not changing the information required from a filer of the ANE Exception Notice. The Commission also is proposing to require that, if the Registered Entity later becomes unregistered or otherwise ineligible to serve as the Registered Entity for purposes of the ANE Exception, the Registered Entity must promptly withdraw its ANE Exception Notice. In addition, a Registered Entity whose associated persons will no longer conduct ANE Activity pursuant to the ANE Exception may withdraw its ANE Exception Notice. Currently, a Registered Entity who wishes to withdraw a filed ANE Exception Notice may contact the Commission and request that the ANE Exception Notice be manually removed from the Commission's website. The Commission is proposing to require Registered Entities to file any withdrawal of an ANE Exception Notice electronically through the Commission's EDGAR filing system.
Rule 15fi-3 generally requires SBS Entities to: (1) engage in periodic portfolio reconciliation activities with counterparties who are also SBS Entities; and (2) establish, maintain, and follow written policies and procedures reasonably designed to ensure that they engage in periodic portfolio reconciliation with counterparties who are not SBS Entities with respect to their outstanding (and uncleared) security-based swaps.
Given that Rule 15fi-3(c) requires that the security-based swap valuation notices be submitted to the Commission “in a form and manner acceptable to the Commission,” staff has made available two options for submitting these notices to the Commission, which include either: (1) an electronic submission using EDGAR or (2) submission to a dedicated Commission email address. Under both submission types, the system is capable of accepting the notice in PDF format, either as an attachment to an email or as an uploaded document to EDGAR. The Commission is now proposing to amend Rule 15fi-3(c) to affirmatively require SBS Entities to submit these notices to the Commission electronically in EDGAR using a custom XML-based data language. This includes both the initial notice and any subsequent amendments. If these proposed changes are adopted, SBS Entities would no longer be able to submit dispute notices to the Commission using a dedicated email address or in PDF format on EDGAR.
Rule 15fk-1(c) currently requires that the CCO of an SBS Entity prepare and sign a CCO report. The CCO report must be submitted to the Commission within 30 days following the filing deadline for the SBS Entity's annual financial report with the Commission.
The proposed amendment to Rule 15fk-1(c)(2)(ii)(A) would not change what the report must include. Rather, the amendment would require that the CCO report be submitted electronically in Inline XBRL through EDGAR. As with other entities that make submissions through EDGAR, these submissions would be subject to the provisions of Regulation S-T and the EDGAR Filer Manual, as defined in Rule 11 of Regulation S-T.
The Commission is proposing amendments to Rule 101 of Regulation S-T to require that broker-dealer and non-bank SBS Entity annual reports and related annual supplemental reports, national securities exchange and association changes in member status, SBS Entity CCO reports, and broker-dealer risk assessment reports be filed electronically with the Commission. The Commission is also proposing amendments to Rule 405 to require that broker-dealer and non-bank SBS Entity annual reports and related annual supplemental reports, SBS Entity CCO reports, broker-dealer risk assessment reports (in part), clearing agency applications (in part), and national securities exchange applications (in part) be filed in Inline XBRL.
The Commission also is proposing that ANE Exception Notices and withdrawals of ANE Exception Notices be filed with the Commission electronically using the Commission's EDGAR system. To implement this requirement, the Commission is proposing amendments to Rule 101 of Regulation S-T to require that ANE Exception Notices and withdrawals of ANE Exception Notices be filed electronically with the Commission using the EDGAR system.
The Commission also is proposing that initial notices and any subsequent amendments pursuant to Rule 15fi-3(c) be submitted to the Commission electronically using the Commission's EDGAR system in a custom XML-based data language. To implement this requirement, the Commission is proposing amendments to Rule 101 of Regulation S-T to require that the notices be submitted electronically to the Commission using the EDGAR system.
The information provided on Form ID allows the Commission staff to review applications for EDGAR access and, if the application is approved, assign CIKs (if the applicant does not already have a CIK) and/or access codes to applicants to permit filing on EDGAR. Form ID is essential to EDGAR security.
The information required pursuant to Rules 6a-1, 6a-2, and 6a-3 is necessary to enable the Commission to receive accurate and complete information from applicants seeking registration as national securities exchanges or an exemption from such registration (“exempt exchanges”) and from national securities exchanges and exempt exchanges, which would enable the Commission to exercise its statutory oversight functions. Without the information submitted pursuant to Rule 6a-1 on Form 1, the Commission would not be able to determine whether the applicant has met the criteria for registration (or an exemption from registration) set forth in section 6 of the Exchange Act. The amendments, periodic updates of information, supplemental materials, and monthly reports submitted pursuant to Rules 6a-2 and 6a-3 are necessary to assist the Commission in its oversight of national securities exchanges and exempt exchanges.
The information obtained under Rule 6a-4 and Form 1-N provides the Commission with basic information about Security Futures Product Exchanges. This information enables the Commission to carry out its statutorily mandated oversight functions and helps ensure that Security Futures Product Exchanges continue to be in compliance with the Exchange Act.
The information required pursuant to Rule 15aa-1 is necessary to enable the Commission to receive accurate and complete information from applicants seeking registration as national securities association which would enable the Commission to exercise its statutory oversight functions. Without the information submitted pursuant to Rule 15aa-1 on Form 15A, the Commission would not be able to determine whether the applicant has met the criteria for registration set forth in section 15A of the Exchange Act. The amendments, periodic updates of information, and supplemental materials submitted pursuant to Rule 15Aa-2 are necessary to assist the Commission in its oversight of national securities associations.
The Commission uses the information disclosed on Form CA-1 to: (i) determine whether an applicant for registration as a clearing agency or for an exemption from such registration meets the standards for registration set forth in the Exchange Act; (ii) enforce compliance with the Exchange Act's registration requirements; and (iii) use as a reference for specific registered clearing agencies or exempt clearing agencies for compliance and investigatory purposes. The information required under Rule 17ab2-1 is essential for the Commission to perform its statutorily required duties.
The information collected pursuant to Rule 19b-4(e) is designed to maintain an accurate record of all new derivative securities products by SROs, the listing and trading of which are not deemed to be proposed rule changes. The Commission reviews compliance with Rule 19b-4(e) through its routine inspections of the SROs.
The information collected pursuant to Rule 19b-4 is designed to provide the Commission with the information necessary to determine, as required by the Exchange Act, whether the proposed rule change is consistent with the Exchange Act and the rules thereunder. The information is used to determine if the proposed rule change should be approved, disapproved, suspended, or if proceedings should be instituted to determine whether to approve or disapprove the proposed rule change. The Commission reviews compliance with Rule 19b-4 through its routine inspections of the SROs. The Commission is proposing to remove a manual signature requirement in the existing collection of information under Rule 19b-4 and on Form 19b-4 because it believes that requirement is unnecessary given the electronic signature already required by Form 19b-4.
The information required to be posted on a registered clearing agency's website under the proposed amendments to Rule 17a-22 would assist the Commission in carrying out its statutorily mandated oversight functions with respect to clearing agencies. The Commission uses this information to determine: (i) whether a clearing agency is implementing procedural or policy changes and, if so, whether such changes are consistent with the purposes of section 17A of the Exchange Act; and (ii) whether a clearing agency has changed its rules without filing the actual or prospective change to the Commission as required by section 19(b) of the Exchange Act. The posting of such information on a registered clearing agency's website would improve transparency of a clearing agency's actions and communications to a larger group of potentially interested persons, including non-member entities that directly or indirectly use the clearing agency's services, investors, and the general public.
Reports required to be made under Rules 17a-5, 18a-7, and 17a-12 are used, among other things, to monitor the financial and operational condition of broker-dealers, SBS Entities, and OTC derivatives dealers by Commission staff and, to the extent applicable to the entity, by its designated examining authority (“DEA”). The reports required under Rules 17a-5, 18a-7, and 17a-12 are also one of the primary means of ensuring compliance with the Commission's financial responsibility rules (
The information required to be filed with the Commission under Rule 17h-
Upon the Commission's receipt of a Form X-17A-19 filing, the information is entered into a database, which is regularly shared with the SROs. Commission staff use the information contained in Form X-17A-19 to assign the appropriate SRO as DEA for the member firms. This information is also used by SIPC in determining which SRO is the collection agent for the SIPC Fund.
The information provided by a Registered Entity in connection with the filing of an ANE Exception Notice pursuant to Exchange Act Rule 3a71-3(d)(1)(vi), and any subsequent withdrawal, assists the Commission in evaluating market participants' compliance with the limitations on use of the ANE Exception, as well as assists Relying Entities and their affiliates in determining whether they have satisfied the ANE Exception's notice requirement and in monitoring their progress toward the ANE Exception's cap on inter-dealer security-based swaps. The proposed amendment to Rule 3a71-3(d)(1)(vi) to move the filing of the ANE Exception Notice, and any subsequent withdrawal, to the Commission's EDGAR filing system would facilitate more efficient and timely transmission, dissemination, and analysis of this information.
The information shared by counterparties to a security-based swap transaction periodically during the portfolio reconciliation process, as contemplated by Rule 15fi-3, plays an important role in assisting those counterparties in identifying and resolving discrepancies involving key terms of their transactions on an ongoing basis. This information also allows those counterparties to improve their management of internal risks related to the enforcement of their rights and the performance of their obligations under a security-based swap. Moreover, requiring SBS Entities to agree in writing with each of their counterparties on the terms of the portfolio reconciliation (including, if applicable, agreement on the selection of any third party service provider who may be performing the reconciliation) helps to minimize any discrepancies regarding the portfolio reconciliation process itself, thereby ensuring that it operates in as efficient and cost-effective means possible. The requirement to report certain unresolved valuation disputes to the Commission assists the Commission in identifying potential issues with respect to an SBS Entity's internal valuation methodology and also could serve as an indication of a widespread market disruption in cases where the Commission receives a large number of such notices from multiple firms. The proposed amendment to Rule 15fi-3 to require submission of the valuation dispute notices using the Commission's EDGAR system is intended to facilitate more efficient and secure transmission and efficient and effective analysis of this information.
The information collected under Rule 15fk-1(c) assists the Commission staff's oversight and examination of SBS Entities compliance with the business conduct requirements for such entities.
The proposed amendments to Rule 101 of Regulation S-T, as part of implementing the requirement that broker-dealers or SBS Entities use the EDGAR system to electronically file their annual reports, broker-dealer risk assessment reports, and CCO reports, as applicable, will be used by the Commission to streamline and simplify the filing process for filers and the Commission. In addition, the public filings will be more quickly available to investors to evaluate and compare these firms.
The proposed amendments to Rule 101 of Regulation S-T, as part of implementing the requirement that filers use the EDGAR system to provide Rule 3a71-3(d)(1)(vi) and Rule 15fi-3(c) notices, will be used as described above. Further, the proposed amendments to Rules 201 and 202 of Regulation S-T would preclude the possibility of temporary or continuing hardship exemptions that otherwise would allow the ANE Exception Notice (and any subsequent withdrawal) to be filed on paper. The ANE Exception Notice facilitates the availability of a conditional exception
The proposed amendments to Rule 405 of Regulation S-T, which would implement the proposed Inline XBRL requirements for Form 1, Form CA-1, Form X-17A-5 Part III, Form 17-H, and the CCO reports, will be used to facilitate the retrieval, comparison, and other analysis of the disclosures on those forms across respondents and time periods.
The respondents to the collection of information required under Form ID would be all entities that would be required to file electronically on EDGAR under the proposal and that do not already have access to EDGAR. Such respondents must submit a Form ID, along with the notarized signature of an authorized individual, to obtain an EDGAR identification number and access codes to file on EDGAR. If the requirements to file on EDGAR are adopted as proposed, the Commission estimates that these respondents would include the following entities not currently registered on EDGAR: 24 national securities exchanges and exempt exchanges; 2 Security Futures Product Exchanges; 1 registered national securities association; 12 registered and exempt clearing agencies; 1,559 broker-dealers; and 24 Registered Entities.
The respondents to the collection of information required under Rule 6a-1 are new applicants applying to register as a national securities exchange or seeking an exemption from such registration. The Commission estimates that it would receive approximately one initial Form 1 filing per year.
The respondents to the collection of information required under Rules 6a-2 and 6a-3 are national securities exchanges and exempt exchanges. Currently, there are 24 entities registered as national securities exchanges. These respondents would file annual, triennial, and periodic amendments to their Form 1 under Rule 6a-2. These respondents would also file supplemental materials and monthly reports under Rule 6a-3. There are no exempt exchanges that currently submit amendments under Rule 6a-2 or supplemental materials and monthly reports under Rule 6a-3.
The respondents to the collection of information required under Rule 6a-4 are futures exchanges that trade security futures products. Currently, there are two Security Futures Product Exchanges. These respondents would file annual, triennial, and periodic amendments to their Form 1-N under Rule 6a-4(b). These respondents would also file supplemental materials and monthly reports under Rule 6a-4(c).
The respondents to the collection of information required under Rule 15aa-1 are new applicants applying to register as a national securities association. The Commission estimates that it would receive one initial Form 15A filing per year.
The respondents to the collection of information required under Rule 15aa-2 are national securities associations currently registered with the Commission. Currently, there is only one entity that would be required to file annual, triennial, and periodic amendments to its Form 15A under Rule 15aa-2.
The respondents to the collection of information required under Rule 17ab2-1 are registered and exempt clearing agencies, as well as applicants seeking to register as a clearing agency or seeking an exemption from such registration. Currently, there are nine registered clearing agencies, only seven of which are operational,
The respondents to the collection of information required under Rule 19b-4(e) are SROs that list and trade new derivative securities products—national securities exchanges. Currently, there are 24 entities registered as national securities exchanges.
The respondents to the collection of information required under Rule 19b-4(j) and Form 19b-4 are SROs (as defined by section 3(a)(26) of the Act), including national securities exchanges, national securities associations, registered clearing agencies, notice registered securities future product exchanges, and the MSRB. The Commission's current approved estimated number of respondents is 42 SROs.
The respondents to the collection of information required under Rule 17a-22 are registered clearing agencies. Currently, there are nine registered clearing agencies, only seven of which are operational.
The respondents to the annual reports collection of information required under Rule 17a-5 are broker-dealers. For the 12 months ended December 31, 2022, the Commission received 1,559 filings of the broker-dealer annual reports in paper and 1,659 electronically via EDGAR. The Commission therefore estimates that approximately 3,218 broker-dealers are required to file annual reports with the Commission. As of June 15, 2022, five of those broker-dealers are ANC broker-dealers required to file supplemental reports under Rule 17a-5. The respondents to the annual reports collection of information required under Rule 18a-7 are SBSDs and MSBSPs that are not prudentially regulated. As of June 15, 2022, there are nine SBSDs and MSBSPs that are not prudentially regulated. The respondents to the annual reports collection of information under Rule 17a-12 are OTC derivatives dealers. There are three OTC derivatives dealers subject to Rule 17a-12.
There are 460 broker-dealers or stand-alone SBS Entities that filed FOCUS Report Part II as of March 31, 2022. Of those Part II filers, 4 firms are domestic stand-alone swap dealers and 103 firms are domestic stand-alone introducing brokers. There are 31 bank SBS Entities that filed FOCUS Report Part IIC as of March 31, 2022. There are 3,056 broker-dealers that filed FOCUS Report Part IIA as of March 31, 2022.
The respondents to the collection of information required under Rule 17h-2T are broker-dealers. There are 241 broker-dealers that must file quarterly and annual risk assessment reports with the Commission under Rule 17h-2T.
The respondents to the collection of information required under Rule 17a-19 are national securities exchanges and registered national securities associations. As of June 15, 2022, there are a total of 25 national securities exchanges and registered national securities associations.
The Commission estimates that up to 24 entities that engage in security-based swap dealing activity may rely on the ANE Exception.
The respondents to the collection of information under Rule 15fi-3 are registered SBS Entities. As of January 4, 2023, 50 entities have submitted applications for registration as an SBSD; there are no registered MSBSPs.
The respondents to the collection of information under Rule 15fk-1(c) are registered SBS Entities. As of January 4, 2023, there are 50 SBS Entities registered with the Commission. Of these entities, the Commission estimates that none will be first-time EDGAR users needing to obtain EDGAR access credentials in order to submit its CCO report because they have already registered as SBS Entities through EDGAR.
The respondents to the collection of information under Regulation S-T are broker-dealers, SBSDs, MSBSPs, OTC derivatives dealers, and national securities associations and exchanges. The collection of information requirements are reflected in the burden hours estimated for Rule 3a71-3, 15fi-3, 15fk-1, 17a-5, 18a-7, 17a-12, 17a-19, and Rule 17h-2T. The rules in Regulation S-T should not impose any separate burden.
Form ID (OMB Control No. 3235-0328) must be completed and filed with the Commission by all individuals, companies, and other organizations who seek access to file electronically on EDGAR. Accordingly, a filer that does not already have access to EDGAR must submit a Form ID, along with the notarized signature of an authorized individual, to obtain an EDGAR identification number and access codes to file on EDGAR. The Commission currently estimates that Form ID would take 0.30 hours to prepare, resulting in an annual industry-wide burden of 17,199 hours.
The Commission estimates that each filer that currently does not have access to EDGAR would incur an initial, one-time burden of 0.30 hours to complete and submit a Form ID.
Initial filings on Form 1 by applicants seeking registration as a national securities exchange or an exemption from such registration are made on a one-time basis. The Commission estimates that it would receive approximately one initial Form 1 filing per year. The Commission also estimates that each respondent who submits an initial Form 1 filing would incur an average burden of 880 hours to complete and file an initial Form 1.
With respect to supplemental information and monthly reports, the Commission estimates that each exchange would file such materials 12 times per year. The Commission estimates that each exchange would incur an average burden of 0.5 hours per filing to comply with Rule 6a-3.
The Commission recognizes that the proposed amendments to Rules 6a-1, 6a-2, and 6a-3 would impose certain burdens on respondents. Although the information to be provided on filings made pursuant to Rules 6a-1, 6a-2, and 6a-3 would not change, respondents would be required to submit documents electronically. The instructions to Form 1 would be amended to no longer require respondents to make and submit multiple copies of the Form 1 submission. Currently, respondents must make two copies of each filing to be submitted pursuant to Rules 6a-1 and 6a-2. The Commission believes that generally the time spent making such copies instead would be spent uploading documents on EDGAR. Where a filing could include multiple exhibits, the Commission believes that the time required to upload documents would be less than the time required to make two copies of each exhibit, particularly when the exhibit contains numerous pages. Accordingly, the Commission estimates that, on average, filing an initial Form 1 application electronically would require two fewer hours of clerical work from the current baseline. The aggregate initial burden on all respondents submitting an initial Form 1 application electronically would be two hours less than the current baseline. Accordingly, the Commission believes that the aggregate initial burden on all respondents to complete and submit an initial Form 1 application would be 878 hours.
With respect to material filed under Rule 6a-3, while in some instances there may be a marginal reduction in burden hours associated with submitting these materials electronically as a result of a reduction in printing requirements, for purposes of making a PRA burden estimate the Commission believes that, on average, the most recently approved baseline represents a reasonable estimate of the burden hours associated with submitting supplemental information and monthly reports. The Commission believes that the time required to compile copies of these materials would, on average, be equivalent to the time required to upload those filings electronically. The Commission estimates that, on average, filing supplemental information and monthly reports electronically would not increase or decrease burden hours from the current baseline of 0.5 hours. Accordingly, the Commission believes that the aggregate burden associated with filing supplemental information and monthly reports would be 180 hours.
The Commission also recognizes that the requirement to tag certain disclosures (specifically, the financial statements and the manner of operations description) on the initial Form 1 in Inline XBRL would impose burdens on respondents. To file reports in Inline XBRL, a filer must purchase Inline XBRL tagging software to apply Inline XBRL tags to the reports before filing them on EDGAR, or employ a tagging service provider to apply the Inline XBRL tags on its behalf. As discussed in further detail below, the Commission believes this burden would be mitigated for most exchanges, because most exchanges are affiliated with public reporting companies subject to existing Inline XBRL structuring requirements and thus may be able to leverage the compliance software and experience of their reporting affiliates.
The Commission estimates respondents will incur an average of 10 burden hours to tag the initial Form 1 in Inline XBRL (a total annual industry-wide burden of 10 hours), and an average of 7 burden hours to tag financial statements included in annual amendments to Form 1 in Inline XBRL (a total annual industry-wide burden of 168 hours).
The Commission also recognizes the requirement to structure certain other disclosures on Form 1 in a custom XML data language would impose burdens on respondents.
To summarize, the current estimated annual burden to submit filings pursuant to Rules 6a-1, 6a-2, and 6a-3 is 7,624 hours.
Initial filings on Form 1-N by futures exchanges submitting notice registration as a national securities exchange solely for the purpose of trading security futures products are made on a one-time basis. The Commission estimates that it would receive zero initial Form 1-N filing per year.
The Commission recognizes that the proposed amendments to Rule 6a-4 would impose certain burdens on respondents. Although the information to be provided on filings made pursuant to Rule 6a-4 would not change, respondents would be required to submit documents electronically. The instructions to Form 1-N would be amended to no longer require respondents to make and submit multiple copies of the Form 1-N submission. Currently, respondents must make two copies of each filing in addition to the original Form 1-N to be submitted pursuant to Rule 6a-4. The Commission believes that, generally, the time spent making such copies instead would be spent uploading documents through EDGAR. Where a filing could include multiple exhibits, the Commission believes that, generally, the time required to upload documents would be less than the time required to make two copies of each exhibit, particularly when the exhibit contains numerous pages.
The Commission estimates that, on average, filing an initial Form 1-N filing electronically would require, generally, two fewer hours of clerical work from the current baseline. Therefore, instead of 31 hours, an initial filing would require 29 hours. However, because the Commission estimates that there will be zero respondents submitting initial filings, the burden would remain zero hours (29 hours/respondent/year × 0 respondents/year).
The Commission estimates that, on average, periodic amendments to Form 1-N electronically would require 1 fewer hour of clerical work from the current baseline. The aggregate ongoing burden on all respondents submitting periodic amendments electronically would be two hours fewer than the current baseline. Accordingly, the Commission estimates that the aggregate burden on all respondents to submit periodic amendments to Form 1-N would be 28 hours (14 hours/respondent/year × 2 respondents).
Similarly, the Commission estimates that, on average filing annual amendments to Form 1-N electronically would require 1 fewer hour of clerical work from the current baseline. The aggregate burden on all respondents submitting annual amendments electronically would be two hours fewer than the current baseline. Accordingly, the Commission estimates that the aggregate burden on all respondents to provide annual amendments to Form1-N would be 28 hours (14 hours/respondent/year × 2 respondents).
The Commission estimates that, on average, filing triennial amendments to Form 1-N would require 1 fewer hour of clerical work from the current baseline. Accordingly, the Commission estimates that the total annual burden for all respondents to provide triennial amendments to Form 1-N would be 13 hours
With respect to supplemental material filed under Rule 6a-4, while in some instances there may be a marginal reduction in burden hours associated with submitting these materials electronically as a result of a reduction in printing requirements, for purposes of making a PRA burden estimate the Commission believes that, on average, the most recently approved baseline represents an appropriate estimate of the burden hours associated with submitting supplemental information and monthly reports. The Commission believes that the time required to compile copies of these materials would, on average, be equivalent to the time required to upload those filings electronically. The Commission estimates that, on average, filing supplemental information and monthly reports electronically would not increase or decrease burden hours from the current baseline of six hours/respondent/year. Accordingly, the Commission believes that the aggregate burden associated with filing supplemental information and monthly reports would continue to be 12 hours. Thus, the Commission believes that the total aggregate annual burden to comply with Rule 6a-4 would be 81 hours.
Initial filings on proposed Form 15A by an applicant seeking registration as a national securities association are made on a one-time basis.
Based on the number of applications for registration as a national securities association the Commission has received, the Commission estimates that it will receive not more than one initial Form 15A filing per year. The Commission estimates that a respondent would incur an average burden of 878 hours to file an initial Form 15A.
With respect to the proposed amendments to proposed Form 15A, the Commission estimates that each registered association would file 11 amendments or periodic updates to Form 15A per year.
The Commission has previously discussed the requirements of Rule 17ab2-1 and Form CA-1 above in IX.A.5.
The Commission estimates that, on average, each initial Form CA-1 requires approximately 340 hours to complete and submit for approval, and that, on average, the Commission receives one application each year.
The Commission recognizes that the proposed amendments to Rule 17ab2-1 would impose certain burdens on respondents. Although the information to be provided on filings made pursuant to Rule 17ab2-1 would not change, respondents would be required to submit documents electronically. The instructions to Form CA-1 would be amended to no longer require respondents to make and submit multiple copies of the same form. Currently, respondents must make four copies of Form CA-1. The Commission believes that the time spent making such copies would now be spent uploading documents through EDGAR. Where a filing may include multiple exhibits, the Commission believes that the time required to upload documents would be slightly less than the time required to make copies of each exhibit. As the number of exhibits required to be submitted with Form CA-1 is roughly equivalent to the number of exhibits required by an initial Form 1 application, the Commission believes that the overall burden is two hours less (for either an initial application or an amendment) to make an electronic filing, compared to making the paper copies. Thus, the Commission believes that the aggregate annual burden associated with compliance with Rule 17ab2-1 and Form CA-1, other than the structuring requirement discussed below, would be approximately 396 hours.
The Commission also recognizes that the requirement to file Form CA-1 in Inline XBRL (in part) and in custom XML (in part) would impose burdens on respondents.
The Commission's currently approved estimate to complete and submit one Form 19b-4(e) is 1 hour, for an aggregate annual burden of 2,331 hours.
The proposed amendment to Rule 19b-4(e) rescinding Form 19b-4(e) and instead requiring an SRO to publicly report the information currently provided in Forms 19b-4(e) on its internet website would impose certain burdens on respondents. Respondents would be required to use the most recent versions of the XML schema (
The Commission's currently approved estimated response burden pursuant to Rule 19b-4 and Form 19b-4 for the 42 respondents is an aggregate burden of 91,300 hours.
The Commission believes that, on average, the removal of the manual signature and retention requirement would not increase or decrease the burden hours associated with continuing to file Form 19b-4 electronically because the manual signature and retention requirement is only a small component of the filing requirement. Accordingly, the Commission believes that the aggregate burden for SROs associated with complying with Rule 19b-4 and filing Form 19b-4 would continue to be 91,300 hours.
The Commission estimates that it receives, on average, approximately 840 filings per year pursuant to Rule 17a-22.
The Commission recognizes that the proposed amendments to Rule 17a-22 would impose certain burdens on respondents. Although the scope of supplemental materials subject to Rule 17a-22 would not change, respondents would be required to prominently post certain supplemental materials on their internet websites within two business days after issuing, or making generally available, such materials to their participants or other entities with whom they have a significant relationship. Currently, respondents must file with the Commission three paper copies of certain supplemental materials issued, or made generally available, to their participants or other entities with whom they have a significant relationship within 10 days after issuing, or making generally available, such materials. In addition, when the Commission is not a respondent's ARA, the respondent must file at the same time one paper copy of the materials with its ARA.
While there may be a marginal reduction in burden hours associated with replacing the paper filing requirement under Rule 17a-22 with an electronic filing requirement via a registered clearing agency's website, the Commission believes that, for purposes of making a PRA burden estimate, the current baseline represents a reasonable estimate of the burden hours associated with filing supplemental materials. The Commission believes that the time required to compile and mail copies of supplemental materials would, on average, be equivalent to the time required to post these materials on a clearing agency's website such that they would be readily identifiable and accessible on the website.
Rules 17a-5, 17a-12, and 18a-7 require broker-dealers, OTC derivatives dealers, and SBS Entities that are not prudentially regulated, respectively, to file annual reports, including financial statements and supporting schedules that must be audited by a PCAOb-registered independent public accountant in accordance with PCAOB standards. Under Rule 17a-5, each broker-dealer is estimated to have an annual reporting burden of 12 hours, resulting in an annual industry burden of 44,148 hours.
In the context of Nationally Recognized Statistical Rating Organizations (“NRSROs”), the Commission estimated that it would take an NRSRO, on average, sixteen hours on a one-time basis to become familiar with the EDGAR system.
As stated above, the Commission estimates that for the 12 months ended December 31, 2022, the Commission received 1,559 filings of the annual reports required by paragraph (d) of Rule 17a-5 in paper.
In addition, as stated above, the Commission estimates that nine non-bank SBSDs and MSBSPs would be required to file annual reports under proposed paragraph (c) of Rule 18a-7 and that these firms would be new EDGAR filers. However, since these firms are already filing Form SBSE on EDGAR, the Commission does not estimate any burden for these firms to familiarize themselves with EDGAR.
The Commission estimates that the one-time burden for an OTC derivatives dealer to familiarize itself with EDGAR would be approximately 16 hours. However, because all three OTC derivatives dealers already voluntarily file their annual reports on EDGAR, the Commission estimates that the one-time industry-wide burden would be zero hours.
The current PRA burden for paragraph (d) of Rule 17a-5 includes an annual industry-wide cost of approximately $28,512 in postage costs to mail the annual reports to the Commission and the current PRA burden for paragraph (k) of Rule 17a-5 includes an annual industry-wide cost of approximately $85 in postage costs to mail the supplemental reports to the Commission. Under the proposal, broker-dealers would no longer incur these costs. Under the proposal, broker-dealers, OTC derivatives dealers, SBSDs, and MSBSPs filing their annual
Under the proposal, broker-dealers, OTC derivatives dealers, SBSDs, and MSBSPs would be required to file their annual reports and related filings (including compliance reports, exemption reports, accountant's reports, and supplemental reports) in Inline XBRL. To file reports in Inline XBRL, a filer must purchase Inline XBRL tagging software to apply Inline XBRL tags to the reports before submitting them to EDGAR, or employ a tagging service provider to apply the Inline XBRL tags to the reports on its behalf. As described in further detail in the subsequent economic analysis of proposed structured data requirements, the Commission expects the burdens associated with tagging the annual reports and related filings in Inline XBRL will vary based on the size of the respondent and whether the respondent is affiliated with a public reporting company that is already subject to Inline XBRL requirements.
On average, we estimate respondents will incur 6 burden hours and $1,200 in external cost for the first response to be tagged in Inline XBRL, and will incur 4 burden hours and $800 in external cost to tag subsequent responses in Inline XBRL. Therefore, the Commission estimates the total initial industry-wide internal burden and external cost would be 19,308 hours and $3,861,600 for broker-dealers (including OTC derivatives dealers); and the total initial industry-wide internal burden and external cost would be 54 hours and $10,800 for SBSDs and MSBSPs.
Rules 17a-5, 17a-12, and 18a-7 require broker-dealers, OTC derivatives dealers, and SBS Entities, respectively, to file unaudited financial information on the FOCUS Report (Form X-17A-5 Part II, IIA, or IIC) on a monthly or quarterly basis.
The Commission proposes a number of amendments to the FOCUS Report. First, it proposes corrective and clarifying amendments to FOCUS Report Part II. The Commission estimates that the proposed amendments will result in an initial burden of five hours on each Part II filer so firms can familiarize themselves with the amendments to FOCUS Report Part II. The Commission believes that these proposed amendments will generally either have no impact on or reduce the ongoing burden on the vast majority of filers because they will generally reduce questions about where and how to report items on the form. However, because the proposed amendments require stand-alone swap dealers and stand-alone introducing brokers to complete a new section of FOCUS Report Part II that these types of firms were not previously required to complete (
The Commission estimates that there are 460 broker-dealers or stand-alone SBS Entities filing FOCUS Report Part II, resulting in an estimated industry-wide initial burden of 2,300 hours.
Second, the Commission proposes to align the text in FOCUS Report Part IIC with the text in FFIEC Form 031. These proposed amendments are expected to result in an initial burden of five hours on each bank SBS Entity so that firms can compare the revised FOCUS Report Part IIC with FFIEC Form 031. However, these proposed amendments are expected to generally either have no impact on or reduce the ongoing burden on bank SBS Entities because they will generally reduce questions about how to complete FOCUS Report Part IIC consistently with FFIEC Form 031. The Commission estimates that there are 31 bank SBS Entities filing FOCUS Report Part IIC, resulting in an estimated industry-wide initial burden of 155
Third, the Commission proposes to require only two of the three signature lines to be signed on the FOCUS Report's cover page, and allows these signatures to be signed either manually or electronically. This proposed amendment is expected to result in an initial burden of 1 hour on each filer so that the firm can review the standards for an electronic signature on the FOCUS Report Part II, IIA, or IIC, as applicable. However, this proposed amendment is expected to generally either have no impact on or reduce the ongoing burden on FOCUS Report filers, because they will not be required to furnish as many signatures as before the amendment, and it may be easier to prepare electronic signatures rather than manual signatures since firms will already be familiar with the process and can easily obtain these signatures while working remotely. The Commission estimates that there are 3,547 broker-dealers, stand-alone SBS Entities, and bank SBS Entities filing FOCUS Report Parts II, IIA, or IIC, resulting in an estimated industry-wide initial burden of 3,547 hours.
Finally, the Commission proposes to require OTC derivatives dealers to file the FOCUS Report electronically on the SEC eFOCUS system instead of in paper. The Commission estimates that this proposed amendment will result in an initial burden of 15 hours on each OTC derivatives dealer so that the firm can familiarize itself with the SEC eFOCUS system. However, this proposed amendment is expected to generally either have no impact on or reduce the ongoing burden on OTC derivatives dealers, because filing the FOCUS Report electronically is an automated process as compared to filing by paper. Therefore, the Commission estimates that there are 3 OTC derivatives dealers, resulting in an estimated industry-wide initial burden of 45 hours.
The current PRA burden for Rule 17h-2T does not include a burden for sending the risk assessment reports to the Commission. As broker-dealers that are required to file reports under Rule 17h-2T are also required to file annual reports under Rule 17a-5,
Under the proposal, broker-dealers that are required to file reports under Rule 17h-2T would be required to tag the financial statements included with the report in Inline XBRL. Because these broker-dealers are also required to tag annual reports under Rule 17a-5 in Inline XBRL, the proposed Inline XBRL requirement for reports under Rule 17h-2T would represent additional (quarterly) iterations of that compliance process, as abbreviated to reflect that Form 17-H requires only financial statements (and not any supplemental reports or other related filings) to be tagged in Inline XBRL, and that Form 17-H filers may omit the statement of cash flows and the footnotes to the financial statements. Thus, the Commission estimates an average additional burden of 1 hour per response and a total industrywide burden of 964 hours per year for Form 17-H filers to structure their financial statements in Inline XBRL.
Rule 17a-19 requires every national securities exchange and registered national securities association to file a Form X-17A-19 with the Commission and SIPC within five business days of the initiation, suspension, or termination of any member. The Commission currently estimates that Form X-17A-19 would take 0.25 hours to prepare, resulting in an annual industry-wide burden of 102 hours.
The 25 respondents who file Form X-17A-19 would need to familiarize themselves with the EDGAR system. As stated above with respect to Rule 17a-5, 17a-12, and 18a-7, the Commission estimates the one-time reporting burden of becoming familiar with the EDGAR system is approximately 16 hours.
Currently, Exchange Act Rule 3a71-3(d)(1)(vi) requires the Registered Entity to file the ANE Exception Notice by submitting it to the electronic mailbox specified on the Commission's website. When the Commission originally adopted the ANE Exception Notice requirement, it estimated that each Registered Entity would file one ANE Exception Notice with the Commission and that it would take 30 minutes to file each ANE Exception Notice, resulting in an industry-wide initial one-time burden of 12 hours.
The Commission does not expect that changing the manner of filing the ANE Exception Notice from an email filing to an EDGAR filing will change this estimated one-time burden. The ability to withdraw an ANE Exception Notice via EDGAR as proposed in this release will result in an additional one-time burden. The Commission estimates that withdrawing an ANE Exception Notice electronically on EDGAR will incur the same burden as filing the initial ANE Exception Notice electronically on EDGAR. If each Registered Entity files one withdrawal of its ANE Exception Notice, the Commission estimates that would result in an industry-wide initial one-time burden of 12 hours.
When the Commission originally adopted Rule 15fi-3, it expected there to be only a minimal, if any, initial burden of designing a system for submitting valuation dispute notices.
The Commission believes that the proposed amendments to Rule 15fi-3 related to EDGAR submission would not have an impact on the burdens associated with the existing collection of information. In particular, Rule 15fi-3(c) currently requires SBS Entities to submit security-based swap valuation dispute notices to the Commission “in a form and manner acceptable to the Commission.” Under current practice, staff has made available to SBS Entities two options for submitting these notices (and any amendments) which includes either: (1) an electronic submission using EDGAR or (2) submission to a dedicated Commission email address. The Commission is now proposing to amend Rule 15fi-3(c) to affirmatively require SBS Entities to submit these notices (and any amendments) to the Commission electronically in EDGAR in a custom XML data language.
SBS Entities will already have access to EDGAR by virtue of using the system to submit their applications for registration on either Forms SBSE, SBSE-A, or SBSE-BD, and to submit their certification for registration on Form SBSE-C. As a result, SBS Entities would not incur any additional burden associated with obtaining access to EDGAR for purposes of submitting dispute notices given that all such filers should already have an active CIK. With respect to the proposed custom XML structuring requirement for the dispute notices, SBS Entities would be able to comply by inputting their disclosures into a fillable web form on EDGAR rather than structuring their disclosures in custom XML themselves. As a result, SBS Entities would not incur any additional burden associated with the proposed custom XML structuring requirement for dispute notices.
Under current Rule 15fk-1(c), the CCO of a SBS Entity is required to prepare and submit a CCO report the Commission. The Commission previously estimated that these reports would require on average 93 hours per respondent per year for an ongoing annual burden of 5,115 hours.
The Commission recognizes that the proposed amendments to Rule 15fk-1(c) may potentially impose certain burdens on respondents. Although the information to be included in the CCO report pursuant to Rule 15fk-1(c) would not change, the proposed amendment would require respondents to submit the CCO report electronically with the Commission through EDGAR in Inline XBRL.
The Commission estimates that no SBS Entities would be first-time EDGAR users needing to obtain EDGAR access credentials. Thus, the internal time burden associated with completing a Form ID application to gain access to EDGAR would not apply to SBS Entities.
SBS Entities would incur a burden to submit the CCO report in Inline XBRL. Because the CCO reports consist of a limited number of textual narrative sections (compared to the various sets of numerical values that comprise financial statements, which take significantly longer to tag), the Commission estimates that, on average, an SBS Entity would spend 1.5 internal burden hours and $600 in external costs (
The Commission is proposing to require that the annual reports filed or submitted with the Commission under Rules 17a-5, 17a-12, and 18a-7, and the reports filed or submitted with the Commission under Rules 17a-19 and 15fk-1(c) be filed or submitted electronically with the Commission using the EDGAR system. The Commission also is proposing to require that the notices under Rules 3a71-3(d)(1)(vi) and 15fi-3(c), including withdrawals and amendments, respectively, be made using the EDGAR system. In order to implement these requirements, the Commission is proposing amendments to Rule 101 of Regulation S-T. In addition, the Commission is proposing that some or all of the annual reports filed or submitted with the Commission under Rules 17a-5, 17a-12, and 18a-7, and the reports filed or submitted with the Commission under Rule 15fk-1(c), be structured in Inline XBRL. In order to implement these requirements, the Commission is proposing amendments to Rule 405 of Regulation S-T.
While the amendments would revise Regulation S-T, the collection of information requirements are reflected in the burden hours estimated for Rule 3a71-3, 15fi-3, 15fk-1, 17a-5, 18a-7, 17a-12, Rule 17h-2T, and Form ID. The rules in Regulation S-T should not impose any separate burden, and accordingly the estimated burden for Regulation S-T as proposed to be amended would not change. Consistent with historical practice, the Commission is retaining a burden estimate of one hour for Regulation S-T for administrative convenience. A firm that does not already have log-in credentials for EDGAR will need to submit a request to the Commission in order to gain access to the EDGAR system.
All collections of information pursuant to the proposed rules would be mandatory, or mandatory except to the extent an exception is available.
For all Covered SRO Forms, no assurance of confidentiality is given by the Commission with respect to responses made on such forms. While Rule 24b-2 allows entities to seek confidential treatment, the Commission expects that all information will be public and that confidential treatment will not be available. Any person may make written objection to the public disclosure of any information contained in such forms in accordance with the procedures set forth in Rule 24b-2(b).
The information collected pursuant to Rule 3a71-3(d)(1)(vi) is public information to assist Relying Entities and their affiliates in determining whether they have satisfied the ANE Exception's notice requirement and in monitoring their progress toward the ANE Exception's cap on inter-dealer security-based swaps. The proposed amendment to Rule 3a71-3(d)(1)(vi) provides that notices and withdrawals shall be publicly disseminated through the Commission's EDGAR system. Because reliance on the ANE Exception which requires filing of an ANE Exception Notice is voluntary, the Commission does not expect that a Registered Entity seeking to facilitate the exception would include information that could not be publicly disclosed in the notices or withdrawals required by the proposed amendment to Rule 3a71-3(d)(1)(vi) or would object to the public disclosure of information contained in such notices or withdrawals.
Rule 15fi-3(c) requires an SBS Entity to promptly notify the Commission and any applicable prudential regulator of any security-based swap valuation dispute in excess of $20,000,000 (or its equivalent in any other currency) if not resolved within: (1) three business days, if the dispute is with a counterparty that is an SBS Entity; or (2) five business days, if the dispute is with a counterparty that is not an SBS Entity. The rule also requires SBS Entities to notify the Commission and any applicable prudential regulator, if the amount of any security-based swap valuation dispute that was the subject of a previous notice increases or decreases by more than $20,000,000 (or its equivalent in any other currency), at either the transaction or portfolio level. These amendments are required to be provided to the Commission, and any applicable prudential regulator, no later than the last business day of the calendar month in which the applicable security-based swap valuation dispute increases or decreases by the applicable dispute amount. To the extent that the Commission receives confidential information pursuant to this collection of information that is otherwise not publicly available, including in connection with examinations or investigations, the SBS Entity can request the confidential treatment of the information.
With respect to the other information collected under the proposed rule amendments and new rules, the firm can request the confidential treatment of the information.
For all Covered SRO Forms and for proposed Rule 19b-4(e), records of these collections of information must be retained for at least five years, the first two years in an easily accessible place, pursuant to Rule 17a-1.
Rule 17a-4 specifies the required retention periods for a broker-dealer, including an OTC derivatives dealer.
Pursuant to 44 U.S.C. 3506(c)(2)(B), the Commission solicits comment to:
92. Evaluate whether the proposed collection of information is necessary for the proper performance of our functions, including whether the information shall have practical utility;
93. Evaluate the accuracy of our estimate of the burden of the proposed collection of information;
94. Determine whether there are ways to enhance the quality, utility, and clarity of the information to be collected; and
95. Evaluate whether there are ways to minimize the burden of collection of information on those who are to respond, including through the use of automated collection techniques or other forms of information technology.
Persons submitting comments on the collection of information requirements should direct them to the Office of Management and Budget, Attention: Desk Officer for the Securities and Exchange Commission, Office of Information and Regulatory Affairs, Washington, DC 20503, and should also send a copy of their comments to Secretary, Securities and Exchange Commission, 100 F Street NE, Washington, DC 20549-1090, with reference to File Number S7-08-23. Requests for materials submitted to OMB by the Commission with regard to this collection of information should be in writing, with reference to File Number S7-08-23 and be submitted to the Securities and Exchange Commission, Office of FOIA/PA Services, 100 F Street NE, Washington, DC 20549-2736. As OMB is required to make a decision concerning the collections of information between 30 and 60 days after publication, a comment to OMB is best assured of having its full effect if OMB receives it within 30 days of publication.
The Commission is mindful of the costs imposed by and the benefits obtained from our rules. Section 2(b) of the Securities Act,
Where possible, we have attempted to quantify the costs and benefits expected to result from the proposed amendments to the submission or posting requirements. However, in some cases we have been unable to quantify the economic effects because we lack the information necessary to provide an estimate. For example, we do not quantify the benefit to the general public of improved access to public filings made available in structured format. We encourage commenters to provide data that may be relevant for quantifying impacts we have not quantified.
This section discusses the benefits and costs of the proposed amendments, as well as their potential effects on efficiency, competition, and capital formation. Some of the proposed amendments are, however, technical, so they will likely not have significant economic effects.
Existing Commission rules require or provide the option for the filing in paper of certain forms and filings, including applications of entities seeking to register with the Commission as a national securities exchange (or seeking an exemption from such registration based on limited volume) or as a national securities association as well as amendments to these initial applications, reports regarding the listing and trading of new derivative securities products, clearing agency registration and updates, annual broker-dealer audit reports and risk assessment reports, and certain clearing agency supplemental materials. Other Commission rules do not specify the format in which a requirement should be satisfied, such as notices of changes in SRO membership.
By requiring the electronic submission on the Commission's EDGAR system or website posting of: (1) the Covered SRO Forms; (2) the information posted under Rule 19b-4(e); (3) the annual reports and related annual filings filed by broker-dealers, OTC derivatives dealers, SBSDs, and MSBSPs; and (4) other notices and reports from SBSDs, MSBSPs, and Registered Entities (“the affected documents”), and by requiring certain of the affected documents to be provided, where appropriate, in a structured, machine-readable data language, the proposed amendments seek to streamline the submission process, and facilitate the transmission and effective use of submitted information. The proposed amendments to certain Exchange Act rules and the affected documents are expected to increase the efficiency of, and remove certain costs related to ongoing compliance with, the existing requirements. The discussion below addresses the potential economic effects of the proposed amendments, including their likely costs and benefits as well as the likely effects of the proposed amendments on efficiency, competition, and capital formation, relative to the economic baseline, which is comprised of the filing practices in existence today.
We anticipate that the proposed amendments that would require electronic submission or posting of documents that are currently filed in paper would not result in an increase in filing costs, and in some cases result in cost savings to reporting entities on an ongoing basis as a result of overall reduction in internal time burdens and the elimination of the printing and mailing expenses associated with paper filing. As noted,
Compared to paper filing, electronic submission or posting information directly to a website can expedite the availability of public disclosures. Improving the speed of disclosure to the public improves the price efficiency of markets by improving the timeliness of information available to market participants. Electronic submission or posting would also facilitate the Commission's ability to oversee compliance with the securities laws and its oversight of securities markets making this information available to the Commission quicker, with added and more accessible functionality for Commission staff to review, analyze, and respond to, as necessary. The structured data requirements under the proposed amendments would augment these effects, allowing the Commission—and, where applicable, the public—to draw upon comparable information from other reporting periods and from other disclosing entities in assessing the reported disclosures.
The entities primarily affected by the proposed requirements include the filers or submitters of the affected documents and the users of the affected documents. Other affected entities include third parties that may be involved with the preparation and filing or submission of the affected documents and in facilitating the use of structured data filed or submitted with the Commission, as well as parties that may indirectly benefit from the use of the affected documents by others.
Entities that currently file or submit the affected documents include SROs, including: national securities exchanges and exempt exchanges; notice-registered Security Futures Product Exchanges; registered national securities associations; and registered and exempt clearing agencies. Filers or submitters of the affected documents also include broker-dealers and registered SBS Entities (and certain affiliates thereof).
The particular entities that use (
In addition to the preparers and users of the affected documents, the other entities likely to be affected by the proposal are third-party service providers that assist in electronic filing and, in some cases, structuring, of regulatory documents, and in the facilitation of structured data use. As discussed in further detail below, the cost to filers or submitters of the proposed rules includes, in some instances, the cost of paying third-party service providers to prepare electronic and structured documents.
The Commission does not have data on the costs or structure of these services to filers or submitters of the affected documents. However, although the filers or submitters might nominally bear the costs of these services, we believe that some portion of these costs are passed on to investors indirectly. The Commission requests comment or data on the costs of these third-party service providers or how these costs are borne by filers and submitters of the affected documents.
With particular respect to structured data, entities currently subject to structured data requirements under Commission rules often pay third-party service providers to structure their disclosures, or to license structuring compliance software that allows filers or submitters to structure their disclosures internally. The specific amounts paid to third-party providers of structured data compliance services and/or software vary significantly based on a number of factors, such as the particular filing or submission on which structured data is required, the number of data points to be structured, the size of the filer or submitter, the industry to which the filer or submitter belongs, the number of individual users of the structured data compliance software, the extent to which the structuring is fully outsourced, and others. For example, smaller reporting companies are particularly likely to fully outsource their structured data preparation requirements to third-party service providers, leading to different cost dynamics than other companies that license third-party structured data preparation software and structure their disclosures in-house.
In some cases, rather than use a third-party structured data compliance service or software provider, filers or submitters will have already structured their data in-house, independently of any Commission disclosure requirements. For example, rather than paying third-party structured data compliance service providers, some filers or submitters use ERP systems or other data management platforms that include a data structuring component.
In addition, with particular respect to custom XML requirements on EDGAR forms, some filers or submitters may comply by inputting their disclosures into fillable web forms on the EDGAR website; EDGAR then converts these inputted disclosures into the applicable custom XML data language. In such instances, filers or submitters forgo the cost of paying third-party structured data compliance service providers. With respect to the proposed rule amendments, because use of the fillable form permits filers or submitters to forgo the costs of structuring, we expect most entities affected by the proposed custom XML requirements would opt to use fillable forms rather than structure directly in custom XML.
Other filers or submitters of custom XML documents choose not to use the fillable web form; instead, they structure their disclosures in the applicable custom XML data language and file or submit that structured custom XML document on EDGAR. These filers or submitters typically incur implementation costs to integrate any new or updated custom XML schemas into their data systems, and then incur decreased structured data costs after such integration. Such filers or submitters may find direct submission
While not required for structured data use, some data users (including some investors and analysts) pay third-party service providers for software that can facilitate their usage and analysis of structured data. As with structured data compliance, the specific amounts paid for third-party structured data research software vary significantly based on a number of factors, such as the number of individual software users, whether the user is an individual or an enterprise, and the particular type of functionality offered. Based on the Staff's understanding of third-party structured data research software pricing, we believe data users typically pay between $1,000 and $15,000 per year for third-party structured data research software.
Certain of the affected documents are currently filed or submitted in paper format. Specifically, the Commission's regulatory framework currently requires an entity seeking to be registered as a national securities exchange, as a clearing agency, and as a security futures product exchange, to file in a paper-based format certain forms that are mandated by rules under the Exchange Act. Filers are also required to submit paper-based amendments to their respective forms. The forms currently required to be filed in paper format include Forms 1, 1-N, X-15AA-1, X-15AJ-1, X-15AJ-2, CA-1. Form 19b-4(e) also is required to be submitted in paper format. In addition, paragraphs (d)(6) of Rule 17a-5 and (c)(6) of Rule 18a-7 provide that broker-dealer and SBS Entity annual reports, respectively, must be sent to the Commission's principal office in Washington, DC, and appropriate regional office or they may be submitted to the Commission electronically in accordance with directions provided on the Commission's website. Some broker-dealers voluntarily file annual reports electronically on EDGAR,
OTC derivatives dealer annual reports filed under Rule 17a-12 must be filed at the Commission's principal office under paragraph (p) of that rule. Further, Rule 17h-2T permits quarterly and annual risk assessment reports to be filed with the Commission in paper-based format, and Rule 17a-19 currently requires every national securities exchange and registered national securities association to file a Form X-17A-19 with the Commission in paper format at its principal office. In some circumstances, the Commission's regulatory framework currently requires or permits submission of documentation by email. Specifically, Exchange Act Rule 3a71-3(d)(1)(vi) requires the Registered Entity to provide the ANE Exception Notice by submitting it to the electronic mailbox described on the Commission's website. Further, notices made pursuant to Rule 15fi-3(c) may be made via email or on EDGAR. Annual compliance reports provided pursuant to Rule 15fk-1(c) may be submitted by an SBS Entity as a paper or electronic submission.
In addition, current Rule 17a-22 under the Exchange Act requires that within 10 days after issuing, or making generally available, to its participants or to other entities with whom it has a significant relationship, such as pledgees, transfer agents, or self-regulatory organizations, any material (including, for example, manuals, notices, circulars, bulletins, lists or periodicals), a registered clearing agency shall file three copies of such material with the Commission.
When a paper filing is received, the Commission staff scan it into PDF format, and upload it to EDGAR or make it available to Commission staff. For some filings, such as broker-dealer's annual reports, this process can take an average of a several weeks from the date of receipt of a paper filing until it is scanned and the public portion published on EDGAR, and the confidential portion available to Commission staff.
Currently, four of the affected documents may be filed or submitted electronically using EDGAR—Form X-17A-5 Part III, Form 17-H, notices made pursuant to Exchange Act Rule 15fi-3(c), and CCO reports.
Form X-17A-5 Part III elicits registrant and accountant identifying information and includes an oath or affirmation in a custom XML-based data language specific to that form.
Form 17-H is similar to Form X-17A-5 Part III in that its facing page, when filed electronically through EDGAR, is structured in a custom XML-based data language specific to Form 17-H.
In addition, the CCO reports are, when filed electronically through EDGAR, partially structured in a custom XML-based data language specific to the reports.
The broker-dealers (including OTC derivatives dealers) and non-bank SBS Entities that file Form X-17A-5 Part III and, where applicable, Form 17-H, are also subject to other structuring requirements under Commission rules. As discussed, all of these entities are required to file FOCUS Reports under Exchange Act Rule 17a-5, Rule 17a-12, or Rule 18a-7, as applicable.
Other filers or submitters of the affected documents include clearing agencies, national securities exchanges, Security Futures Product Exchanges, and registered national securities associations. None of these entities is currently subject to custom XML requirements or Inline XBRL requirements under the Commission's rules.
Thus, the affected documents currently include only a limited amount of structured data. For execution pages of electronically submitted Form X-17A-5 Part III reports, Form 17-H reports and CCO reports, the inclusion of structured identifying information on the facing page facilitates the filtering and retrieval of particular reports from particular subsets of filers or submitters. For Part II of electronically submitted Form 17-H reports, the inclusion of structured material associated person disclosures enables more efficient mathematical calculations of the disclosed numerical information. Because Form 17-H reports and CCO reports are non-public, such enhanced functionality is unavailable to parties other than Commission staff; by contrast, because the execution page of Form X-17A-5 Part III is public, such enhanced functionality is available to Commission staff and to public data users.
Electronic submissions can increase the accuracy, speed, and efficiency of the documents provided to the Commission. After an initial setup cost described below,
The proposed rule includes several amendments designed to update the FOCUS Report and related requirements. First, the release proposes amendments to FOCUS Report Part II that would allow SEC staff to compare the data reported on this page with the information being reported by firms that are FCMs, because FCMs are already required to complete this section of the form.
Second, the Commission proposes to align the text in FOCUS Report Part IIC with the text in FFIEC Form 031. Making these amendments should reduce the overall burden because information input in the proposed form will be consistent with FFIEC Form 031 (
Third, the Commission proposes to require only two of the three signature lines to be signed on the FOCUS Report's cover page, and allows these signatures to be signed either manually or electronically. In the time since the revised FOCUS Report was adopted, it has come to the Commission's attention that obtaining the signatures of all three principal officers on or close to the same day may be burdensome, especially with respect to larger firms with thousands of employees. Therefore, the Commission proposes to require only two of the three principal officers' signatures in an effort to balance the Commission's desire for individual accountability with the burden on the filer. Reducing the number of required signatures reduces the burden of submitting FOCUS reports in the long run. The use of electronic signatures would also reduce the burden in the long-run because firms would not need to obtain and store wet signatures, especially due to the increase in remote work.
Finally, the Commission proposes to require OTC derivatives dealers to file the FOCUS Report electronically on the SEC eFOCUS system instead of in paper. The SEC eFOCUS system offers benefits of electronic filing of forms over paper, reducing costs and making information more easily usable and timely.
In general, the Commission believes the proposed structured data requirements will benefit investors and markets by increasing the accessibility and usability of the disclosures in the Proposed Structured Documents, thereby increasing transparency and insight into the operations, governance, management, financial condition, and other characteristics of the affected entities. Requiring machine-readability for the disclosures would enable significantly more efficient retrieval, sorting, filtering, comparison, aggregation, and other analysis of the disclosures across reporting entities and time periods. The exact nature and magnitude of such benefits may vary based on a number of factors, which are discussed herein.
As an initial point of comparison, some research on XBRL requirements for public operating company financial statement disclosures has found that such requirements have mitigated information asymmetry by reducing information processing costs, thereby facilitating access and analysis of the disclosures on a large-scale basis.
These external parties include investors themselves, as well as other entities that process firm disclosures into conclusions that often influence investors and markets; such entities include financial analysts, data aggregators, academic researchers and financial media (collectively, “information intermediaries”).
Regulators, including the Commission, the Federal Deposit Insurance Commission (“FDIC”), and the Internal Revenue Service (“IRS”), have also been observed to leverage XBRL disclosure benefits in better fulfilling their mandates.
The enhanced monitoring facilitated by XBRL requirements has been observed to influence the behavior of firms relevant to governance and compliance, including firms' disclosure and reporting choices as well as their strategic decisions. For example, one study found that firms increase quantitative footnote disclosures upon implementation of detailed tagging requirements.
XBRL requirements have also been observed to impact the timeliness and effectiveness of firms' disclosure preparation and related processes. For example, one study found XBRL to have decreased audit report lags, especially among firms with strong internal control systems and no prior XBRL reporting experience.
The structured data benefits discussed above, while largely specific to public operating company financial statement disclosures, generally indicates that the proposed structured data requirements could facilitate the use and analysis of the information disclosed on the affected documents. Several of the affected documents that would be structured in Inline XBRL under the proposal—namely, Form X-17A-5 Part III, Form 17-H, Form 1, and Form CA-1—include financial statements that are not currently provided in a structured data language, but would be provided in a structured data language (specifically, Inline XBRL) under the proposed rule amendments. The probability that, and extent to which, the observed effects can be extrapolated are thus likely greater for those affected documents than for the remaining affected documents, which do not contain financial statements.
In addition, unlike the public company financial statement information evaluated in the literature referenced above, several of the affected documents are submitted confidentially or are otherwise non-public, either in whole or in part. This includes Form 17-H, Form X-17A-19, Form X-17A-5 Part III (in part), Form CA-1 (in part), and the CCO reports.
The benefits of structuring would also vary based on the number of entities in a particular population of reporting entities. As noted, one benefit of structured disclosure is the ability to run large-scale comparisons across reporting entities and across reporting periods. For those affected documents that have a small population of reporting entities, this benefit would be limited largely (or, in the case of Form 15A, wholly) to the latter. For those affected documents that have a large population of reporting entities (such as Form X-17A-5 Part III, which is filed by over 3,000 entities), the benefits of efficient cross-entity comparisons would be much more relevant.
Finally, the Commission expects the benefits of structuring data would vary based on the type of disclosures included in each particular affected document. Structured numerical disclosures lend themselves to mathematical functionality, such as the calculation of leverage or other ratios to assess potential exposure to insolvency or other risk. Structured textual disclosures lend themselves to period-over-period redline comparisons, targeted keyword searching, and more sophisticated sentiment analysis. The CCO report consists primarily of textual responses to required disclosure items, so the latter benefit would be relevant for that document.
For Rule 19b-4(e), numeric disclosures are required only when the disclosure of position limits for new derivative products is applicable.
For Form 15A, its execution page (
Third-party structured data service providers (including providers of structured data compliance services and/or software, as well as providers of structured data research software) would also likely realize benefits as a result of the proposed rule amendments. Most affected entities would be newly required to file or submit structured data, resulting in additional clients/customers and revenues for third-party structured data compliance service providers. Similarly, some users of the affected documents would likely seek to use third-party structured data research software to facilitate their analysis of the structured data, resulting in additional customers and revenues for third-party structured data research software providers.
The Commission is proposing a specific structured data language for each Proposed Structured Document, rather than leaving the structured data language requirement open-ended (
By contrast, an open-ended data language requirement would allow different filers or submitters of the same document to provide their disclosures in different data languages. In such instances, data users such as Commission staff and market participants would be unable to incorporate disclosures from filers or submitters using one data language into the same datasets and applications as disclosures of other filers or submitters using different data languages without undertaking data conversion processes that are frequently burdensome and imprecise. This may hinder investors, the Commission, and market participants from efficiently comparing disclosures across the complete set of entities within a given filer population, and could therefore dampen the benefits that would otherwise accrue from requiring the disclosures to be machine-readable. Thus, specifying the data language to be used may increase the probability of realizing the anticipated benefits of machine-readability for users of the Proposed Structured Documents.
As noted above, we are requesting comment on all aspects of this proposal. By specifying the structured data language to be used for each Proposed Structured Document, we invite comment, including from affected entities, on the proposed use and effects of the proposed specified data languages. As further detailed elsewhere in this economic analysis, different structured data languages have different implications (
The proposal would alter the manner in which the affected entities provide the affected documents, specifically by requiring electronic submission or posting of the affected documents, and by requiring most of the content of the affected documents to be provided in a structured data language. The affected entities already are required to prepare and submit the affected forms with the Commission pursuant to Exchange Act rules that currently govern each category of affected entity.
As discussed above, a significant number of the entities subject to the proposed rule amendments already have experience with EDGAR due to other reporting obligations and thus are not expected to incur EDGAR-related costs incremental to the proposed rule amendments. Entities that use EDGAR for purposes of complying with reporting obligations under existing rules generally are not expected to incur additional EDGAR access costs due to the proposed rule amendments.
Due to the widespread use of the internet, the cost of establishing and maintaining internet access is not expected to stem from the proposed amendments. We preliminarily believe that the costs associated with providing materials pursuant to Rule 17a-22 by registered clearing agencies on websites, and the costs associated with posting information currently required on Form 19b-4(e) by SROs, in addition to the reduced timeframe for compliance, is likely not to add significant costs to a registered clearing agencies' 17a-22 obligations or an SRO's 19b-4(e) obligations.
The proposed rule contains several amendments related to FOCUS reports, which could impose burdens on market participants. The proposed amendments to FOCUS Report Part II are expected to result in an initial burden of $2,130 on each Part II filer so firms can familiarize themselves with the amendments to FOCUS Report Part II.
The proposed amendments to Part IIC are expected to result in an initial burden of five hours on each bank SBS Entity so that firms can compare the revised FOCUS Report Part IIC with FFIEC Form 031. However, these proposed amendments are expected to either have no impact on or reduce the ongoing burden on bank SBS Entities, because they will reduce questions about how to complete FOCUS Report Part IIC consistently with FFIEC Form 031.
The proposed amendment to signature requirements for the FOCUS report is expected to result in an initial burden of $426 on each filer so that the firm can review the standards for an electronic signature on the FOCUS Report Part II, IIA, or IIC, as applicable.
The proposed amendment to OTC derivatives dealer requirements is expected to result in an initial burden of $4,740 on each OTC derivatives dealer so that the firm can familiarize itself with the SEC eFOCUS system.
The Commission expects that certain structured data requirements under the proposed amendments would impose additional compliance costs on affected entities. Specifically, the Commission believes the proposed Inline XBRL requirements for Form 1, Form CA-1, Form X-17A-5 Part III and related annual filings, Form 17-H, and the CCO reports would result in additional compliance costs, both initial and ongoing, for the SROs, broker-dealers (including OTC derivatives dealers), and SBS Entities filing or submitting those documents relative to the current baseline, because those entities would be newly required to apply Inline XBRL tags to the documents before filing or submitting them to the Commission (or pay a third-party tagging service provider to do so).
The Commission does not expect the proposed requirements to provide Form X-17A-19, the execution pages of the Covered SRO Forms, the facing page of Form X-17A-5 Part III, the facing page and Part II of Form 17-H, and the notices to the Commission (and any amendments to the notices) required by Exchange Act Rule 15fi-3(c) using custom XML-based data languages would impose similar structured data implementation costs on the SROs, broker-dealers, and SBS Entities that would be subject to those requirements. For the custom XML requirements on proposed EDGAR filings, EDGAR would provide filers or submitters with the option of using a fillable web form that would convert inputted disclosures into the relevant custom XML.
With respect to the proposed requirement for SROs to post Rule 19b-4(e) information using the custom XML schema for this information (such schema would be posted on the Commission's website), the Commission expects that the SROs would incur higher implementation costs than those affected entities that are subject to EDGAR custom XML requirements, because SROs would need to encode the posted information in accordance with the schema rather than using a fillable web form on EDGAR. This would also be the case for any entities that choose to submit EDGAR documents directly in the relevant custom XML data language rather than use the fillable form that EDGAR provides.
Various XBRL and Inline XBRL preparation solutions have been developed and used by operating companies and open-end funds to fulfill their existing structuring requirements under the Commission's rules. These existing requirements include multiple types of data, including numerical data in the context of financial statements, numerical data in the context of tables (along with the tables themselves), simple text strings, longer textual narratives, numerical data nested within textual narratives, and checkboxes.
With respect to the magnitude of Inline XBRL compliance costs, an American Institute of Certified Public Accountants (“AICPA”) survey of 1,032 public operating companies with $75 million or less in market capitalization in 2018 found an average cost of $5,850 per year, a median cost of $2,500 per year, and a maximum cost of $51,500 per year for fully outsourced XBRL creation and filing.
This observed variance in XBRL and Inline XBRL compliance costs is likely attributable to variance in the number of discrete disclosures (including numbers, blocks of narrative text, checkboxes, etc.) contained in a tagged document, as well as the complexity of the specific disclosures to be tagged. Larger, more organizationally complex entities are likely to have more detailed and complex financial statements (including footnotes and schedules), and thus have more tags that they will need to apply to their documents, typically resulting in higher compliance costs (as described in further detail below in this section).
The affected documents that the Commission is proposing to be required to be structured in Inline XBRL under the proposed rule amendments consist of the same data types as the documents that are currently required to be structured in Inline XBRL (
The Commission believes the compliance costs associated with the proposed structured data requirements, as adjusted for inflation, would likely decrease over time. Affected entities would likely comply with structuring requirements more efficiently after gaining experience over repeated filings, though such an effect would likely be diminished for affected entities that already have experience structuring similar data in other documents. Third-party vendors of structured data compliance software or services may decrease the prices of their products over time; the XBRL compliance costs reported in the 2018 AICPA survey of smaller operating companies reflect such a trend, as they represented a 45% decline in average cost and a 69% decline in median cost from 2014.
The Commission expects the direct relationship between filer size and compliance costs described earlier in this section would apply to Inline XBRL compliance costs that would arise under the proposed rule amendments, and would be particularly relevant to Form X-17A-5 Part III filers (which include broker-dealers—including OTC derivatives dealers—and non-bank SBS Entities) for two reasons. First, like public operating companies, Form X-17A-5 Part III filers would be tagging financial statements (including footnotes and schedules) in Inline XBRL under the proposal.
We expect the correlation between entity size and tagging cost to be less relevant to the other populations of entities that would be subject to Inline XBRL requirements under the proposal, because those populations are more limited in number and in the variation of size and complexity across entities within those populations. For example, Form CA-1 is filed by clearing agencies, including registered and exempt clearing agencies; there are currently 12 such entities in operation.
Some entities that would file or submit the documents to be structured in Inline XBRL under the proposal may be affiliated with entities that are subject to Inline XBRL requirements in other filings. For example, 17 of the 24 national securities exchanges are affiliated with public companies that file financial statements and cover page information in EDGAR in Inline XBRL.
As noted above, the Commission is proposing specific structured data languages for each Proposed Structured Document, rather than leaving the structured data language requirement open-ended (
For Form 1, Form CA-1, Form X-17A-5 Part III, Form 17-H, and the CCO reports, the proposed approach of requiring Inline XBRL for some parts of the document and custom XML for other parts of the document would entail drawbacks for users of the information (including Commission staff and market participants). Specifically, data users would be unable to incorporate the Inline XBRL disclosures on a given filing or submission into the same datasets and applications as the custom XML disclosures on that filing, and would be unable to run analyses that incorporate both types of information without undertaking data conversion processes that are frequently burdensome and imprecise. Similarly, any technical validations programmed into EDGAR would be unable to check for any inappropriate inconsistencies between disclosures on Inline XBRL portions and disclosures on custom XML portions of a given filing, thus reducing the benefit of improved data quality that would be likely to result from structured data requirements.
With respect to specific estimated cost ranges for Form X-17A-5 Part III and Form 17-H filers to structure their filings under the proposal, we believe the aforementioned AIPCA survey, which polled roughly 1,000 small reporting companies and found a median and average annual cost of XBRL filing of $2,500 and $5,850, respectively, is likely relevant to the majority of Form X-17A-5 Part III filers. In 2017, the 1,000 smallest reporting companies by asset size reported total assets of approximately $8 million or less. As of December 31, 2021, approximately 70% of Form X-17A-5 Part III filers fell within that $8 million total asset size threshold. For these smaller Form X-17A-5 Part III filers, we estimate the approximate median cost of tagging financial statements on Form X-17A-5 Part III by using the median annual cost estimate from the AICPA survey ($2,500) and dividing it by four, because the respondents in the AICPA survey prepared tagged financial statements on a quarterly rather than annual basis. Using the resulting figure ($625) as a midpoint and establishing lower and upper bounds at 50% of the midpoint, we estimate smaller Form X-17A-5 Part III filers would incur an approximate median per filing cost of $310-$940 to structure their financial statements in Inline XBRL.
For the larger Form X-17A-5 Part III filers (
In addition to the financial statements, footnotes, and schedules, Form X-17A-5 Part III also requires a series of reports (including accountant's reports, compliance reports, exemption reports, and supplemental reports).
A subset of larger Form X-17A-5 Part III filers also file Form 17-H and would thus be required to tag their quarterly financial statements in addition to their annual financial statements.
Other portions of Form 17-H (namely, the facing page and the material associated positions and holdings disclosure) are currently structured in a custom XML data language specific to Form 17-H, and this would remain the case under the proposal. Because nearly all broker-dealers subject to Form 17-H filing requirements currently file Form 17-H via EDGAR, they are already submitting this information in that custom XML language.
The Covered SRO Forms (Form CA-1, Form 1, Form 1-N, Form 15A, Form X-17A-19) and the information required to be posted under Rule 19b-4(e) would require some or all of the information reported on the forms or postings to be provided in a structured data language. Here, we provide estimated ranges for the approximate cost that affected entities would incur to structure Forms CA-1, Form 1, and the Rule 19b-4(e) information. With respect to Form X-17A-19, due to the brevity and simplicity of that Form, we anticipate SROs would not structure their disclosures in custom XML themselves, but would instead simply input their disclosures in the fillable web form that EDGAR would provide. Thus, we do not believe a cost estimate for the structuring of Form X-17A-19 in custom XML would be relevant or appropriate to include. For the same reason, we have not included estimated custom XML structuring cost ranges for the facing pages to Form CA-1, Form 1, Form 1-N, and Form 15A. Because the facing pages of Form 1-N and Form 15A would be the only structured portion of those forms, we have not provided any estimated structuring cost ranges for them.
Clearing agencies filing Form CA-1 would be required to tag their financial statements and a series of schedules containing largely narrative disclosures in Inline XBRL. For the financial statements, because clearing agencies likely operate at a higher level of complexity than the median Nasdaq-listed reporting company, we estimate a 25% higher cost than the cost reported in the Nasdaq survey, resulting in an approximate per filing cost estimate of $4,690-$14,070 for clearing agencies to tag financial statements in Inline XBRL. For the disclosures other than financial statements, the disclosure schedules on Form CA-1 to be tagged in Inline XBRL are considerably lengthier than the supplemental reports on Form X-17A-5 Part III discussed above. We therefore estimate tagging the non-financial statement disclosures on Form CA-1 would add 25% of the costs to tag financial statements in Inline XBRL, resulting in a median per filing cost estimate of approximately $1,180-$3,530 for clearing agencies to tag the non-financial statement disclosures on Form CA-1 in Inline XBRL. This results in a total estimated Inline XBRL tagging cost of $5,870-$17,600 per filing on Form CA-1.
Clearing agencies would be required to structure other Form CA-1 disclosures using a custom XML data language specific to that Form. The Commission recently estimated that the structuring of disclosures of Form N-CR event reports in custom XML would cost approximately $555 per filing. Here, the Form CA-1 disclosures to be structured in custom XML are lengthier than the Form N-CR disclosures that money market funds would structure in custom XML under that proposal, so we estimate an approximate cost per filing of $560-$1,670 (using a 50% increase over the Form N-CR estimate) that clearing agencies would structure the Form CA-1 schedules in custom XML.
For national securities exchanges, we estimate the cost to tag financial statements on Form 1 in Inline XBRL would be similar to the cost that large broker-dealer affiliates of reporting companies would incur to tag financial
Exchanges would also tag their manner of operation disclosure in Inline XBRL under the proposal.
By contrast, for the Rule 19b-4(e) information that exchanges would post on their websites in a custom XML data language (
Under the proposal, SBS Entities would be required to structure the valuation dispute notices required under Exchange Act Rule 15fi-3(c) in a custom XML data language specific to those notices, and they would also be required to structure the CCO report required under Exchange Act Rule 15fk-1(c)(2)(ii)(A) in Inline XBRL. In addition, non-bank SBS Entities would be required to file Form X-17A-5 Part III and related annual filings in Inline XBRL; the structuring costs associated with that form are discussed above.
For Rule 15fi-3(c) valuation dispute notices, which are not required to include specific fields, we expect SBS Entities would use the fillable web form that EDGAR would provide rather than structure the disclosures in the custom XML data language themselves.
For the Inline XBRL tagging of the CCO report, those reports consist of a series of narrative text blocks, some of which could contain nested quantitative values (such as the description of financial resources set aside for compliance). This content is similar to the content of the narrative disclosures on Form CA-1 that clearing agencies would structure in Inline XBRL under the proposed amendments, which we estimate as $1,180 to $3,530. Most SBS Entities, however, are affiliated with public reporting companies that already structure disclosures in Inline XBRL.
The structured data cost estimates discussed above relate to the ongoing costs of structuring various disclosures in Inline XBRL and in custom XML-based data languages. For affected entities that do not have structured data compliance experience, and are not affiliated with entities that have structured data compliance experience, we estimate compliance costs would increase by 50% in the first year of the proposed structured data requirements. We anticipate these initial implementation costs, which could include the training of new staff and the establishing of new compliance procedures, would apply only to those filers or submitters that do not fully outsource their structured data preparation requirements to a third-party tagging service provider (
The impact of this initial implementation cost overall is reflected in the following chart:
Form 17-H is excluded from the table above, because Form 17-H filers also file Form X-17A-5 Part III. Including initial implementation costs for structuring financial statements on Form 17-H would be duplicative of the initial implementation costs for structuring financial statements on Form X-17A-5 Part III, which are reflected in the table.
For Rule 19b-4(e) information, we anticipate the initial implementation costs would apply only to the first posting, and not to subsequent postings during the first year of compliance. The content required by Rule 19b-4(e) is limited to less than 10 individual items of disclosure regarding the newly traded derivative securities product for each posting. We expect the process of structuring, rendering, and posting the first response would entail additional implementation time to map the associated (and commensurately simple) custom XML schema to the information regarding the new derivative securities product traded on the exchange; we expect subsequent responses would entail a less burdensome process of applying the newly mapped schema to each derivative securities product.
Mandated electronic submission and posting will increase the timeliness of public access to the affected documents that are made publicly available. Insofar as market participants use the information in these documents, easier or quicker access could result in lower search costs or more efficient decision making. These benefits are potentially magnified during disruptive events, such as a pandemic, when investors may place a premium on electronic and timely access to information. Furthermore, the efficiency benefits of electronic submission or posting may be augmented by the proposed structured data requirements, as structured data requirements have been observed to decrease information asymmetries, increase liquidity, and reduce the cost of capital.
Moreover, as mandated electronic submission or posting leads to lower ongoing, marginal costs for reporting entities, compared to non-electronic submission, the submission or posting process may become more efficient, especially over the medium and longer term. In addition, electronic submission or posting standards in the proposed amendments are expected to make the submission or posting process more efficient by making it easier and less costly for reporting entities to assure timely receipt and/or availability of the submitted information. We expect, however, that any such efficiency gains would be small. The efficiency gains that would arise under the proposed rule would likely be further mitigated in the near term because, as noted, the proposed Inline XBRL requirements would impose initial implementation costs on affected entities subject to the requirements that do not have prior experience with Inline XBRL.
As discussed above, similar implementation costs are unlikely to arise for most of the proposed EDGAR custom XML forms, because EDGAR would provide a fillable web form in which affected entities would be able to input their disclosures without having to structure them in the relevant custom XML data language. By contrast, implementation costs are likely to arise for SROs subject to the proposed custom XML schema requirement for posting Rule 19b-4(e) information, because those would be posted on the SROs' websites rather than filed through EDGAR; however, due to the relatively small amount of data to be structured, rendered, and posted for each new derivative securities product, we expect the cost of structuring each Form 19b-4(e) would be lower than the cost of structuring Commission filings in Inline XBRL.
The costs and benefits of electronic submission or posting under the proposed rule may have differential impacts on some categories of reported entities, resulting in potential competitive effects. To the extent that the EDGAR cost has a fixed component, smaller entities that do not have experience with EDGAR may be at a relative competitive disadvantage to larger entities. In addition, smaller registrants might use third party service providers to meet the requirements of the proposed amendments. The use of these providers could reduce the costs of EDGAR access, and reduce the competitive effects of the requirements.
For the proposed Inline XBRL requirements, it is less likely that the associated compliance costs would be fixed, because the documents filed or submitted by smaller entities (such as smaller broker-dealers) are likely shorter and less complex than documents filed or submitted by larger entities (such as larger broker-dealers), and would thus require less time and sophistication to tag in Inline XBRL. By contrast, compliance costs for the proposed custom XML requirements are more likely to be fixed, because with the exception of Form 1 and Form CA-1 filers and SROs posting Rule 19b-4(e) information, we expect affected filers or submitters to comply with such requirements by completing fillable web forms rather than structuring their disclosures in custom XML.
To the extent that market practices are already consistent with the Updated Staff Statement, many of the expected effects of the proposed amendments on efficiency, competition, and capital formation may be mitigated. For example, for broker-dealer registrants that file reports pursuant to Rule 17a-5 electronically, the efficiency gains of electronic submission will be mitigated, and the effects of the proposed amendments will be limited to those associated with the use of structured data.
As an alternative, the Commission could change the scope of the proposed structured data requirements (
As another alternative, the Commission could require structuring Form 1-N, Form 15A, and the ANE Exception Notices to the same extent as comparable Proposed Structured Documents. For example, the Commission could require Form 1-N and Form 15A, which are similar to Form CA-1 and Form 1 in that they contain substantive disclosures in exhibits to an execution page, to be structured using a mix of Inline XBRL and custom XML data languages. The Commission could also require ANE Exception Notices, which contain only a limited number of data points, to be structured using a custom XML data language. Structuring these documents would extend the analytical capabilities associated the other structured data requirements in this proposal to these additional documents. However, the
As another alternative, the Commission could replace the proposed custom XML requirements with Inline XBRL requirements for some or all of the relevant Proposed Structured Documents (which include Form X-17A-5 Part III, Form 17-H, Form CA-1, Form 1, Form 1-N, Form 15A, Form X-17A-19, Rule 19b-4(e) information, notices of security-based swap valuation disputes pursuant to Rule 15fi-3(c), and CCO reports). For example, rather than requiring Inline XBRL structuring for certain of the affected documents, and custom XML structuring for other affected documents, the Commission could require Inline XBRL for all of the affected documents proposed to be structured (
This alternative could benefit users of the data in that the reported information could be used compatibly (
The Commission could alternatively replace the proposed Inline XBRL requirements with custom XML requirements for some or all of the relevant Proposed Structured Documents (which include Form X-17A-5 Part III, Form 17-H, Form CA-1, Form 1, and CCO reports). However, while this could lead to benefits such as smaller file sizes and lower compliance burdens (to the extent entities would input disclosures into fillable forms rather than structuring the disclosures themselves), Inline XBRL is more technically suited to handle financial statement disclosures (and was originally designed to so), as well as extended narrative discussions (including those with individual values nested within the discussions). Accordingly, the Commission believes Inline XBRL as proposed for these forms is appropriate.
As another alternative, the Commission could require structured data languages other than Inline XBRL and custom XML for some or all of the affected documents. For example, the Commission could require other variants of XBRL, such as XBRL-CSV (“Comma-Separated Values”) or XBRL-JSON (“JavaScript Object Notation”). For example, we are aware that public commenters in other rulemakings have indicated that using these XBRL variants could entail benefits, such as smaller file sizes and greater ease of use.
Other structured data languages that could be used include the Financial Information eXchange Markup Language (“FIXML”), which the Commission recently proposed for security-based swap position reporting, and pipe-delimited ASCII, which the Rule 605 NMS Plan currently requires for market centers' order execution reports.
As another alternative, the Commission could replace some or all of the proposed structured data requirements with voluntary structuring provisions. This would provide greater flexibility to respondents and ease compliance burdens on any respondents that choose not to structure their filings or postings. Some respondents may be incentivized by the benefits of structured data, and thus pursue those benefits even in the absence of structured data requirements, such as
As another alternative, the Commission could exempt smaller entities from electronic submission or posting requirements for some or all of the affected documents. This could take the form of some thresholds based on total assets, total annual revenues, net capital requirements, a combination of factors, or the type of entity (
While this alternative could reduce the cost burden to smaller entities, this alternative would also eliminate the benefits of electronic submission and posting for these entities, such as the reduction of costs and the improved efficiency of the submission process. In addition, exempting smaller entities from the submission or posting requirements might reduce the value of publicly available data if the result is that only a portion of the submissions are machine-readable or if multiple methods are required to access all the data as might occur if some portion of forms are submitted electronically via EDGAR while other submissions of the same form are made publicly available as PDFs of paper submissions.
As another alternative, rather than requiring the information required by Rule 19b-4(e) under the Exchange Act to be posted on an SRO's website in custom XML, the Commission could amend Rule 19b-4, Form 19b-4(e), and the instructions thereto to require SROs to submit Form 19b-4(e) with the Commission via EDGAR using custom XML. Compared to the proposal, an EDGAR alternative could provide benefits for users of the information, because they would be able to access and analyze disclosures across different SROs from a centrally accessible location, rather than having to navigate to various individual SRO websites to retrieve the disclosures. EDGAR would also provide the ability to run technical validations upon intake of the disclosures, thus potentially improving the quality of the 19b-4(e) data by decreasing the incidence of non-substantive errors (
As another alternative, the Commission could require registrants submit by sending some or all of the affected documents to a dedicated email inbox in addition to eliminating the paper requirement. For example, rather than requiring registered clearing agencies to post Rule 17a-22 materials on their websites, the Commission could require registered clearing agencies to submit electronic copies of Rule 17a-22 materials to a dedicated email inbox, as they have been doing recently, consistent with the Updated Staff Statement.
The Commission requests feedback on any aspect of the above economic analysis, including our description of the current economic baseline, the potential costs (including quantified estimates thereof) and benefits of the proposed amendments, their effect on efficiency, competition, and capital formation, and reasonable alternatives. In addition, we request comment on the following aspects of the proposal:
96. In general, are there any affected entities for whom the compliance costs associated with the proposed structured data requirements would not be justified by the informational benefits that would be realized by users of the structured data, such that exempting those entities from structured data requirements would be advisable? If so, what particular exemption threshold or thresholds should the Commission use for the structured data requirements under the proposed rule amendments, and why?
97. For example, with respect to Form X-17A-5 Part III filers, would the compliance costs incurred by smaller broker-dealers, or non-clearing/carrying broker-dealers, in filing Form X-17A-5 Part III and related annual filings in Inline XBRL not be justified by the benefits arising to data users from having the information in a structured, machine-readable data language? Should the Commission use an exemption threshold for Form X-17A-5 Part III filers based on total assets (
98. Similarly, are there any affected documents (or portions thereof) subject to proposed structuring requirements (
99. For example, should the Commission refrain from adding structuring requirements for Form CA-1, which is filed by only twelve entities, for the same reason the Commission is refraining from adding structured data requirements (other than execution page structuring) for Form 15A and Form 1-N, which are each filed by only one entity?
100. Conversely, are there any affected documents or portions thereof not subject to proposed structuring requirements (
101. How would the costs of third-party service providers, including those that provide electronic submission and structured data compliance services and/or software to filers and submitters, as well as those that provide software that facilitates structured data research, impact affected entities and data users under the proposed rule amendments? Please provide any data you have on the current costs and usage of these third-party services and software, as well as how such costs and usage may change under the proposed rule amendments.
102. Does the evidence of structured data benefits in other contexts, such as XBRL requirements for public operating company financial statements, generally indicate that the proposed structured data requirements could facilitate the use and analysis of the information disclosed on the affected documents? Why or why not?
103. Is it reasonable to assume that affected entities with affiliates that are subject to Inline XBRL requirements would be able to leverage the Inline XBRL compliance software licenses and/or service agreements, as well as the Inline XBRL tagging processes and experience, of those affiliates? Why or why not?
104. Should the Commission modify the particular structured data languages required for each Proposed Structured Document? For example, should the Commission replace the proposed custom XML requirements with Inline XBRL requirements, or vice versa? Should the Commission require other structured data languages, such as XBRL-CSV, XBRL-JSON, FIXML, pipe-delimited ASCII, or other structured data languages for some or all of the Proposed Structured Documents? If so, which structured data languages should be used for which documents, and why?
105. Rather than requiring structured data for the Proposed Structured Documents, should the Commission permit affected entities (or subsets thereof) to provide structured data on a voluntary basis? If so, which entities and which documents should be subject to voluntary structuring, and why?
106. Also, are there any affected documents for which the proposed manner of submission or posting creates significant costs or difficulties for reporting entities or for users of the documents? If so, which particular documents, and how should the manner of submission be changed for those documents?
Section 3(a) of the Regulatory Flexibility Act of 1980
The Commission currently believes that no national securities exchange, Security Futures Product Exchange, or national securities association is a “small entity” as currently defined. With regard to clearing agencies, based on publicly reported data the Commission does not believe that any registered or exempt clearing agency is a “small entity” as currently defined. With respect to registrants subject to Rule 17a-12, based upon financial reports and other information filed with the Commission by such entities, none of the entities subject to Rule 17a-12 is a “small entity” as currently defined. With respect to SBS Entities, based on feedback from market participants and staff experience with the security-based swap markets, and consistent with the Commission's position in prior Dodd-Frank Act rulemakings, the Commission continues to believe that (1) the types of entities that register with the Commission as SBSDs (
The Commission encourages written comments regarding this certification. The Commission solicits comment as to whether the proposed amendments could have impacts on small entities that have not been considered. The Commission requests that commenters describe the nature of any impacts on small entities and provide empirical data to support the extent of such effect. Persons wishing to submit written comments should refer to the instructions for submitting comments located at the front of this release.
This Initial Regulatory Flexibility Act Analysis (“IRFA”) has been prepared, and been made available for public comment, in accordance with the RFA.
In general, the proposed amendments to Rule 17a-5 that implicate broker-dealers that are small entities would require that a broker-dealer: (1) file its annual reports and related annual filings electronically on EDGAR using structured data; and (2) keep the original notarized oath or affirmation for a period of not less than six years, the first two in an easily accessible place in accordance with the requirements of Rule 17a-4.
As stated above, it has been the staff's experience that electronic filing has been practical and efficient. It also has been the staff's experience that electronic filing has been positively received by the broker-dealers who are currently filing their annual reports electronically on EDGAR. Based on these positive experiences with electronic filing and as part of its efforts to modernize the methods by which it collects information from registrants, the Commission is proposing to amend certain rules and forms, including certain rules and forms that would impact broker-dealers that are small entities.
With respect to the proposed structured data requirements, XBRL requirements for public company financial statements have been observed to increase the ease and efficiency of
The Commission is proposing the amendments in this release under the authority set forth in sections 6, 7, 8, 10, and 19(a) of the Securities Act of 1933,
The proposed changes would affect some broker-dealers that are small entities. For purposes of Commission rulemaking in connection with the RFA,
As noted above, the purpose of the proposed amendments to Rule 17a-5 that would impact a broker-dealer that is a small entity is to require a broker-dealer to: (1) file its annual reports on EDGAR using structured data; and (2) keep the original notarized oath or affirmation attached to the annual reports for a period of not less than six years, the first two in an easily accessible place in accordance with the requirements of Rule 17a-4.
The Commission does not believe that the compliance costs of the proposed amendments relating to the requirement to file on EDGAR will be significant. The Commission does expect that smaller entities that are broker-dealers will need to familiarize themselves with the EDGAR system. However, the Commission does not believe that the familiarization process will be particularly burdensome. In support of its belief in this regard, the Commission notes that approximately 1,659 broker-dealers have chosen to voluntarily file their respective annual reports on EDGAR, and the Commission estimates that a large majority of these broker-dealers are small entities. Furthermore, with respect to the proposed structured data requirements, the Commission believes the related compliance costs for broker-dealers that are small entities would be modest and would continue to decrease over time. The Commission bases this belief on observed trends in XBRL compliance costs for small public companies.
The Commission also believes that there will be benefits to small entities resulting from filing on EDGAR. For example, once a smaller entity has familiarized itself with EDGAR, that entity can be confident that required filings will be timely because the public portion of the filing is immediately available on the Commission's website and the filer has received a confirming email. The Commission believes that such regulatory certainty is of benefit to registrants generally, including broker-dealers that are small entities.
With respect to the requirement to maintain a copy of the oath or affirmation, the Commission does not believe this requirement will be unduly burdensome to small entities that are broker-dealers. A broker-dealer filing its annual reports in paper maintains a hard copy of the filing cover sheet as a record of the oath or affirmation. The proposed amendment in paragraph (e)(2)(iii) of Rule 17a-5 is designed to ensure that this requirement is preserved in the context of a broker-dealer filing its annual reports electronically on EDGAR.
The Commission does not believe that the proposed amendments impacting smaller entities that are broker-dealers would duplicate, overlap, or conflict with other Federal Rules.
The RFA directs the Commission to consider alternatives that would accomplish our stated objectives, while minimizing any significant economic impact on small entities. The Commission considered alternatives with respect to whether to utilize the EDGAR system. However, given that approximately half of all broker-dealers are voluntarily utilizing EDGAR for filing their respective annual audit reports, and that EDGAR is an existing system that is available for immediate use, the Commission does not believe that alternative electronic platforms would be practical or efficient. Further, developing an alternative technology platform for intake of annual audit reports or change in SRO membership would be time consuming and expensive relative to using an existing Commission system that is in use by a large number of broker-dealers. The Commission considered exempting small entities from the EDGAR-filing requirement and allowing small entities to make submissions via dedicated email or similar means, but there are significant efficiencies for Commission staff and other users of regulatory disclosure information in having the forms submitted to a single, uniform platform, and, as mentioned, EDGAR is the Commission's existing platform for the receipt and publication (in the case
The Commission also considered alternatives with respect to the proposed structured data requirements, including the alternative of removing broker-dealers that are smaller entities from the structured data requirements.
Likewise, the Commission considered changing the actual forms themselves—either by consolidating or simplifying the information to be submitted—for small entities, but allowing a subset of entities to submit different forms—and accompanying information—would reduce the usability and comparability of the information contained in disclosures. The Commission does not believe that the cost savings that might arise from devising different forms for small entities would justify the limitations and difficulties that would arise for investors, market participants and/or regulatory users of the information.
Finally, the Commission considered allowing small broker-dealers a longer timeframe to file on EDGAR so they have time to familiarize themselves with the system, but given that a staff no-action letter already does not object to small broker-dealers filing their annual reports within a longer timeframe so long as they file on EDGAR,
The Commission encourages the submission of comments with respect to any aspect of this IRFA. In particular, the Commission requests comment regarding:
107. Are there are more efficient or less burdensome ways for the Commission to modernize its collection of information from registrants compared to what the Commission has proposed?
108. What are the number of small entities that may be affected by the proposed rule amendments?
109. What is the existence or nature of the potential impact of the proposed amendments on small entities and would the proposed amendments would have any effects that have not been discussed in the analysis?
110. Are there are any Federal rules that duplicate, overlap, or conflict with the proposed amendments?
For purposes of the Small Business Regulatory Enforcement Fairness Act of 1996 (“SBREFA”),
• An annual effect on the U.S. economy of $100 million or more (either in the form of an increase or decrease);
• A major increase in costs or prices for consumers or individual industries; or
• Significant adverse effects on competition, investment, or innovation.
The Commission requests comment on whether the proposal would be a “major rule” for purposes of SBREFA. In particular, we request comment and empirical data on:
• The potential effect on the U.S. economy on an annual basis;
• Any potential increase in costs or prices for consumers or individual industries; and
• Any potential effect on competition, investment, or innovation.
The amendments contained in this release are being proposed under the authority in sections 6, 7, 8, 10, and 19(a) of the Securities Act of 1933,
Administrative Practice and Procedure, Securities.
Reporting and recordkeeping requirements, Securities.
Brokers, Fraud, Reporting and recordkeeping requirements, Securities, Swaps.
Brokers, Reporting and recordkeeping requirements, Securities.
Brokers, Reporting and recordkeeping requirements.
In accordance with the foregoing, title 17, chapter II of the Code of Federal Regulations is proposed to be amended as follows:
15 U.S.C. 77s, 77t, 77sss, 77uuu, 78d-1, 78u, 78w, 78
(b) * * *
(2) Applications for registration as national securities exchanges, or exemption from registration as exchanges by reason of such exchanges' limited volume of transactions filed with the Commission are routed to the Division of Trading and Markets, which examines these applications to determine whether all necessary information has been supplied and
(3) Notice forms for registration as national securities exchanges pursuant to Section 6(g)(1) of the Securities Exchange Act of 1934 (15 U.S.C. 78f(g)(1)) filed with the Commission are routed to the Division of Trading and Markets, which examines these notices to determine whether all necessary information has been supplied and whether all other required documents have been furnished in proper form. Defective notices may be returned.
15 U.S.C. 77c, 77f, 77g, 77h, 77j, 77s(a), 77z-3, 77sss(a), 78c(b), 78l, 78m, 78n, 78o(d), 78
(c) Persons or entities whose filings are subject to review by the Division of Trading and Markets; and
The revisions and additions read as follows:
(a) * * *
(1) * * *
(xxxii)(A) The annual reports filed with the Commission under § 240.17a-5(d) of this chapter, the supplemental reports and statements filed with the Commission under § 240.17a-5(k) of this chapter, the annual reports filed with the Commission under § 240.17a-12(b) of this chapter, the accountant's reports filed with the Commission under § 240.17a-12(k), (l), and (m) of this chapter, the reports filed with the Commission under § 240.17a-19 of this chapter, and the annual reports filed with the Commission under § 240.18a-7(c) of this chapter. The submissions must be made on EDGAR in the electronic format required by the EDGAR Filer Manual, as defined in 17 CFR 232.11 (Rule 11 of Regulation S-T), and must be filed in accordance with the requirements of part 232 (Regulation S-T).
(B) The reports filed and furnished, as applicable, with the Commission under § 240.17h-2T of this chapter. The submissions must be made on EDGAR in the electronic format required by the EDGAR Filer Manual, as defined in Rule 11 of Regulation S-T, and must be filed in accordance with the requirements of Regulation S-T.
(xxxiii) Notices (and withdrawals of notices) filed with the Commission pursuant to § 240.3a71-3(d)(1)(vi) of this chapter (Rule 3a71-3(d)(1)(vi)).
(xxxiv) Notices (and amendments, including notices of dispute termination) provided to the Commission pursuant to § 240.15fi-3(c) of this chapter (Rule 15fi-3(c)); and
(xxxv) Compliance reports submitted with the Commission pursuant to § 240.15fk-1(c)(2)(ii)(A) of this chapter (Rule 15fk-1(c)(2)(ii)(A)).
(c) * * *
(9) Exchange Act filings submitted to the Division of Trading and Markets other than those that are submitted in electronic format as mandated or permitted electronic submissions under paragraph (a) and (b) of this section or that are submitted electronically in a filing system other than EDGAR;
(d) The following must be filed in electronic format:
(1) All documents, including any information with respect to which confidential treatment is requested, filed pursuant to section 13(n) (15 U.S.C. 78m(n)) and section 13(f) (15 U.S.C. 78m(f)) of the Exchange Act and the rules and regulations thereunder;
(2) All documents, including any information with respect to which confidential treatment is requested, filed pursuant to §§ 240.17a-5(d), 240.17a-5(k), 240.17a-12(b), 240.17a-12(k) through (m), 240.17a-19, 240.17h-2T, or 240.18a-7(c) of this chapter; and
(3) All notices (and amendments, including notices of dispute termination), including any information with respect to which confidential treatment is requested, provided to the Commission pursuant to § 240.15fi-3(c) of this chapter.
The revisions and additions read as follows:
This section applies to electronic filers that submit Interactive Data Files. Section 229.601(b)(101) of this chapter (Item 601(b)(101) of Regulation S-K), General Instruction F of § 249.311 (Form 11-K), §§ 240.15fk-1(c)(2)(ii)(A), 240.17a-5(d)(6)(i), 240.17a-5(k)(2), 240.17a-12(b)(6), 240.17a-12(k), 240.17a-12(l), 240.17a-12(m), 240.17h-2T(a)(2), and 240.18a-7(c)(6) of this chapter (Rules 15fk-1(c)(2)(ii)(A), 17a-5(d)(6)(i), 17a-5(k)(2), 17a-12(b)(6), 17a-12(k), 17a-12(l), 17a-12(m), 17h-2T(a)(2), and 18a-7(c)(6) under the Exchange Act), paragraph (101) of Part II—Information Not Required to be Delivered to Offerees or Purchasers of § 239.40 of this chapter (Form F-10), paragraph 101 of the Instructions as to Exhibits of § 249.220f of this chapter (Form 20-F), paragraph B.(15) of the General Instructions to § 249.240f of this chapter (Form 40-F), paragraph C.(6) of the General Instructions to § 249.306 of this chapter (Form 6-K), § 240.17ad-27(d) of this chapter (Rule 17ad-27(d) under the Exchange Act), Note D.5 of § 240.14a-101 of this chapter (Rule 14a-101 under the Exchange Act), Item 1 of § 240.14c-101 of this chapter (Rule 14c-101 under the Exchange Act), General Instruction C.3.(g) of §§ 239.15A and 274.11A of this chapter (Form N-1A), General Instruction I of §§ 239.14 and 274.11a-1 of this chapter (Form N-2),
(a) * * *
(2) Be submitted only by an electronic filer either required or permitted to submit an Interactive Data File as specified by § 229.601(b)(101) of this chapter (Item 601(b)(101) of Regulation S-K), General Instruction F of § 249.311 (Form 11-K), §§ 240.15fk-1(c)(2)(ii)(A), 240.17a-5(d)(6)(i), 240.17a-5(k)(2), 240.17a-12(b)(6), 240.17a-12(k), 240.17a-12(l), 240.17a-12(m), 240.17h-2T(a)(2), and 240.18a-7(c)(6) of this chapter (Rules 15fk-1(c)(2)(ii)(A), 17a-5(d)(6)(i), 17a-5(k)(2), 17a-12(b)(6), 17a-12(k), 17a-12(l), 17a-12(m), 17h-2T(a)(2), and 18a-7(c)(6) under the Exchange Act), paragraph (101) of Part II—Information Not Required to be Delivered to Offerees or Purchasers of § 239.40 of this chapter (Form F-10), paragraph 101 of the Instructions as to Exhibits of § 249.220f of this chapter (Form 20-F), paragraph B.(15) of the General Instructions to § 249.240f of this chapter (Form 40-F), paragraph C.(6) of the General Instructions to § 249.306 of this chapter (Form 6-K), § 240.17ad-27(d) of this chapter (Rule 17ad-27(d) under the Exchange Act), Note D.5 of § 240.14a-101 of this chapter (Rule 14a-101 under the Exchange Act), Item 1 of § 240.14c-101 of this chapter (Rule 14c-101 under the Exchange Act), General Instruction C.3.(g) of §§ 239.15A and 274.11A of this chapter (Form N-1A), General Instruction I of §§ 239.14 and 274.11a-1 of this chapter (Form N-2), General Instruction C.3.(h) of §§ 239.17a and 274.11b of this chapter (Form N-3), General Instruction C.3.(h) of §§ 239.17b and 274.11c of this chapter (Form N-4), General Instruction C.3.(h) of §§ 239.17c and 274.11d of this chapter (Form N-6), General Instruction C.4 of §§ 249.331 and 274.128 of this chapter (Form N-CSR), General Instruction A of § 249.1 of this chapter (Form 1), or General Instruction A of § 249b.200 of this chapter (Form CA-1), as applicable;
(3) * * *
(i) If the electronic filer is not a management investment company registered under 15 U.S.C. 80a
(ii) If the electronic filer is a management investment company registered under 15 U.S.C. 80a
(4) Be submitted in accordance with the EDGAR Filer Manual and, as applicable, § 229.601(b)(101) of this chapter (Item 601(b)(101) of Regulation S-K), General Instruction F of § 249.311 of this chapter (Form 11-K), §§ 240.15fk-1(c)(2)(ii)(A), 240.17a-5(d)(6)(i), 240.17a-5(k)(2), 240.17a-12(b)(6), 240.17a-12(k), 240.17a-12(l), 240.17a-12(m), 240.17h-2T(a)(2), and 240.18a-7(c)(6) of this chapter (Rules 15fk-1(c)(2)(ii)(A), 17a-5(d)(6)(i), 17a-5(k)(2), 17a-12(b)(6), 17a-12(k), 17a-12(l), 17a-12(m), 17h-2T(a)(2), and 18a-7(c)(6) under the Exchange Act)15fk-1, paragraph (101) of Part II—Information Not Required to be Delivered to Offerees or Purchasers of § 239.40 of this chapter (Form F-10), paragraph 101 of the Instructions as to Exhibits of § 249.220f of this chapter (Form 20-F), paragraph B.(15) of the General Instructions to § 249.240f of this chapter (Form 40-F), paragraph C.(6) of the General Instructions to § 249.306 of this chapter (Form 6-K), § 240.17ad-27(d) of this chapter (Rule 17ad-27(d) under the Exchange Act), Note D.5 of § 240.14a-101 of this chapter (Rule 14a-101 under the Exchange Act), Item 1 of § 240.14c-101 of this chapter (Rule 14c-101 under the Exchange Act), General Instruction C.3.(g) of §§ 239.15A and 274.11A of this chapter (Form N-1A), General Instruction I of §§ 239.14 and 274.11a-1 of this chapter (Form N-2), General Instruction C.3.(h) of §§ 239.17a and 274.11b of this chapter (Form N-3), General Instruction C.3.(h) of §§ 239.17b and 274.11c of this chapter (Form N-4), General Instruction C.3.(h) of §§ 239.17c and 274.11d of this chapter (Form N-6); General Instruction C.4 of §§ 249.331 and 274.128 of this chapter (Form N-CSR); General Instruction A of § 249.1 of this chapter (Form 1); or General Instruction A of § 249b.200 of this chapter (Form CA-1).
(b) * * *
(1) If the electronic filer is not a management investment company registered under 15 U.S.C. 80a
(5) If an electronic filer is an entity subject to §§ 240.15fk-1, 240.17a-5, 240.17a-12, 240.17h-2T, or 240.18a-7 of this chapter (Rule 15fk-1, 17a-5, 17a-12, 17h-2T, or 18a-7 under the Exchange Act), an exchange as defined in 15 U.S.C. 78c(a)(1) (Section 3(a)(1) of the Exchange Act), or a clearing agency as defined in 15 U.S.C. 78c(a)(23)(A) (Section 3(a)(23)(A) of the Exchange Act), an Interactive Data File must consist of only a complete set of information for all periods required to be presented in the corresponding data in the Related Official Filing, no more and no less, from all of the following categories, as applicable:
(i) For electronic filers of § 249.517 of this chapter (Part III of Form X-17A-5): the disclosures required by Items (a) through (y) of that Form.
(ii) The disclosure provided pursuant to Item 4 of § 249.328T of this chapter (Form 17-H).
(iii) The report provided pursuant to § 240.15fk-1(c)(2)(ii)(A) of this chapter (Rule 15fk-1(c)(2)(ii)(A) under the Exchange Act).
(iv) The exhibits specified by General Instruction A to § 249.1 of this chapter (Form 1).
(v) The disclosure provided pursuant to Schedule A and Exhibits C, F, H, J, K, L, M, O, R, and S to § 249b.200 of this chapter (Form CA-1).
(vi) The information provided pursuant to § 240.17ad-27 of this chapter (Rule 17ad-27 under the Exchange Act).
Section 229.601(b)(101) of this chapter (Item 601(b)(101) of Regulation S-K) specifies the circumstances under which an Interactive Data File must be submitted and the circumstances under which it is permitted to be submitted, with respect to § 239.11 of this chapter (Form S-1), § 239.13 of this chapter (Form S-3), § 239.25 of this chapter (Form S-4), § 239.18 of this chapter (Form S-11), § 239.31 of this chapter (Form F-1), § 239.33 of this chapter (Form F-3), § 239.34 of this chapter (Form F-4), § 249.310 of this chapter (Form 10-K), § 249.308a of this chapter (Form 10-Q), and § 249.308 of this chapter (Form 8-K). General Instruction F of § 249.311 of this chapter (Form 11-K) specifies the circumstances under which an Interactive Data File must be submitted, and the circumstances under which it is permitted to be submitted, with respect to Form 11-K. Paragraph (101) of Part II—Information not Required to be Delivered to Offerees or Purchasers of § 239.40 of this chapter (Form F-10) specifies the circumstances under which an Interactive Data File must be submitted and the circumstances under which it is permitted to be submitted, with respect to Form F-10. Paragraph 101 of the Instructions as to Exhibits of § 249.220f of this chapter (Form 20-F) specifies the circumstances under which an Interactive Data File must be submitted and the circumstances under which it is permitted to be submitted, with respect to Form 20-F. Paragraph B.(15) of the General Instructions to § 249.240f of this chapter (Form 40-F) and Paragraph C.(6) of the General Instructions to § 249.306 of this chapter (Form 6-K) specify the circumstances under which an Interactive Data File must be submitted and the circumstances under which it is permitted to be submitted, with respect to § 249.240f of this chapter (Form 40-F) and § 249.306 of this chapter (Form 6-K). Note D.5 of § 240.14a-101 of this chapter (Schedule 14A) and Item 1 of § 240.14c-101 of this chapter (Schedule 14C) specify the circumstances under which an Interactive Data File must be submitted with respect to Schedules 14A and 14C. Section 229.601(b)(101) (Item 601(b)(101) of Regulation S-K), paragraph (101) of Part II—Information not Required to be Delivered to Offerees or Purchasers of Form F-10, paragraph 101 of the Instructions as to Exhibits of Form 20-F, paragraph B.(15) of the General Instructions to Form 40-F, and paragraph C.(6) of the General Instructions to Form 6-K all prohibit submission of an Interactive Data File by an issuer that prepares its financial statements in accordance with 17 CFR 210.6-01 through 210.6-10 (Article 6 of Regulation S-X). For an issuer that is a management investment company or separate account registered under the Investment Company Act of 1940 (15 U.S.C. 80a
15 U.S.C. 77c, 77d, 77g, 77j, 77s, 77z-2, 77z-3, 77eee, 77ggg, 77nnn, 77sss, 77ttt, 78c, 78c-3, 78c-5, 78d, 78e, 78f, 78g, 78i, 78j, 78j-1, 78j-4, 78k, 78k-1, 78
Sections 240.3a71-3 and 240.3a71-5 are also issued under Public Law 111-203, sec. 761(b), 124 Stat. 1754 (2010), and 15 U.S.C. 78dd(c).
Sections 240.15Fh-1 through 240.15Fh-6 and 240.15fk-1 are also issued under sec. 943, Public Law 111-203, 124 Stat. 1376.
Section 240.19b-4 is also issued under 12 U.S.C. 5465(e).
(d) * * *
(1) * * *
(vi)
(e) Filings on Form 1 (§ 249.1 of this chapter) submitted pursuant to this chapter shall be filed electronically on EDGAR in accordance with the requirements of 17 CFR part 232 (Regulation S-T). Except as otherwise specified on Form 1, the disclosure required to be included in Exhibits D, E, and I must be provided as an Interactive Data File in accordance with 17 CFR 232.405 (Rule 405 of Regulation S-T).
The revisions read as follows:
(a) A national securities exchange, or an exchange exempted from such registration based on limited volume, shall electronically file an amendment to Form 1 (§ 249.1 of this chapter), in accordance with § 240.6a-1(e) of this chapter, which shall set forth the nature and effective date of the action taken and shall provide any new information and correct any information rendered inaccurate, on Form 1 (§ 249.1 of this chapter), within 10 days after any action is taken that renders inaccurate, or that causes to be incomplete, any of the following:
(1) Information filed on Sections I and II of Form 1, or amendment thereto; or
(b) On or before June 30 of each year, a national securities exchange, or an exchange exempted from such registration based on limited volume, shall electronically file, as an amendment to Form 1, in accordance with § 240.6a-1(e) of this chapter, the following:
(c) On or before June 30, 2025, and every three years thereafter, a national securities exchange, or an exchange exempted from such registration based on limited volume, shall electronically file, as an amendment to Form 1, in accordance with § 240.6a-1(e) of this chapter, complete Exhibits A, B, C and J. * * *
(d)(1) If an exchange, on an annual or more frequent basis, publishes, or cooperates in the publication of, any of the information required to be filed by paragraphs (b)(2) and (c) of this section, in lieu of filing such information, an exchange may:
(i) Identify on Form 1 the publication in which such information is available, the name, address, and telephone number of the person from whom such publication may be obtained, and the price of such publication; and
(ii) Certify on Form 1 to the accuracy of such information as of its publication date.
(2) If an exchange keeps the information required under paragraphs (b)(2) and (c) of this section up to date and makes it available to the Commission and the public upon request, in lieu of filing such information, an exchange may certify on Form 1 that the information is kept up to date and is available to the Commission and the public upon request.
(3) If the information required to be filed under paragraphs (b)(2) and (c) of this section is available continuously on an internet website controlled by an exchange, in lieu of filing such information with the Commission, such exchange may:
(i) Provide on Form 1 the Uniform Resource Locator(s) (URL(s)) of the location(s) on the internet website where such information may be found; and
(ii) Certify on Form 1 that the information available at such location(s) is accurate as of its date and is free and accessible (without any encumbrances or restrictions) by the general public.
The revisions read as follows:
(a)(1) * * * Such material shall be electronically filed with the Commission on Form 1 (§ 249.1 of this chapter), in accordance with § 240.6a-1(e) of this chapter, within 10 days after issuing or making such material available to members, participants or subscribers.
(2) If the information required to be filed under paragraph (a)(1) of this section is available continuously on an internet website controlled by an exchange, in lieu of filing such information with the Commission, such exchange may:
(i) Provide on Form 1 the Uniform Resource Locator(s) (URL(s)) of the location(s) on the internet website where such information may be found; and
(ii) Certify on Form 1 that the information available at such location(s) is accurate as of its date and is free and accessible (without any encumbrances or restrictions) by the general public.
(b) Within 15 days after the end of each calendar month, a national securities exchange or an exchange exempted from such registration based on limited volume, shall electronically file on Form 1 (§ 249.1 of this chapter), in accordance with § 240.6a-1(e) of this chapter, a report concerning the securities sold on such exchange during the calendar month. * * *
The revisions and addition read as follows:
(a) * * *
(1) * * *
(i) The exchange is a board of trade, as that term is defined in the Commodity Exchange Act (7 U.S.C. 1a(6)), that:
(B) Is registered as a derivative transaction execution facility under Section 6(a) of the Commodity Exchange Act (7 U.S.C. 8(a)) and such registration
(ii) * * *
(B) Futures on exempted securities or on groups or indexes of securities or options thereon that have been authorized under Section 2(a)(1)(C) of the Commodity Exchange Act (7 U.S.C. 2(a)(1)(C)).
(b) * * *
(1) * * *
(i) Ten days after any action is taken that renders inaccurate, or that causes to be incomplete, any information filed on Sections I through III of Form 1-N (§ 249.10 of this chapter), or amendment thereto; or
(3) On or before June 30, 2023, and by June 30 every year thereafter, a Security Futures Product Exchange shall file, as an amendment to Form 1-N (§ 249.10 of this chapter), Exhibits F, H, and I, which shall be current as of the latest practicable date, but shall, at a minimum, be up to date within three months as of the date the amendment is filed.
(4) On or before June 30, 2025, and by June 30 every three years thereafter, a Security Futures Product Exchange shall file, as an amendment to Form 1-N (§ 249.10 of this chapter), complete Exhibits A, B, C, and E, which shall be current as of the latest practicable date, but shall, at a minimum, be up to date within three months as of the date the amendment is filed.
(5)(i) If a Security Futures Product Exchange, on an annual or more frequent basis, publishes, or cooperates in the publication of, any of the information required to be filed by paragraphs (b)(3) and (b)(4) of this section, in lieu of filing such information, a Security Futures Product Exchange may:
(A) Identify on Form 1-N the publication in which such information is available, the name, address, and telephone number of the person from whom such publication may be obtained, and the price of such publication; and
(B) Certify on Form 1-N to the accuracy of such information as of its publication date.
(ii) If a Security Futures Product Exchange keeps the information required under paragraphs (b)(3) and (b)(4) of this section up to date and makes it available to the Commission and the public upon request, in lieu of filing such information, a Security Futures Product Exchange may certify on Form 1-N that the information is kept up to date and is available to the Commission and the public upon request.
(iii) If the information required to be filed under paragraphs (b)(3) and (b)(4) of this section is available continuously on an internet website controlled by a Security Futures Product Exchange, in lieu of filing such information with the Commission, such Security Futures Product Exchange may:
(A) Provide on Form 1-N the Uniform Resource Locator(s) (URL(s)) of the location(s) of the internet website where such information may be found; and
(B) Certify on Form 1-N that the information available at such location(s) is accurate as of its date and is free and accessible (without any encumbrances or restrictions) by the general public.
(c) * * *
(1) * * *
(ii) * * *
(A) Provide on Form 1-N the Uniform Resource Locator(s) (URL(s)) of the location(s) of the internet website where such information may be found; and
(B) Certify on Form 1-N that the information available at such location(s) is accurate as of its date and is free and accessible (without any encumbrances or restrictions) by the general public.
(2) * * * Such a report shall state:
(d) Filings on Form 1-N (§ 249.10 of this chapter) submitted pursuant to this section shall be filed electronically on EDGAR in accordance with the requirements of 17 CFR part 232 (Regulation S-T).
Any application for registration of an association as a national, or as an affiliated, securities association shall be submitted on Form 15A. Filings on Form 15A (§ 249.801 of this chapter) submitted pursuant to this section shall be filed electronically on EDGAR in accordance with the requirements of 17 CFR part 232 (Regulation S-T).
The revisions read as follows:
(b) * * *
(1) No current supplements need be filed with respect to changes in the information called for in Exhibit B.
(2) Supplements setting forth changes in the information called for in Exhibit C need not be filed until 10 days after the calendar month in which the changes occur.
(3) If changes in the information called for in items (1) and (2) of Exhibit C are reported in any record which is published at least once a month by the association and promptly filed with the Commission, no current supplement need be filed with respect thereto.
(c) * * *
(1) Promptly after March 1 of each year, the association shall file with the Commission an annual consolidated supplement as of such date on Form 15A (§ 249.801) except that:
(i) If the securities association publishes or cooperates in the publication of the information required in Items 6(a) and 6(b) of Form 15A on an annual or more frequent basis, in lieu of filing such an item the securities association may:
(A) Identify on Form 15A the publication in which such information is available, the name, address, and telephone number of the person from whom such publication may be obtained, and the price thereof; and
(B) Certify on Form 15A to the accuracy of such information as of its date.
(ii) Promptly after March 1, 2025, and every three years thereafter each association shall file complete Exhibit A to Form 15A. The information contained in this exhibit shall be up to date as of the latest practicable date within 3 months of the date on which these exhibits are filed. If the association publishes or cooperates in the publication of the information required in this exhibit on an annual or more frequent basis, in lieu of filing such exhibit the association may:
(A) Identify on Form 15A the publication in which such information is available, the name, address, and telephone number of the person from whom such publication may be obtained, and the price thereof; and
(B) Certify on Form 15A to the accuracy of such information as of its date. If a securities association keeps the information required in the exhibit up to date and makes it available to the Commission and the public upon request, in lieu of filing such an exhibit a securities association may certify on Form 15A that the information is kept up to date and is available to the
(d)
(2) One amendment or supplement may include any number of changes. In addition to the formal filing of amendments and supplements above described, each association shall electronically file with the Commission copies of any notices, reports, circulars, loose-leaf insertions, riders, new additions, lists or other records of changes covered by amendments or supplements when, as and if such records are made available to members of the association.
The revision reads as follows:
(c)
(i) Three business days, if the dispute is with a counterparty that is a security-based swap dealer or major security-based swap participant; or
(ii) Five business days, if the dispute is with a counterparty that is not a security-based swap dealer or major security-based swap participant.
(2)
The revision reads as follows:
(c) * * *
(2) * * *
(ii) * * *
(A) Be submitted to the Commission electronically through the EDGAR system as an Interactive Data File in accordance with 17 CFR 232.405 (Rule 405 of Regulation S-T) within 30 days following the deadline for filing the security-based swap dealer's or major security-based swap participant's annual financial report with the Commission pursuant to section 15F of the Act and rules and regulations thereunder;
The revisions and additions read as follows:
(a) * * *
(2) * * * All reports filed pursuant to this paragraph (a) will be deemed confidential for the purposes of section 24(b) of the Act.
(d) * * *
(6)(i)
(ii)
(e) * * *
(2) * * *
(iii) The broker or dealer must keep the original notarized oath or affirmation for a period of not less than six years, the first two years in an easily accessible place and in accordance with the requirements of § 240.17a-4 of this chapter (Rule 17a-4) under the Exchange Act.
(3) The annual reports filed under paragraph (d) of this section may be filed as:
(i) One public document; or
(ii) Two documents:
(A) A document consisting of the Statement of Financial Condition, the notes to the Statement of Financial Condition, and the report of the independent public accountant covering the Statement of Financial Condition, which is not confidential; and
(B) A document containing the balance of the annual reports for which confidential treatment may be requested and which will be deemed confidential for the purposes of section 24(b) of the Act. However, the annual reports, including the confidential portions, will be available for official use by any official or employee of the U.S. or any State, by national securities exchanges and registered national securities associations of which the broker or dealer filing such a report is a member, by the Public Company Accounting Oversight Board, and by any other person if the Commission authorizes disclosure of the annual reports to that
(f) * * *
(3) * * *
(v) * * *
(B) * * * The broker or dealer must file three copies of the notice and the accountant's letter, one copy of which must be signed by the sole proprietor, a general partner, or a duly authorized corporate, limited liability company, or limited liability partnership officer or member, as appropriate, and by the independent public accountant, respectively.
(i) * * *
(1) * * *
(ii) Be signed;
(k)
(i) A description of the agreed-upon procedures agreed to by the broker or dealer and the registered public accounting firm; and
(ii) A notice describing changes in those agreed-upon procedures, if any. If there are no changes, the broker or dealer should so indicate.
(2) The supplemental report and statement to be filed under paragraph (k)(1) of this section must be filed with the Commission electronically on EDGAR in the manner described by the EDGAR Filer Manual, as defined in 17 CFR 232.11 (Rule 11 of Regulation S-T), and must be filed in accordance with the requirements of 17 CFR part 232 (Regulation S-T). The supplemental report and statement must be provided as an Interactive Data File in accordance with 17 CFR 232.405 (Rule 405 of Regulation S-T).
(p)
(1) Require the signatory to present a physical, logical, or digital credential that authenticates the signatory's individual identity;
(2) Reasonably provide for non-repudiation of the signature;
(3) Provide that the signature be attached, affixed, or otherwise logically associated with the signature page or document being signed; and
(4) Include a timestamp to record the date and time of the signature.
The revisions and additions read as follows:
(a) * * *
(2) The reports provided for in this paragraph (a) must be filed with the Commission electronically on the SEC eFOCUS system. All reports filed pursuant to paragraph (a) of this section shall be deemed to be confidential for the purposes of section 24(b) of the Act.
(b) * * *
(6) The annual audit report shall be filed with the Commission electronically on EDGAR in the manner described by the EDGAR Filer Manual, as defined in 17 CFR 232.11 (Rule 11 of Regulation S-T), and must be filed in accordance with the requirements of 17 CFR part 232 (Regulation S-T). The annual audit report must be provided as an Interactive Data File in accordance with 17 CFR 232.405 (Rule 405 of Regulation S-T).
(c) * * *
(3) The OTC derivatives dealer must keep the original notarized oath or affirmation for a period of not less than six years, the first two years in an easily accessible place and in accordance with the requirements of § 240.17a-4 of this chapter (Rule 17a-4 under the Exchange Act).
(4) An OTC derivatives dealer may request confidential treatment for all of the statements filed pursuant to paragraph (b) of this rule and such statements will be deemed confidential for the purposes of section 24(b) of the Act. However, such statements shall be available for use by any official or employee of the United States or by any other person if the Commission authorizes disclosure of such information to that person.
(g) * * *
(2) * * * The OTC derivatives dealer shall file three copies of the notice and the accountant's letter, one copy of which shall be signed by the sole proprietor, a general partner, or a duly authorized corporate, limited liability company, or limited liability partnership officer or member, as appropriate, and by the independent public accountant, respectively.
(j) * * *
(1)
(k)
(l) * * *
(1) The OTC derivatives dealer shall file concurrently with the annual audit report a supplemental report by the certified public accountant indicating the results of the certified public accountant's review of the OTC derivatives dealer's internal risk management control system with respect to the requirements of § 240.15c3-4. This review shall be conducted in accordance with procedures agreed to by the OTC derivatives dealer and the certified public accountant conducting the review. The purpose of the review is to confirm that the OTC derivatives dealer has established, documented, and maintained an internal risk management control system in accordance with § 240.15c3-4, and is in compliance with that internal risk management control system. This supplemental report shall be filed with the Commission electronically on EDGAR in the manner described by the EDGAR Filer Manual, as defined in 17 CFR 232.11 (Rule 11 of Regulation S-T), and must be filed in accordance with the requirements of 17 CFR part 232 (Regulation S-T). This supplemental report must be provided as an Interactive Data File in accordance with 17 CFR 232.405 (Rule 405 of Regulation S-T).
(m) * * *
(1) The OTC derivatives dealer shall file concurrently with the annual audit report a supplemental report by the certified public accountant indicating the results of the certified public accountant's review of the broker's or dealer's inventory pricing and modeling procedures. This review shall be conducted in accordance with procedures agreed to by the OTC derivatives dealer and by the certified public accountant conducting the review. The purpose of the review is to confirm that the pricing and modeling procedures relied upon by the OTC derivatives dealer conform to the procedures submitted to the Commission as part of its OTC derivatives dealer application, and that the procedures comply with the qualitative and quantitative standards set forth in § 240.15c3-1f. This supplemental report shall be filed with the Commission electronically on EDGAR in the manner described by the EDGAR Filer Manual, as defined in 17 CFR 232.11 (Rule 11 of Regulation S-T), and must be filed in accordance with the requirements of 17 CFR part 232 (Regulation S-T). This supplemental report must be provided as an Interactive Data File in accordance with 17 CFR 232.405 (Rule 405 of Regulation S-T).
(p) Unless otherwise stated in this rule, for purposes of filing requirements as described in § 240.17a-12, these filings shall be deemed to have been accomplished upon receipt at the Commission's principal office in Washington, DC.
(q) Any signature required by this section may be a manual or electronic signature. The signing process for an electronic signature must, at a minimum:
(1) Require the signatory to present a physical, logical, or digital credential that authenticates the signatory's individual identity;
(2) Reasonably provide for non-repudiation of the signature;
(3) Provide that the signature be attached, affixed, or otherwise logically associated with the signature page or document being signed; and
(4) Include a timestamp to record the date and time of the signature.
Every national securities exchange and every registered national securities association must file with the Commission and with the Securities Investor Protection Corporation such information as is required by § 249.635 of this chapter on Form X-17A-19 within five business days of the occurrence of the initiation of the membership of any person or the suspension or termination of the membership of any member. Form X-17A-19 must be filed with the Commission electronically on EDGAR in accordance with the EDGAR Filer Manual, as defined in 17 CFR 232.11 (Rule 11 of Regulation S-T), and must be filed in accordance with the requirements of Regulation S-T. Nothing in this section shall be deemed to relieve a national securities exchange or a registered national securities association of its responsibilities under § 240.17a-5(b)(5) except that, to the extent a national securities exchange or a registered national securities association promptly files a report on Form X-17A-19 including therewith, inter alia, information sufficient to satisfy the requirements of § 240.17a-5(b)(5), it shall not be required to file a report pursuant to § 240.17a-5(b). Upon the occurrence of the events described in this paragraph, every national securities exchange and every registered national securities association shall notify in writing such member of its responsibilities under § 240.17a-5(b).
Within two business days after issuing, or making generally available, to its participants or to other entities with whom it has a significant relationship, any material (including, for example, manuals, notices, circulars, bulletins, lists or periodicals) that are not otherwise required to be posted on its internet website pursuant to any requirement under Section 19(b) of the Exchange Act or any rule under § 240.19b-4, a registered clearing agency shall prominently post such material on its internet website.
(a)
(1) Every broker or dealer registered with the Commission pursuant to section 15 of the Act, and every municipal securities dealer registered pursuant to section 15B of the Act for which the Commission is the appropriate regulatory agency, unless exempt pursuant to paragraph (b) of this section, shall file a Form 17-H within 60 calendar days after the end of each fiscal quarter. The Form 17-H for the fourth fiscal quarter shall be filed within 60 calendar days of the end of the fiscal year. The cumulative year-end financial statements required by section 240.17h-1T may be filed separately within 105 calendar days of the end of the fiscal year.
(2) The reports required to be filed pursuant to paragraph (a)(1) of this section must be filed with the Commission electronically on EDGAR in accordance with the EDGAR Filer Manual, as defined in 17 CFR 232.11
(3) For purposes of this section, the term Material Associated Person shall have the meaning used in § 240.17h-1T.
The revisions and addition read as follows:
(a) An application for registration or for exemption from registration as a clearing agency, as defined in section 3(a)(23) of the Act, or an amendment to any such application shall be filed electronically with the Commission on Form CA-1, in accordance with the instructions thereto and paragraph (g) below.
(d) The electronic filing of an amendment to an application for registration or for exemption from registration as a clearing agency, which registration or exemption has not been granted, or the electronic filing of additional information or documents prior to the granting of registration or an exemption from registration shall extend to ninety days from the date such electronic filing is made (or to such longer period as to which the applicant consents) the period within which the Commission shall grant registration, institute proceedings to determine whether such registration shall be denied, or conditionally or unconditionally exempt registrant from the registration and other provisions of section 17A of the Act or the rules or regulations thereunder.
(e) If any information reported at items 1-3 of Form CA-1 is or becomes inaccurate, misleading or incomplete for any reason, whether before or after registration or an exemption from registration has been granted, the registrant shall electronically file promptly an amendment on Form CA-1 correcting the inaccurate, misleading or incomplete information.
(f) Every application for registration or for exemption from registration as a clearing agency or amendment to, or additional information or document electronically filed in connection with, any such application shall constitute a “report” or “application” within the meaning of sections 17, 17A, 19, and 32(a) of the Act.
(g)(1) Filings on Form CA-1 made pursuant to this section shall be made electronically and shall contain an electronic signature.
(2) For the purposes of this section, the term
(3) If the conditions of this section and Form CA-1 are otherwise satisfied, all filings submitted electronically on or before 5:30 p.m. eastern standard time or eastern daylight saving time, whichever is currently in effect, on a business day, shall be deemed filed on that business day, and all filings submitted after 5:30 p.m. eastern standard time or eastern daylight saving time, whichever is currently in effect, shall be deemed filed on the next business day. A filing would be deemed timely filed if it is required to be filed on a day that is not a business day and it is filed on the next available business day.
(4) For purposes of this section, the term
(c) * * *
(6)
(d) * * *
(1)(i)
(A) The financial report is true and correct; and
(B) Neither the registrant, nor any partner, officer, director, or equivalent person, as the case may be, has any proprietary interest in any account classified solely as that of a customer.
(ii) The oath or affirmation must be made before a person duly authorized to administer such oaths or affirmations. If the security-based swap dealer or major security-based swap participant is a sole proprietorship, the oath or affirmation must be made by the proprietor; if a partnership, by a general partner; if a corporation, by a duly authorized officer; or if a limited liability company or limited liability partnership, by the chief executive officer, chief financial officer, manager, managing member, or those members vested with management authority for the limited liability company or limited liability partnership.
(iii) The security-based swap dealer or major security-based swap participant must keep the original notarized oath or affirmation for a period of not less than six years, the first two years in an easily accessible place in accordance with the requirements of § 240.18a-6 of this chapter (Rule 18a-6 under the Exchange Act).
(2)
(i) One public document; or
(ii) Two documents:
(A) A document consisting of the Statement of Financial Condition, the notes to the Statement of Financial Condition, and the report of the independent public accountant covering the Statement of Financial Condition, which is not confidential; and
(B) A document containing the balance of the annual reports for which confidential treatment may be requested and which will be deemed confidential for the purposes of section 24(b) of the Act. However, the annual reports, including the confidential portions, will be available for official use by any official or employee of the U.S. or any State, and by any other person if the Commission authorizes disclosure of the annual reports to that person. Nothing contained in paragraph (d)(2) of this section may be construed to be in derogation of the rights of customers of a security-based-swap dealer or major security-based swap participant, upon
(e) * * *
(3) * * *
(v) * * *
(B) * * * The security-based swap dealer or major security-based swap participant must file three copies of the notice and the accountant's letter, one copy of which must be signed by the sole proprietor, or a general partner or a duly authorized corporate, limited liability company, or limited liability partnership officer or member, as appropriate, and by the independent public accountant, respectively.
(h) * * *
(1) * * *
(ii) Be signed;
(j)
(1) Require the signatory to present a physical, logical, or digital credential that authenticates the signatory's individual identity;
(2) Reasonably provide for non-repudiation of the signature;
(3) Provide that the signature be attached, affixed, or otherwise logically associated with the signature page or document being signed; and
(4) Include a timestamp to record the date and time of the signature.
(e) * * *
(2) * * *
(ii) When relying on paragraph (e) of this section, a self-regulatory organization shall post the following information, using the most recent versions of the XML schema and the associated PDF renderer as published on the Commission's website for all reports required by this section, on its publicly available internet website within five business days after commencement of trading a new derivative securities product:
(A) Type of issuer of new derivatives securities product;
(B) Class of new derivative securities product;
(C) Name of underlying instrument;
(D) If the underlying instrument is an index, identify whether it is broad-based or narrow-based;
(E) Ticker symbol(s) of new derivative securities product;
(F) Market(s) upon which securities comprising the underlying instrument trades;
(G) Settlement methodology of new derivative securities product; and
(H) Position limits of new derivative securities product (if applicable).
(j) Filings by a self-regulatory organization submitted under 17 CFR 249.819 on Form 19b-4 electronically shall contain an electronic signature. For the purposes of this section, the term
The revisions and additions read as follows:
(j)(1) A broker or dealer shall not omit the confidential portion from the material filed in electronic format pursuant to §§ 240.17a-5(d), 240.17a-5(k), 240.17a-12, or 240.17h-2T of this chapter. In lieu of the procedures described in paragraph (b) of this section, a broker or dealer shall request confidential treatment electronically for any material filed in electronic format pursuant to pursuant to §§ 240.17a-5(d), 240.17a-5(k), 240.17a-12, or 240.17h-2T, of this chapter.
(2) A security-based swap dealer shall not omit the confidential portion from the material filed in electronic format pursuant to § 240.18a-7(c) of this chapter. In lieu of the procedures described in paragraph (b) of this section, a security-based swap dealer shall request confidential treatment electronically for any material filed in electronic format pursuant to § 240.18a-7(c) of this chapter.
(k) An entity shall not omit the confidential portion from the material filed in electronic format on Form CA-1 pursuant to § 240.17ab2-1, and, in lieu of the procedures described in paragraph (b) of this section, may request confidential treatment of information provided on Form CA-1 by completing Section X of Form CA-1.
15 U.S.C. 78a
Section 249.617 is also issued under Public Law 111-203, 939, 939A, 124. Stat. 1376 (2010) (15 U.S.C. 78c, 15 U.S.C. 78
Section 249.819 is also issued under 12 U.S.C. 5465(e).
Form 1 is attached as Appendix 1 to this document. Form 1 will not appear in the Code of Federal Regulations.
Form 1-N is attached as Appendix 2 to this document. Form 1-N will not appear in the Code of Federal Regulations.
3870
• 2% of aggregate debit items, or
• 8% of funds required to be segregated pursuant to the Commodity Exchange Act.
Form 15A is attached as Appendix 6 to this document. Form 15A will not appear in the Code of Federal Regulations.
The revisions read as shown in Appendix 7.
15 U.S.C. 78a
Form CA-1 is attached as Appendix 9 to this document. Form CA-1 will not appear in the Code of Federal Regulations.
By the Commission.
The text of Form 1 does not, and this amendment will not, appear in the Code of Federal Regulations.
Provide the following information of the person at {entity name} prepared to respond to questions for this submission:
☐ By checking this box, {Name of Entity} consents that service of any civil action brought by, or notice of any proceeding before, the Securities and Exchange Commission in connection with the exchange's activities may be given to the contact employee by registered or certified mail at the main address, or mailing address if different, given in Section I above; and represents that the information and statements contained herein, including exhibits, schedules, or other documents attached hereto, and other information filed herewith, all of which are made a part hereof, are current, true, and complete.
Form 1 is the form used by: (a) an applicant for registration as a national securities exchange under Section 6 of the Securities Exchange Act of 1934 (“Exchange Act”) or for an exemption from registration pursuant to Section 5 of the Exchange Act by reason of the limited volume of transactions effected on such exchange (“applicant”) to provide to the Securities and Exchange Commission (“SEC” or “Commission”) specific items of information about the applicant and its operations, or to amend such application, as required under Rule 6a-1; and (b) a national securities exchange (“registered exchange”) or an exchange exempted from such registration by reason of the limited volume of transactions effected on such exchange (“exempt exchange”) uses to provide the information required by Rule 6a-2 and Rule 6a-3.
Filings on Form 1 submitted pursuant to Rule 6a-1, Rule 6a-2 or Rule 6a-3 of the Exchange Act shall be filed in an electronic format on the Commission's Electronic Data Gathering, Analysis, and Retrieval system (EDGAR) in accordance with EDGAR rules set forth in Regulation S-T (17 CFR part 232). All pages of an electronically filed Form 1, including exhibits, shall be numbered consecutively, consistent with Rule 0-3 under the Exchange Act (17 CFR 240.0-3). For assistance with EDGAR issues, please consult the EDGAR—Information for Filers web page on
The disclosure required to be included in the following exhibits to Form 1 must be provided as an Interactive Data File in accordance with Rule 405 of Regulation S-T. This requirement does not extend to copies of existing documents:
(1) Exhibit D;
(2) Exhibit E, except for the copy of the users' manual; and
(3) Exhibit I.
Applicants and registered and exempt exchanges must provide all the information required by the form, including the exhibits, and must present the information in a clear and comprehensible manner. A filing that is incomplete or similarly deficient may be returned to the applicant or registered or exempt exchange. Any filing so returned shall for all purposes be deemed not to have been filed with the Commission.
Form 1 is composed of 6 types of submissions to the Commission pursuant to Rules 6a-1, 6a-2 and 6a-3 under the Exchange Act. In completing Form 1, an applicant or exchange shall select the type of filing and provide all information required by the relevant rules. The types of submissions are:
(1) “Rule 6a-1 Application” submissions are applications for registration as a national securities exchange or for exemption from such registration based on limited volume. The applicant must select the type of application during the initial filing. An exchange that is filing Form 1 as an application may not satisfy the requirements to provide certain information by means of an internet website. All materials must be filed with the Commission as part of the Form 1 application. Amendments to applications as required by Rules 6a-1(b), (c) or (d) must be filed as amending the Rule 6a-1 application type, and marked to number the amendments consecutively. An applicant may withdraw a Rule 6a-1 application submission type prior to Commission action to issue any order granting registration, or institute proceedings to determine whether registration should be denied.
(2) “Rule 6a-2(a) Amendment to Registration” submissions are for amendments to the Form 1 by registered exchanges and exempt exchanges. The amendments shall set forth the nature and effective date of the action taken and shall provide any new information and correct any information rendered inaccurate within 10 days after any action that is taken renders inaccurate, or that causes to be incomplete, any of the following:
(i) Information in Section I-Entity Contact Information, or any amendments thereto; or
(ii) Information filed as part of Exhibits C, F, G, H, J, K or M, or any amendments thereto.
(3) “Rule 6a-2(b) Annual Filing” submission shall be filed on or before June 30 of each year and include the following:
(i) Exhibits D and I as of the end of the latest fiscal year of the exchange; and
(ii) Exhibits K, M, and N, which shall be up to date as of the latest date practicable within three (3) months of the date the amendment is filed.
(4) “Rule 6a-2(c) Triennial Filing” submission shall be filed on or before June 30, 2025, and every three years thereafter and shall include complete Exhibits A, B, C and J. The information filed under this submission type shall, at a minimum, be up to date within three (3) months as of the date the amendment is filed.
(5) “Rule 6a-3(a) Supplemental Material” submission shall be filed with the Commission within 10 days after issuing or making any materials (including notices, circulars, bulletins, lists and periodicals) issued or made generally available to members of, or participants or subscribers to, the exchange.
(6) “Rule 6a-3(b) Report of securities sold” submission type shall be filed within 15 days after the end of each calendar month and shall include a report concerning the securities sold on such exchange during the calendar month. The report shall set forth:
(i) The number of shares of stock sold and the aggregate dollar amount of such stock sold;
(ii) The principal amount of bonds sold and the aggregate dollar amount of such bonds sold; and
(iii) The number of rights and warrants sold and the aggregate dollar amount of such rights and warrants sold.
The completed form filed with the Commission shall consist of Form 1, responses to all applicable items, and any exhibits required in connection with the filing.
Each time an applicant or exchange submits a filing to the Commission on Form 1, the applicant or exchange must provide the contact information required by Section II of Form 1. The contact employee must be authorized to receive all contact information, communications and mailings and must be responsible for disseminating that information within the applicant or exchange's organization.
For assistance with EDGAR issues, please consult the EDGAR—Information for Filers web page on
A copy of this Form 1 must be retained by the exchange and made available for inspection upon request of the SEC.
Form 1 requires an applicant seeking to register as a national securities exchange or seeking an exemption from registration as a national securities exchange pursuant to Section 5 of the Exchange Act to provide the SEC with certain information regarding the operation of the exchange. Form 1 also requires national securities exchanges or exchanges exempt from registration based on limited volume to update certain information on a periodic basis and to provide supplemental material as required.
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 control number. Sections 3(a)(1), 5, 6(a) and 23(a) authorize the Commission to collect information on this Form 1 from exchanges. See 15 U.S.C. 78c(a)(1), 78e, 78f(a) and 78w(a).
Any member of the public may direct to the Commission any comments concerning the accuracy of the burden estimate on the facing page of Form 1 and any suggestions for reducing this burden.
Form 1 is designed to enable the Commission to determine whether an exchange applying for registration is in compliance with the provisions of Sections 6 and 19 of the Exchange Act. Form 1 is also designed to enable the Commission to determine whether a national securities exchange or exchange exempt from registration based on limited volume is operating in compliance with the Exchange Act.
It is estimated that an exchange will spend approximately 891 hours completing the initial application on Form 1 pursuant to Rule 6a-1. It is also estimated that each exchange will spend approximately 26 hours to prepare each amendment to Form 1 pursuant to Rule 6a-2. It is also estimated that each exchange will spend approximately 0.5 hours to prepare each submission pursuant to Rule 6a-3.
It is mandatory that an exchange seeking to operate as a national securities exchange or as an exchange exempt from registration based on limited volume file Form 1 with the Commission. It is also mandatory that national securities exchanges or exchanges exempt from registration based on limited volume file amendments to Form 1 under Rule 6a-2. It is further mandatory that national securities exchanges or exchanges exempt from registration based on limited volume file supplemental information and monthly reports under Rule 6a-3.
No assurance of confidentiality is given by the Commission with respect to the responses made in Form 1. The public has access to the information contained in Form 1.
This collection of information has been reviewed by the Office of Management and Budget (“OMB”) in accordance with the clearance requirements of 44 U.S.C. 3507. The Commission has determined that the information collection does not constitute a system of record for purposes of the Privacy Act.
The text of Form 1-N does not, and this amendment will not, appear in the Code of Federal Regulations.
The individual listed herein as the Contact Employee for {name of exchange} must be authorized to receive all contact information, communications, and mailings and is responsible for disseminating such information within the Security Futures Product Exchange's organization.
☐ By checking this box, {Name of Entity} consents that service of any civil action brought by, or notice of any proceeding before, the Securities and Exchange Commission in connection with the exchange's activities may be given by registered or certified mail to the contact employee at the main address, or mailing address if different, given in Section I above; and represents that the information and statements contained herein, including exhibits, schedules, or other documents attached hereto, and other information filed herewith, all of which are made a part hereof, are current, true, and complete.
Form 1-N is the form used for: (a) notice of registration as a national securities exchange for the sole purpose of trading security futures products (“Security Futures Product Exchange”) under Section 6(g) of the Securities Exchange Act of 1934 (“Exchange Act”) to provide to the Securities and Exchange Commission (“SEC” or “Commission”) specific items of information about the Security Futures Product Exchange and its operations; (b) the filing of annual and triennial updates to the information required by Form 1-N following notice of registration; and (c) supplemental material and reports of security futures products traded. Filings on Form 1-N submitted pursuant to Rule 6a-4 of the Exchange Act (17 CFR 240.6a-4) shall be filed in an electronic format on the Commission's Electronic Data Gathering, Analysis, and Retrieval System (EDGAR) in accordance with EDGAR rules set forth in Regulation S-T (17 CFR part 232). For assistance with EDGAR issues, please consult the EDGAR—Information for Filers web page on
Security Futures Product Exchanges must provide all the information required by the form, including the exhibits, and must present the information in a clear and comprehensible manner. A filing that is incomplete or similarly deficient may be returned to the Security Futures Product Exchange. Any filing so returned shall for all purposes be deemed not to have been filed with the Commission.
The first filing on Form 1-N that a Security Futures Product Exchange submits through EDGAR must contain all items required by Section I.
Form 1-N is composed of 6 types of submissions to the Commission pursuant to Rule 6a-4 under the Exchange Act. In completing Form 1-N, a Security Futures Product Exchange shall select the type of filing and provide all information required by the relevant rules. The types of submissions are:
(1) “Rule 6a-4 Initial Notice of Registration” submissions for notice of registration as a Security Futures Product Exchange. An exchange that is filing Form 1-N may not satisfy the requirements to provide certain information by means of an internet website. All materials must be filed with the Commission as part of the Form 1-N notice of registration.
(2) “Rule 6a-4(b) Amendment to Notice of Registration” submissions for amendments to the Form 1-N, which shall set forth the nature and effective date of the action taken and shall provide any new information and correct any information rendered inaccurate within:
(i) 10 days after any action that is taken renders inaccurate, or that causes to be incomplete, any information in Sections I through IV, or any amendments thereto; or
(ii) 30 days after any action is taken that renders inaccurate, or that causes to be incomplete, any information filed as part of Exhibit F to Form 1-N, or any amendments thereto.
(3) “Rule 6a-4(b)(3) Annual Filing” submission, which shall be filed by June 30 of each year and include Exhibits F, H, and I, which shall be current as of the latest date practicable within 3 months of the date the amendment is filed.
(4) “Rule 6a-4(b)(4) Triennial Filing” submission, which shall be filed by June 30, 2025, and by June 30 every three years thereafter, and shall include complete Exhibits A, B, C, and E. The information filed under this submission type shall be current as of the latest practicable date, but shall at a minimum, be up to date within 3 months as of the date the amendment is filed.
(5) “Rule 6a-4(c)(1) Supplemental Material” submission type, for submission of supplemental material within 10 days after issuing or making such material available to members, participants, or subscribers.
(6) “Rule 6a-4(c)(2) Report of security futures products traded” submission type shall be filed within 15 days after the end of each calendar month. Such report shall contain: (i) For each contract of sale for future delivery of a single security, the number of contracts traded on such exchange during the relevant calendar month and the total number of share underlying such contracts traded; and (ii) For each contract of sale for future delivery of a narrow-based security index, the number of contracts traded on such exchange during the relevant calendar month and the total number of shares represented by the index underlying such contracts traded.
The completed form filed with the Commission shall consist of Form 1-N, responses to all applicable items, and any exhibits required in connection with the filing.
Each time a Security Futures Product Exchange submits a filing to the Commission on Form 1-N, the Security Futures Product Exchange must provide the contact information required by Section II of Form 1-
For assistance with EDGAR issues, please consult the EDGAR—Information for Filers web page on
A copy of this Form 1-N, as well as the forms filed with the SEC, must be retained by the Security Futures Product Exchange and made available for inspection upon request of the SEC.
Form 1-N requires an exchange seeking to register as a national securities exchange for the sole purpose of trading security futures products, pursuant to Section 6(g) of the Exchange Act, to provide the Commission with certain information regarding its operation. If documents containing information satisfying the Commission's information requirements have been filed with the Commodity Futures Trading Commission, copies of such documents may be filed with the Commission. Form 1-N also requires Security Futures Product Exchanges to update certain information on a periodic basis.
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 control number. Sections 3(a)(1), 5, 6(a) and 23(a) authorize the Commission to collect information on this Form 1-N from Security Futures Product Exchanges.
Form 1-N is designed to enable the Commission to determine whether a Security Futures Product Exchange is in compliance with the Exchange Act.
It is estimated that a Security Futures Product Exchange will spend approximately 29 hours completing the initial application on Form 1-N pursuant to Rule 6a-4. It is estimated that each Security Futures Product Exchange will spend approximately 14 hours annually to prepare periodic amendments, 14 hours annually to prepare annual amendments, 7 hours annually to prepare triennial amendments to Form 1-N and 6 hours annually for the required supplemental information and monthly reports pursuant to Rule 6a-4.
Any member of the public may direct to the Commission any comments concerning the accuracy of this burden estimate and any suggestions for reducing this burden.
It is mandatory that an exchange seeking to operate as a national securities exchange for the sole purpose of trading security futures products file a Form 1-N with the Commission. It is also mandatory that Security Futures Product Exchanges file amendments to Form 1-N under Rule 6a-4.
No assurance of confidentiality is given by the Commission with respect to the responses made in Form 1-N. The public has access to the information contained in Form 1-N.
This collection of information has been reviewed by the Office of Management and Budget (“OMB”) in accordance with the clearance requirements of 44 U.S.C. 3507. The Commission has determined that the information collection does not constitute a system of record for purposes of the Privacy Act.
The text of Part II of Form X-17A-5 and the instructions thereto do not and these amendments will not appear in the Code of Federal Regulations.
The text of Part II of Form X-17A-5 and the instructions thereto do not and these amendments will not appear in the Code of Federal Regulations.
This section must be prepared by broker-dealers, nonbank SBSDs, and nonbank MSBSPs registered with the CFTC as futures commission merchants (“FCMs”), swap dealers, and/or introducing brokers pursuant to section 4f and 4s, as applicable, of the Commodity Exchange Act and that elect to file a FOCUS Report in lieu of required CFTC financial reports. (Broker-dealers that notice register as FCMs with the CFTC for the sole purpose of soliciting order, accepting orders, or executing orders for security futures products on behalf of others are not subject to CFTC financial reporting requirements.)
This section should be prepared in accordance with the CFTC's Form 1-FR and other guidance issued by the CFTC or CFTC staff (“CFTC Instructions”).
The text of Part IIC of Form X-17A-5 and the instructions thereto do not and these amendments will not appear in the Code of Federal Regulations.
The text of Form 15A does not and the amendments will not appear in the Code of Federal Regulations.
Form 15A is to be used by an entity for registration with the Securities and Exchange Commission (the “Commission”) as a national securities association or an affiliated securities association, and for any amendments or supplements to such registration statement under Section 15A of the Securities Exchange Act of 1934 (“the Act”). As used hereinafter, the term “Form 15A” includes the form and any required exhibits and schedules thereto.
Form 15A shall be filed in an electronic format through the Commission's Electronic Data Gathering, Analysis, and Retrieval System (EDGAR) in accordance with EDGAR rules set forth in Regulation S-T (17 CFR part 232).
Unless the context clearly indicates otherwise, the terms used in Form 15A have the meanings given in the Act.
A Form 15A that is not prepared and executed in compliance with applicable requirements may be returned as not acceptable for filing. Any filing so returned shall for all purposes be deemed not to have been filed with the Commission.
Form 15A is composed of seven types of submissions to the Commission pursuant to Section 15A of the Act and Rules 15aa-1 and 15aa-2 thereunder. In completing the Form 15A, a registrant shall select the type of filing and provide all information required by the rules and instructions thereunder. In submitting this Form, its exhibits, and its schedules, the person by whom it is executed represents that all information contained within is true, current and complete. The types of submissions are:
(1) Rule 15aa-1 submissions are applications for registration as a national securities association or an affiliated securities association. If Form 15A is being filed as an application for registration as a national securities association, all applicable items are required to be answered in full, except for items in Section IX. If Form 15A is being filed as an application for registration as an affiliated securities association, all applicable items are required to be answered in full. Note: The granting of registration is not to be deemed permanent approval of the association's rules and practices.
(2) Rule 15aa-2(a) submissions shall be filed promptly after the discovery of any inaccuracy in the registration statement or in any amendment or supplement thereto. All amended items are required to be answered in full. All amended exhibits or schedules are
(3) Rule 15aa-2(b) submissions shall be filed promptly after any change which renders no longer accurate any information contained or incorporated in the registration statement or in any amendment or supplement thereto, except that no current supplements need be filed with respect to changes in the information called for in Exhibit B. All supplemented items are required to be answered in full. All supplemented exhibits or schedules are required to be provided completely. Any item that is not being amended may be left blank. If no item in a section is being supplemented, the association may check the box next to the applicable section heading labeled “Check if information has not changed since previous filing.” Supplements setting forth changes in the information called for in Exhibit C need not be filed until 10 days after the calendar month in which the changes occur. If the submission is being filed solely to supplement changes in the information called for in Exhibit C, association should check the applicable box and provide the month and year in which the changes occurred. The association need not provide a current supplement to Exhibit C if it checks the box indicating it has complied with the requirements of Rule 15aa-2(b)(3).
(4) Rule 15aa-2(c) submissions are annual consolidated supplements to a registration statement as a national securities association or an affiliated securities association and shall be filed promptly after March 1 of each year. If the association is filing an annual consolidated supplement to a registration statement as a national securities association, all applicable items are required to be answered in full, except for items in Section IX. If the association is filing an annual consolidated supplement to a registration statement as an affiliated securities association, all applicable items are required to be answered in full. The association need not answer Item 6 if it checks the box indicating it has complied with the requirements of Rules 15aa-2(c)(1)(i)(A)-(B) and provides the applicable information.
(5) Rule 15aa-2(c)(2) submissions shall be filed promptly after the close of each fiscal year of the association. The association is required to provide a complete Exhibit B.
(6) Rule 15aa-2(c)(1)(ii) submissions shall be filed promptly by March 1, 2025, and every three years thereafter. The association is required either to provide a complete Exhibit A or check the boxes indicating it has complied with the requirements of Rules 15aa-2(c)(1)(ii)(A)-(B) and provide the applicable information.
(7) Rule 15aa-2(d)(2) submissions require the association to electronically file any notices, reports, circulars, loose-leaf insertions, riders, new additions, lists or other records of changes when, as, and if such records are made available to members of the association.
The completed form filed with the Commission shall consist of Form 15A, responses to all applicable items, and any exhibits and schedules required in connection with the filing. Any item may be answered by reference to the page, article, section or paragraph of any document filed as an exhibit herewith which contains the information required. Unless the context otherwise requires, the terms “rule of the association,” as used in Form 15A shall include any provision of the association's constitution, charter, articles of incorporation or association and by-laws, and any rule of the association or any of its committees and any settled practice association or of any of its committees having the effect of a rule.
Each time an association submits a filing to the Commission on Form 15A, the association must provide the contact information required by Section X of the form. The contact employee must be authorized to receive all contact information, communications and mailings and must be responsible for disseminating that information within the association's organization.
Consult the EDGAR Filer Manual for EDGAR filing instructions, including the instructions for becoming an EDGAR Filer.
The text of Form X-17A-19 does not, and this amendment will not, appear in the Code of Federal Regulations.
1. * * *
2.
3. The original filed with the Securities and Exchange Commission and the copy filed with the Securities Investor Protection Corporation shall be signed by a duly authorized official of the national securities exchange or registered securities association (self-regulatory organization).
6. Copies of this Form may be obtained on the Commission's website.
The text of Form 19b-4 does not, and this amendment will not, appear in the Code of Federal Regulations.
All proposed rule changes, amendments, extensions, and withdrawals of proposed rule changes shall be filed through the EFFS. All security-based swap submissions, advance notices, and amendments, extensions, and withdrawals of security-based swap
A duly authorized officer of the self-regulatory organization shall electronically sign the completed Form 19b-4 as indicated on Page 1 of the Form. A registered clearing agency for which the Commission is not the appropriate regulatory agency also shall file with its appropriate regulatory agency three copies of the form, one of which shall be manually signed, including exhibits. A clearing agency that also is a designated clearing agency shall file with the Board of Governors of the Federal Reserve System (“Federal Reserve”) three copies of any form containing an advance notice, one of which shall be manually signed, including exhibits; provided, however, that this requirement may be satisfied instead by providing the copies to the Federal Reserve in an electronic format as permitted by the Federal Reserve. The Municipal Securities Rulemaking Board also shall file copies of the form, including exhibits, with the Federal Reserve, the Comptroller of the Currency, and the Federal Deposit Insurance Corporation.
The text of Form CA-1 does not, and this amendment will not, appear in the Code of Federal Regulations.
Form CA-1 is to be used by clearing agencies, as defined in Section 3(a)(23) of the Securities Exchange Act of 1934 (“the Act”), which perform the functions of a clearing agency with respect to any security other than an exempted security, as defined in Section 3(a)(l2) of the Act, to apply for registration or for exemption from registration or to amend registration with the Securities and Exchange Commission (the “Commission”). As used hereinafter, the term “Form CA-1” includes the form and any required schedules, exhibits or attachments thereto. A response is required for every exhibit. For any exhibit that is inapplicable, a statement to that effect shall be furnished in lieu of such exhibit.
Form CA-1 shall be filed in an electronic format through the Commission's Electronic Data Gathering, Analysis, and Retrieval System (EDGAR) in accordance with EDGAR rules set forth in Regulation S-T (17 CFR part 232).
With the exception of certain attachments, Form CA-1 must be provided as an Interactive Data File in accordance with Rule 405 of Regulation S-T. This requirement does not extend to submissions that constitute copies of existing documents other than the financial statements (
In addition, with respect to a clearing agency for which the Commission is not the appropriate regulatory agency, as defined in Section 3(a)(34)(B) of the Act, Section 17(c)(1) of the Act requires such clearing agency to file with the appropriate regulatory agency for such clearing agency a signed copy of any application, document or report filed with the Commission. Each clearing agency should retain an exact copy of Form CA-1 for the clearing agency's records.
Unless the context clearly indicates otherwise, the terms used in Form CA-1 have the meanings given in the Act.
Unless the context otherwise requires, “registrant” means the entity on whose behalf Form CA-1 is filed, whether filed as a registration, as an application for exemption from registration or as an amendment to a previously filed Form CA-1.
A Form CA-1 which is not prepared and executed in compliance with applicable requirements may be returned as not acceptable for filing. Any filing so returned shall for all purposes be deemed not to have been filed with the Commission.
Individuals' names, except for executing signatures, shall be given in full wherever required (last name, first name, and middle name). The full middle name is required. Initials are not acceptable unless the individual legally has only an initial.
Form CA-1 is comprised of 3 types of submissions to the Commission pursuant to Section 17A(b)(1) of the Act and Rule 17ab2-1 thereunder. In completing the Form CA-1, a registrant shall select the type of filing and provide all information required by the rules and instructions thereunder. For any exhibit that is inapplicable, a statement to that effect shall be furnished in lieu of such exhibit. In submitting this Form, its schedules, its
(1) Rule 17ab2-1(a) submissions are applications for registration as a clearing agency or for exemption from registration as a clearing agency. If Form CA-1 is being filed as a registration form or an application for exemption from registration, all applicable items are required to be answered in full. If any item is not applicable respond with “none” or “N/A” (not applicable) as appropriate. If the Form is filed as a registration, indicate whether the applicant requests the Commission to consider granting registration in accordance with paragraph (c)(1) of Rule 17ab2-1. If Form CA-1 is being filed as an application for exemption from registration, it must be accompanied by a statement, marked as Exhibit S, demonstrating why the granting of an exemption from registration as a clearing agency would be consistent with the public interest, the protection of investors and the purposes of Section 17A of the Act.
(2) Rule 17ab2-1(e) submissions shall be filed promptly following the date on which information reported on items 1-3 on Form CA-1 becomes inaccurate, incomplete or misleading. Submission of any amendment after registration has become effective represents that items 1-3 and any schedules, exhibits and attachments related to items 1-3 remain true, current and complete as previously submitted.
(3) Sec. 17A(b)(1) submissions shall be filed as directed by any Order approving an application for exemption from registration as a clearing agency. Such submissions may include any report, notice or other submission as ordered by the Commission as a condition of granting exemption from registration.
The completed form filed with the Commission shall consist of Form CA-1, responses to all applicable items, and any schedules and exhibits required in connection with the filing. Each filing shall be marked on Form CA-1 with the initials of the registrant, the four-digit year, and the number of the filing for the year (
Each time a registrant submits a filing to the Commission on Form CA-1, the registrant must provide the contact information required by Section II of the form. The contact employee must be authorized to receive all contact information, communications and mailings and must be responsible for disseminating that information within the registrant's organization.
Consult the EDGAR Filer Manual for EDGAR filing instructions, including the instructions for becoming an EDGAR Filer.
If Form CA-1 is filed by a corporation, it shall be signed in the name of the corporation by a principal officer duly authorized; if it is filed other than by a corporation it shall be signed by a duly authorized principal of the organization filing the Form. As used in this Form, principal officer means the president, vice president, treasurer, secretary, comptroller or any other person performing a similar function.
The EDGAR receipt confirmation that demonstrates who filed the Form CA-1 shall be preserved pursuant to the requirements of Section 17 of the Act and any rules and regulations thereunder.
Request for confidential treatment.
In responding to, and furnishing the schedules required by, the items on Form CA-1, the registrant may request that confidential treatment be accorded with respect to the information disclosed. The registrant must furnish a statement requesting confidential treatment, detailing the specific responses, schedules and exhibits for which confidential treatment is sought, and specifying both the exemptive provision under the Freedom of Information Act (5 U.S.C. 552(b)) on which the request is based and the considerations which make the exemptive provision applicable to the information for which confidential treatment is requested.
Disclosure to the Commission of the information requested in Form CA-1 (except for the disclosure by an individual registrant of his Social Security number as an IRS Employee Identification Number, which is voluntary) is a prerequisite to the processing of applications for registration or for exemption from registration as a clearing agency.
An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a current valid control number. Under Sections 17, 17A(b) and 23(a) of the Act and the rules and regulations thereunder, the Securities and Exchange Commission is authorized to solicit the information required to be supplied by this Form from applicants for registration or for exemption from registration as a clearing agency.
The information will be used for the principal purpose of determining whether the Commission should grant registration or an exemption from registration or institute proceedings to deny registration. Social Security numbers, if furnished, will be used only to assist the Commission in identifying applicants and, therefore, in promptly processing applications.
It is estimated that a clearing agency will have an average burden of approximately 338 hours completing a new application on the Form CA-1, and 58 hours completing an amendment to an application on the Form CA-1. Any member of the public may direct to the Commission any comments concerning the accuracy of the burden estimate on the facing page of Form CA-1 and any suggestions for reducing this burden.
It is mandatory that an applicant seeking to operate as a clearing agency or as an exempt clearing agency file Form CA-1 with the Commission. It is also mandatory that registrants file amendments to Form CA-1 under Rule 17ab2-1(e).
Information supplied on this Form will be included routinely in the public files of the Commission.
National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.
Final rule; notification of issuance of Letters of Authorization.
NMFS, upon request from the U.S. Department of the Air Force (USAF), issues these regulations pursuant to the Marine Mammal Protection Act (MMPA) to govern the taking of marine mammals incidental to testing and training activities to be conducted in the Eglin Gulf Test and Training Range (EGTTR) from 2023 to 2030 in the Gulf of Mexico. The USAF's activities qualify as military readiness activities pursuant to the MMPA, as amended by the National Defense Authorization Act for Fiscal Year 2004 (2004 NDAA). These regulations, which allow for the issuance of Letters of Authorization (LOA) for the incidental take of marine mammals during the described activities and timeframes, prescribe the permissible methods of taking and other means of effecting the least practicable adverse impact on marine mammal species and their habitat, and establish requirements pertaining to the monitoring and reporting of such taking.
A copy of the USAF's application, NMFS' proposed and final rules and subsequent LOA for the existing regulations, and other supporting documents and documents cited herein may be obtained online at
Robert Pauline, Office of Protected Resources, NMFS, (301) 427-8401.
These regulations, issued under the authority of the MMPA (16 U.S.C. 1361
Eglin Air Force Base (AFB) will conduct operations in the existing Live Impact Area (LIA). In addition, the USAF will also create and use a new, separate LIA within the EGTTR that would be used for live missions in addition to the existing LIA. Referred to as the East LIA, it is located approximately 40 nautical miles (nmi) (74 kilometers (km)) southeast of the existing LIA.
NMFS received an application from the USAF requesting 7-year regulations and an authorization to incidentally take individuals of multiple species of marine mammals (“USAF's rulemaking/LOA application” or “USAF's application”). Take is anticipated to occur by Level A and Level B harassment incidental to the USAF's training and testing activities, with no serious injury or mortality expected or authorized.
Section 101(a)(5)(A) of the MMPA (16 U.S.C. 1371(a)(5)(A)) directs the Secretary of Commerce (as delegated to NMFS) to allow, upon request, the incidental, but not intentional taking of small numbers of marine mammals by U.S. citizens who engage in a specified activity (other than commercial fishing) within a specified geographical region if, after notice and public comment, the agency makes certain findings and issues regulations that set forth permissible methods of taking pursuant to that activity, as well as monitoring and reporting requirements. Section 101(a)(5)(A) of the MMPA and the implementing regulations at 50 CFR part 216, subpart I, provide the legal basis for issuing this final rule and the subsequent LOAs. As directed by this legal authority, this final rule contains mitigation, monitoring, and reporting requirements.
The 2004 NDAA (Pub. L. 108-136) removed the “small numbers” and “specified geographical region” limitations indicated above and amended the definition of “harassment” as applied to a “military readiness activity.” The activity for which incidental take of marine mammals is being requested addressed here qualifies as a military readiness activity.
More recently, section 316 of the NDAA for Fiscal Year 2019 (2019 NDAA) (Pub. L. 115-232), signed on August 13, 2018, amended the MMPA to allow incidental take rules for military readiness activities under section 101(a)(5)(A) to be issued for up to 7 years. Prior to this amendment, all incidental take rules under section 101(a)(5)(A) were limited to 5 years.
The following is a summary of the primary provisions of this final rule regarding the USAF's activities. These provisions include, but are not limited to:
• Use of live munitions with surface or subsurface detonations is restricted to the existing Live Impact Area (LIA) and the new East LIA;
• Use of live munitions in the western part of the existing LIA and new East LIA is restricted based on specified setbacks from the 100-meter isobath. The 100-m isobath is the minimum depth at which the majority of Rice's whale detections have occurred. The setbacks are equivalent to the modeled threshold distances where each mission-day category would cause the onset of permanent threshold shift (PTS) in the Rice's whale;
• Use of inert munitions is prohibited between the 100-meter to 400-meter isobaths throughout the EGTTR, which encompasses the area in which the vast majority of Rice's whale detections have occurred;
• Gunnery missions must be conducted at least 500 meters landward of the 100-meter isobath; and
• Use of 105 mm Training Rounds (TR) containing decreased explosive material is required during live nighttime gunnery missions.
• Use of vessel-based, aerial-based and video-based monitoring platforms for mission activities;
• Employment of protected species observers (PSOs) who have completed Eglin's Marine Species Observer Training Course developed in cooperation with NMFS;
• Implementing two passive acoustic monitoring (PAM) studies (pending availability of funding); and
• Submission of annual and final comprehensive monitoring reports that will record all occurrences of marine mammals and any behavior or behavioral reactions observed, any observed incidents of injury or behavioral harassment, and any required mission delays, relocations or cancellations.
Additionally, the rule includes an adaptive management component that allows for timely modification of mitigation or monitoring measures based on new information, when appropriate.
The MMPA prohibits the “take” of marine mammals, with certain exceptions. Sections 101(a)(5)(A) and (D) of the MMPA direct the Secretary of Commerce (as delegated to NMFS) to allow, upon request, the incidental, but not intentional, taking of small numbers of marine mammals by U.S. citizens who engage in a specified activity (other than commercial fishing) within a specified geographical region if certain findings are made and either regulations are issued or, if the taking is limited to harassment, a notice of proposed authorization is provided to the public for review and the opportunity to submit comments.
An authorization for incidental takings shall be granted if NMFS finds that the taking will have a negligible impact on the species or stocks and will not have an unmitigable adverse impact on the availability of the species or stocks for taking for subsistence uses where relevant, including by Alaska Natives. Further, NMFS must prescribe the permissible methods of taking and other means of effecting the least practicable adverse impact on the affected species or stocks and their habitat, paying particular attention to rookeries, mating grounds, and areas of similar significance, and on the availability of the species or stocks for taking for certain subsistence uses (referred to in this rule as “mitigation measures”); and requirements pertaining to the monitoring and reporting of such takings. The MMPA defines “take” to mean to harass, hunt, capture, or kill, or attempt to harass, hunt, capture, or kill any marine mammal. The Analysis and Negligible Impact Determination section below discusses the definition of “negligible impact.”
The NDAA for Fiscal Year 2004 (2004 NDAA) (Pub. L. 108-136) amended section 101(a)(5) of the MMPA to remove the “small numbers” and “specified geographical region” provisions indicated above and amended the definition of “harassment” as applied to a “military readiness activity.” The definition of harassment for military readiness activities (section 3(18)(B) of the MMPA) is (i) Any act that injures or has the significant potential to injure a marine mammal or marine mammal stock in the wild (Level A Harassment); or (ii) Any act that disturbs or is likely to disturb a marine mammal or marine mammal stock in the wild by causing disruption of natural behavioral patterns, including, but not limited to, migration, surfacing, nursing, breeding, feeding, or sheltering, to a point where such behavioral patterns are abandoned or significantly altered (Level B harassment). In addition, the 2004 NDAA amended the MMPA as it relates to military readiness activities such that the least practicable adverse impact analysis shall include consideration of personnel safety, practicality of implementation, and impact on the effectiveness of the military readiness activity.
More recently, section 316 of the NDAA for Fiscal Year 2019 (2019 NDAA) (Pub. L. 115-232), signed on August 13, 2018, amended the MMPA to allow incidental take rules for military readiness activities under section 101(a)(5)(A) to be issued for up to 7 years. Prior to this amendment, all incidental take rules under section 101(a)(5)(A) were limited to 5 years.
On January 18, 2022, NMFS received an application from the USAF for authorization to take marine mammals by Level A and Level B harassment incidental to training and testing activities (categorized as military readiness activities) in the EGTTR for a period of 7 years. On June 17, 2022, NMFS received an adequate and complete application for missions that would include air-to-surface operations that involve firing live or inert munitions, including missiles, bombs, and gun ammunition from aircraft at targets on the water surface. The types of targets used vary by mission and primarily include stationary, remotely controlled, and towed boats, inflatable targets, and marker flares. Live munitions used in the EGTTR are set to detonate either in the air a few feet above the water surface (airburst detonation), instantaneously upon contact with the water or target (surface detonation), or approximately 5 to 10 feet (1.5 to 3 m) below the water surface (subsurface detonation). On July 17, 2022, we published a notice of receipt (NOR) of application in the
This is the second time NMFS has promulgated incidental take regulations pursuant to the MMPA relating to similar military readiness activities in the EGTTR. On February 8, 2018, NMFS promulgated a rulemaking and issued an LOA for takes of marine mammals incidental to Eglin AFB's training and testing operations in the EGTTR (83 FR 5545).
Most operations during the current effective period are a continuation of the same operations conducted by the same military units during the previous mission period. There will, however, be an increase in the annual quantities of all general categories of munitions (bombs, missiles, and gun ammunition) under the USAF's planned activities, except for live gun ammunition, which will be used less over the next mission period. The highest net explosive weight (NEW) of the munitions under the USAF's activities will be 945 pounds (lb) (430 kilograms (kg)), which was also the highest NEW for the previous mission period. Live missions planned for the 2023-2030 period will be conducted in the existing Live Impact Area (LIA) within the EGTTR. Certain missions may also be conducted in the East LIA, which is a new, separate area within the EGTTR where live and inert munitions will be used.
The USAF's rulemaking/LOA application reflects the most up-to-date compilation of training and testing activities deemed necessary to accomplish military readiness requirements. EGTTR training and testing operations are critical for achieving military readiness and the overall goals of the National Defense Strategy. The regulations cover testing
A detailed description of the specified activity was provided in our
Detailed descriptions of these activities are described in the Eglin Gulf Test and Training Range (EGTTR) Range rulemaking/LOA application (
The specified activities will occur at any time during the 7-year period of validity of the regulations. The planned amount of training and testing activities are described in the Detailed Description of the Specified Activities section.
The Eglin Military Complex encompasses approximately 724 square miles (1,825 km
The USAF's planned activities provide for the creation of a new, separate area within the EGTTR that will be used for live missions in addition to the existing LIA. This area, herein referred to as the East LIA, is located approximately 40 nmi offshore of Eglin AFB property on Cape San Blas. Cape San Blas is located on St. Joseph Peninsula in Gulf County, Florida, approximately 90 mi (144 km) southeast of the Eglin Reservation. Eglin AFB facilities on Cape San Blas remotely support EGTTR operations via radar tracking, telemetry, and other functions. The East LIA is circular-shaped and has a radius of approximately 10 nmi (18.5 km) and a total area of approximately 314 nmi
This section provides descriptions of each military user group's planned EGTTR operations, as well as information regarding munitions planned to be used during the operations. This information includes munition type, category, net explosive weight (NEW), detonation scenario, and annual quantity planned to be expended in the EGTTR. NEW applies only to live munitions and is the total mass of the explosive substances in a given munition, without packaging, casings, bullets, or other non-explosive components of the munition. Note that for some munitions the warhead is removed and replaced with a telemetry package that tracks the munition's path and/or Flight Termination System (FTS) that ends the flight of the munition in a controlled manner. These munitions have been categorized as live munitions with NEWs that range from 0.30 to 0.70 lb (0.13 to 0.31 kg). While certain munitions with only FTS may be considered inert due to negligible NEW, those contained here are considered to be live with small amounts of NEW. The detonation scenario applies only to live munitions which are set to detonate in one of three ways: (1) in the air a few feet above the water surface, referred to as airburst or height of burst (HOB); (2) instantaneously upon contact with the water or target on the water surface; or (3) after a slight delay, up to 10 milliseconds, after impact, which would correspond to a subsurface detonation at a water depth of approximately 5 to 10 ft (1.5 to 3 m). Estimated take is only modeled for scenarios (2) and (3). The planned annual expenditures of munitions are the quantities determined necessary to meet the mission requirements of the user groups.
Live missions planned for the 2023-2030 period would be conducted in the existing LIA and the East LIA, depending on the mission type and objectives. Live missions that involve only airburst or aerial target detonations would continue to be conducted in or outside the LIA in any portion of the EGTTR; such detonations have no appreciable effect on marine mammals because there is negligible transmission of pressure or acoustic energy across the air-water interface. Use of inert munitions and live air-to-surface gunnery operations would also continue to occur in or outside the LIA, subject to required mitigation and monitoring measures.
Eglin AFB plans to implement the following actions in the EGTTR which would be conducted in the existing LIA
(1) 53rd Weapons Evaluation Group missions that involve air-to-surface tests various types of munitions against small target boats, and air-to-air missile testing;
(2) Continuation of the Air Force Special Operations Command (AFSOC) training missions in the EGTTR primarily involving air-to-surface gunnery, bomb, and missile exercises including AC-130 gunnery training, CV-22 training, and bomb and missile training;
(3) 96th Operations Group missions including AC-130 gunnery testing against floating marker targets on the water surface, and other aircraft air-to-surface testing; and 780th Test Squadron weapons testing of air-launched cruise missiles, air-to-air missiles, air-to-surface missiles, and surface-to-air missiles using live and inert munitions against targets on the water surface; and
(4) Naval School Explosive Ordnance Disposal (NAVSCOLEOD) training missions that involve students diving and placing small explosive charges adjacent to inert mines.
The 53rd Weapons Evaluation Group (53 WEG) conducts the USAF's air-to-ground Weapons System Evaluation Program (WSEP) for testing various types of live and inert munitions against small target boats. This testing is conducted to develop tactics, techniques, and procedures (TTP) to be used by USAF aircraft to counter small, maneuvering, hostile vessels. Missions planned in the EGTTR for the 2023-2030 period would involve the use of several types of aircraft. USAF, Air National Guard, and U.S. Navy units would support these missions. Live munitions would be deployed against static (anchored), remotely controlled, and towed targets. Static and remotely controlled targets would consist of stripped boat hulls with simulated systems and, in some cases, heat sources. Various types of live and inert munitions are used during 53 WEG missions in the EGTTR, including missiles, bombs, and gun ammunition. Table 1 presents information on the munitions planned for 53 WEG air-to-surface missions in the EGTTR during the 2023-2030 period.
The 53 WEG also conducts live air-to-air missile testing in the EGTTR. These missions also include firing inert gun ammunition and releasing flares and chaff from aircraft. Air-to-air missile testing during these missions specifically involves firing live missiles at sub-and full-scale Aerial Targets to evaluate the effectiveness of missile delivery techniques. These missions involve the use of several types of fighter aircraft. Table 2 presents information on the munitions planned to be used during 53 WEG missions in the EGTTR.
The Air Force Special Operations Command (AFSOC) plans to continue conducting training missions during the 2023-2030 period. These missions primarily involve air-to-surface gunnery, bomb, and missile exercises. Gunnery training in the EGTTR involves firing live rounds from AC-130 gunships at targets on the water surface. Gun ammunition used for this training primarily includes 30-millimeter (mm) High Explosive (HE) and 105 mm HE rounds. A standard 105 mm HE round has a NEW of 4.7 lb. The Training Round (TR) variant of the 105 mm HE round, which has a NEW of 0.35 lb, is used by AFSOC for nighttime missions. This TR was developed to have less explosive material to minimize potential impacts to protected marine species, which could not be adequately surveyed at night by earlier aircraft instrumentation. Since the development of the 105 mm HE TR, AC-130s have been equipped with low-light electro-optical and infrared sensor systems that provide excellent night vision. Targets used for AC-130 gunnery training include Mark (Mk)-25 marine markers and inflatable targets. During each gunnery training mission, gun firing can last up to 90 minutes but typically lasts approximately 30 minutes. Live firing is continuous, with pauses usually lasting well under 1 minute and rarely up to 5 minutes. Table 3 presents information on the rounds planned for AC-130 gunnery training by AFSOC.
The 8th Special Operations Squadron (8 SOS) under AFSOC conducts training in the EGTTR using the tiltrotor CV-22 Osprey. This training involves firing .50 caliber rounds from CV-22s at floating marker targets on the water surface. The .50 caliber rounds do not contain explosive material and, therefore, do not detonate. Flight procedures for CV-22 training are similar to those described for AC-130 gunnery training, except that CV-22 aircraft typically operate at much lower altitudes (100 to 1,000 feet (30.48 to 304.8 m) (AGL) than AC-130 gunships (6,000 to 20,000 feet (1,828 to6,96 m) AGL). Like AC-130 gunships, CV-22s are equipped with highly sophisticated electro-optical and infrared sensor systems that allow advanced detection capability during day and night. Table 4 presents information on the rounds planned for CV-22 training missions.
In addition to AC-130 gunnery and CV-22 training, AFSOC also conducts other air-to-surface training in the EGTTR using various types of live and inert bombs and missiles as shown in Table 5. These munitions are launched from various types of aircraft against small target boats, and they either detonate on impact with the target or at a programmed HOB.
Three units under the 96th Operations Group (96 OG) plan to conduct missions in the EGTTR during the 2023-2030 period: the 417th Flight Test Squadron (417 FLTS), the 96th Operational Support Squadron (96 OSS), and the 780th Test Squadron (780 TS).
The 417 FLTS plans to continue conducting AC-130 systems and munitions testing in the EGTTR. AC-130 gunnery testing is generally similar to activities previously described for AFSOC AC-130 gunnery training.
Table 6 presents information on the munitions planned for AC-130 testing in the EGTTR during the 2023-2030 mission period.
The 96 OSS plans to conduct air-to-surface testing in the EGTTR using assorted live missiles and live and inert precision-guided bombs to support testing requirements for multiple programs. The planned munitions would include captive carry and munitions employment tests. During munition employment tests, the planned munitions would be launched from aircraft at various types of static and moving targets on the water surface. Table 7 presents information on the munitions planned by the 96 OSS for testing in the EGTTR.
The 780 TS, the Air Force Life Cycle Management Center, and the U.S. Navy jointly conduct some test missions in the EGTTR. These missions use precision-guided bombs. Some munitions would detonate at a HOB of approximately 5 ft (0.30 m); however, these detonations are assumed to occur at the surface for the impact analysis. Other munitions would detonate either at a HOB of approximately 7 to 14 ft (2.1 to 4.2 m) or upon impact with the target (surface). For simultaneous munition launches, two munitions would be launched from the same aircraft at approximately the same time to strike the same target. These simultaneously launched munitions would strike the target within approximately 5 seconds or less of each other. Such detonations would be considered a single event, with the associated NEW being doubled for a conservative impact analysis.
Two types of targets are typically used for 780 TS tests: Container Express (CONEX) targets and hopper barge targets. CONEX targets typically consist of up to five CONEX containers strapped, braced, and welded together to form a single structure. A hopper barge is a common type of barge that cannot move itself; a typical hopper barge measures approximately 30 ft (9.1 m) by 12 ft (3.6 m) by 125 ft (38.1 m).
Other 780 TS tests in the EGTTR during the 2023-2030 mission period may include operational testing of a third bomb munition. These tests may involve live and inert testing of the munition against target boats.
Table 8 presents information on the munitions planned for these 780 TS missions in the EGTTR during the 2023-2030 period.
The 780 TS, along with the Air Force Life Cycle Management Center and U.S. Navy, plans to jointly conduct air-to-air missile testing in the EGTTR. These missions would involve the use of missiles; all missiles used in these tests would be inert. Table 9 presents information on the munitions planned for air-to-air missile testing missions in the EGTTR during the 2023-2030 mission period.
The 780 TS plans to test the ability of other missiles to track and impact moving target boats in the EGTTR as shown in Table 10. The test targets would be remotely controlled boats, including the 25-foot High-Speed Maneuverable Surface Target (HSMST) (foam filled) and 41-foot (12.5 m) Coast Guard Utility Boat (metal hull).
The 780 TS plans to test an air-to-surface tactical missile system against static and moving target boats in the EGTTR. These missiles shown in Table 11 would target foam-filled fiberglass boats approximately 25 ft (7.62 m) in length that are either anchored or towed by a remotely controlled (HSMST).
The 780 TS plans to conduct surface-to-air testing of missiles in the EGTTR. These missiles are expected to be fired from the A-15 launch site on Santa Rosa Island in the EGTTR. Detailed operational data for this testing are not yet available. Standard inventory missiles would be used and up to eight tests of one type and two tests of another type per year are planned as shown in Table 12.
Hypersonic weapons are capable of traveling at least five times the speed of sound, referred to as Mach 5. While conventional weapons typically rely on explosive warheads to inflict damage on a target, hypersonic weapons typically rely on kinetic energy from high-velocity impact to inflict damage on targets. For the purpose of assessing impacts, the kinetic energy of a hypersonic weapon may be correlated to energy release in units of feet-lb or trinitrotoluene (TNT) equivalency.
The 780 TS supports hypersonic weapon programs which are presented in Table 13.
780 TS plans to conduct testing of one type of hypersonic missile, which would involve air launches through a north-south corridor within the EGTTR to a target location on the water surface. The dimensions and orientation of the test flight corridor within the EGTTR for these tests are to be determined; the flight corridor is expected to be 300 to 400 nmi (555 to 740 km) in total length. Live types of missiles would be fired from the southern portion of the EGTTR into either the existing LIA or planned East LIA. Up to two live of these live missiles per year are planned to be tested in the EGTTR during the 2023-2030 mission period.
The 780 TS in coordination with the U.S. Army plans to conduct testing of another type of hypersonic missile in the EGTTR. Some testing of these missiles is expected to involve surface launches from the A-15 launch site on Santa Rosa Island. The dimensions and orientation of the test flight corridor within the EGTTR for these tests are to be determined; the flight corridor is expected to be 162 to 270 nmi (300 to 500 km) in total length. For tests that involve a live warhead on these missiles, they would be preset to detonate at a specific height above the water surface (HOB/airburst) and could occur in any portion of the EGTTR. Any surface strikes planned with these live missiles would be required to be in the existing LIA or East LIA. Like inert of the previously mentioned missile type, inerts of this type could occur in any portion of the EGTTR, except between the 100-m and 400-m isobaths to prevent impacts to the Rice's whale.
The 780 TS, in coordination with the Air Force Research Laboratory, plans to conduct sink at-sea live-fire training exercises (SINKEX) testing in the EGTTR. SINKEX exercises would involve the sinking of vessels, typically 200-400 ft (61-122 m) in length, in the existing LIA. The types of munitions that would be used for SINKEX testing is controlled information and, therefore, not identified (Table 14).
The 780 TS plans to lead or support other types of testing in the EGTTR as shown in Table 15. These missions would primarily include testing live and inert munitions against targets on the water surface, such as boats and barges. Some of the tests would involve munitions with NEWs of up to 945 lb, which is the highest NEW associated with the munitions analyzed in this LOA application
The 96 OG plans to continue expanding approximately nine inert bombs a year in the EGTTR for testing purposes. The bombs are expected to be up to 2,000 lb (907 kg) in total weight. For the impact analysis, the bombs to be used by the 96 OG in the EGTTR during the 2023-2030 mission period are assumed to be 2,000 lb (907 kg) General Purpose (GP) inert bombs (Table 16).
NAVSCOLEOD plans to conduct training missions in the EGTTR which would include Countermeasures (MCM) exercises to teach NAVSCOLEOD students techniques for neutralizing mines underwater (Table 17). Underwater MCM training exercises are conducted in nearshore waters and primarily involve diving and placing small explosive charges adjacent to inert mines by hand; the detonation of such charges disables live mines. NAVSCOLEOD training is conducted offshore of Santa Rosa Island and in other locations and has not yet extended into the EGTTR. NAVSCOLEOD training planned for the 2023-2030 mission period would extend approximately 5 nmi (9.26 km) offshore of Santa Rosa Island, in the EGTTR. Up to 8 MCM training missions would be conducted annually in the EGTTR during the 2023-2030 period. Each mission would involve 4 underwater detonations of charges hand placed adjacent to inert mines, for a total of 32 annual detonations. The MCM neutralization charges consist of C-4 explosives, detonation cord, non-electric blasting caps, time fuzes, and fuze igniters; each charge has a NEW of approximately 20 lb. (9.07 kg). During each mission, with a maximum of 4 charges, would detonate with a delay no greater than 20 minutes between shots. After the final detonation, or a delay greater than 20 minutes, a 30-minute environmental observation would be conducted. Additionally, NAVSCOLEOD plans to conduct up to 80 floating mine training missions, which would involve detonations of charges on the water surface; these charges would have a NEW of approximately 5 lb (2.3 kg). All NAVSCOLEOD missions would occur only during daylight hours.
The USAF uses the EGTTR for training purposes and for testing of a variety of weapon systems described in this planned rule. All of the weapons systems considered likely to cause the take of marine mammals involve explosive detonations. Training and testing with these systems may introduce acoustic (sound) energy or shock waves from explosives into the environment. The following section describes explosives detonated at or just below the surface of the water within the EGTTR. Because of the complexity of analyzing sound propagation in the ocean environment, the USAF relied on acoustic models in its environmental analyses and rulemaking/LOA application that considered sound source characteristics and conditions across the EGTTR.
Explosive detonations at the water surface send a shock wave and sound energy through the water and can release gaseous by-products, create an oscillating bubble, or cause a plume of water to shoot up from the water surface. When an air-to-surface munition impacts the water, some of the kinetic energy displaces water in the formation of an impact “crater” in the water, some of the kinetic energy is transmitted from the impact point as underwater acoustic energy in a pressure impulse, and the remaining kinetic energy is retained by the munition continuing to move through the water. Following impact, the warhead of a live munition detonates at or slightly below the water surface. The warhead detonation converts explosive material into gas, further displacing water through the rapid creation of a gas bubble in the water, and creates a much larger pressure wave than the pressure wave created by the impact. These impulse pressure waves radiate from the impact point at the speed of sound in water, roughly 1,500 m per second. If the detonation is sufficiently deep, the gas bubble goes through a series of expansions and contractions, with each cycle being of successively lower energy. When detonations occur below but near the water surface, the initial gas bubble reaches the surface and causes venting, which also dissipates energy through the ejection of water and release of detonation gasses into the atmosphere. When a detonation occurs below the water surface after the impact crater has fully or partially closed, water can be violently ejected upward by the pressure impulse and through venting of the gas bubble formed by the detonation.
With radii of up to 15 m, the gas bubbles that would be generated by EGTTR munition detonations would be larger than the depth of detonation but much smaller than the water depth, so all munitions analyzed are considered to fully vent to the surface without forming underwater bubble expansion and contraction cycles. When detonations occur at the water surface,
The impulsive pressure waves generated by munition impact and warhead detonation radiate spherically and are reflected between the water surface and the sea bottom. There is generally some attenuation of the pressure waves by the sea bottom but relatively little attenuation of the pressure waves by the water surface. As a conservative assumption, the water surface is assumed to be flat (no waves) to allow for maximum reflectivity. Additionally, is it assumed that all detonations occur in the water and none of the detonations occur above the water surface when a munition impacts a target. This conservative assumption implies that all munition energy is imparted to the water rather than the intended targets. The potential impacts of exposure to explosive detonations are discussed in detail in the Potential Effects of Specified Activities on Marine Mammals and their Habitat section of the notice of proposed rulemaking published in the
We published the proposed rule in the
NMFS notes that video cameras are planned/required for use in all regular situations, and might not be used in situations of unplanned circumstances, such as in cases of equipment malfunction. In such situations, the test engineer and other staff can make a decision to delay, cancel, or postpone a mission due to asset status (
Regarding the effectiveness of aerial monitoring, NMFS notes that the electro-optical sensors employed by the USAF were specifically designed to detect targets on the electromagnetic spectrum under such areal and altitudinal parameters. NMFS is confident in the USAF's ability to effectively monitor for marine mammals from aircraft and marine vessels.
As of this writing, funding has been requested from near-term funding sources but has not yet been approved by the USAF for the second part of the study, which was to follow up on the results of the initial PAM study. NMFS and the USAF have reviewed the findings from the initial study and will discuss specific next steps. Furthermore, NMFS has included language in this final rule and the LOA requiring the USAF to prioritize studies to (1) follow up on the results of the initial PAM study by investigating marine mammal vocalizations before, during, and after live missions in the EGTTR, pending the availability of funding; and (2) investigate ways to supplement its mitigation measures with the use of real-time PAM devices, pending the availability of funding.
The Commission recommended that NMFS and the USAF investigate the possible use of sonobuoys for the second part of the study. NMFS and the USAF appreciate the Commission's recommendations regarding possible use of various types of sonobuoys.
(1) The Commission recommended that the USAF establish two platforms (aerial and vessel) for conducting visual monitoring of a 4.6-km mitigation zone from 90 minutes before the first firing.
NMFS will require all range clearing vessels to be on site 90 minutes before the mission to clear the prescribed human safety zone and survey the mitigation zone for the given mission-day category. Up to 25 vessels will be used depending upon the size of the NEW. Not all of these vessels will contain PSOs, but these will also be looking for marine mammals in addition to range-clearing exercises. PSOs will be stationed on all vessels that are required to monitor the mitigation zones for the given mission-day category for a minimum of 30 minutes or until the entirety of the mitigation zone has been surveyed, whichever takes longer. Furthermore, all mission-day categories require aerial-based monitoring, assuming assets are available and when such monitoring does not interfere with testing and training parameters required by mission proponents.
While the aerial platforms may not always be onsite 90 minutes before the mission, the measures required in these regulations provide similar equivalent protection, as the entirety of the mitigation zone will have been monitored by PSOs on vessels and aircraft a short time before the mission commences.
(2) The Commission recommended that the USAF should conduct both visual monitoring from a vessel and passive acoustic monitoring of the mitigation zone during the exercise.
Real-time visual monitoring from a vessel would pose a safety threat to both the PSO as well as crew of the vessel. All vessels must have exited the human safety zone prior to the commencement of SINKEX activities. The large size of the human safety zone means that extended distance from a vessel to the SINKEX target area would not allow for effective monitoring from a vessel. However, video-based monitoring will be employed during SINKEX missions, which provides real-time observation data for the mitigation zone.
NMFS has engaged in multiple discussions with the USAF about the implementation of PAM. However, human safety concerns and the inability to make mission go/no-go decisions in a timely manner are the most immediate obstacles for the USAF implementing PAM as part of the suite of mitigation measures during live weapon missions in the EGTTR. For safety purposes during live air-to-surface missions in the EGTTR and during SINKEX exercises portions of the Gulf of Mexico are closed off to human activity. The human safety zone corresponds to the weapon safety footprint. The size of the closure area varies depending on the weapons being dropped, the type of aircraft being used, and the specific release parameters (direction, altitude, airspeed, etc.) requested by the mission group, but it always encompasses the area occupied by the instrumentation barge (GRATV). Typically, this footprint is where personnel are restricted to ranges between a 9-nautical mile (nmi) radius up to a 12-nmi radius around the GRATV from the target and the GRATV that is usually within hundreds of meters of the target. As part of PAM, biologists generally deploy an array of hydrophones, listen for vocalizations
The USAF is supportive of PAM and has conducted a NMFS-approved PAM study in 2020 to increase our understanding of acoustic impacts associated with underwater detonations. Given the need for additional research as recommended by the Commission, additional studies have been established as conditions of these regulations and LOA. Development, testing and full implementation of a real-time PAM system is not likely feasible during the effective period of the new LOA due to human safety concerns and the need for additional investigations of efficacious protocols. Considering all of this, the use of PAM as a real-time mitigation measure is not practicable at this time.
(3) The Commission recommended that the USAF observe marine mammals in the vicinity of where detonations occurred for 2 hr after sinking the vessel or until sunset (whichever comes first).
The post-mission survey area will be the area covered in 30 minutes of observation by both aerial crews and vessels in a direction down-current from the impact site or the actual pre-mission survey area, whichever is reached first. PSOs must survey the mission site for any dead or injured marine mammals. Additionally, post-mission cleanup operations will recover as much target-related debris as possible from the water surface by hand and by using dip nets. The USAF reports that typical post-cleanup operations involve the use of up to 10 vessels for up to 2 to 3 hours depending on the size of the NEW, and personnel on these vessels will be instructed to report any dead or injured marine mammals to the Lead Biologist. NMFS is not requiring a minimum time limit or specifying the number of vessels that must be employed post mission since it is difficult, if not impossible, to predict how much debris will occur at or near a given SINKEX mission location. Furthermore, it is inefficient and costly to require multiple vessels primarily engaged in cleanup activities to continue monitoring for extended periods after cleanup is complete. For single-detonation SINKEX actions, the USAF has committed to survey the entirety of the mission area or survey for 30 minutes, whichever comes first.
(4) The Commission recommended that any additional platforms supporting the primary mission activity (
As noted above, up to 10 USAF support vessels primarily focused on collecting debris will spend several hours in the mission area collecting debris from damaged targets. All vessels will be instructed to report any dead or injured marine mammals to the Lead Biologist.
In summary, with the exception of PAM, which NMFS concurs with the USAF is not practicable at this time, the USAF's required mitigation and monitoring measures are either similar to those employed by the Navy or provide comparable protection. Further, as noted, a requirement to investigate ways to supplement the USAF's mitigation measures with the use of real-time PAM devices has been included in these regulations. Monitoring reports under the LOA effective from 2018 through 2021 have not recorded take of any marine mammals. Only bottlenose dolphins have been observed and there have not been sightings of whales of any species. Based on the information above, NMFS has determined that the mandated mitigation and monitoring measures required for SINKEX activities in the EGTTR effect the least practicable adverse impact on the affected species and their habitat. Therefore, NMFS is not adopting the Commission's recommendation that the USAF measures be changed to mirror the Navy's protocols.
Further, if one assumes that each of the 6 annual exposures is incurred by a different whale, these authorized takes affect 11.8 percent (6/51) of the population during any given year. Importantly, each of those instances of take represents exposure within 1 day of the year. This represents low magnitude, short duration impacts to a relatively small portion of the total population.
No Air Force vessels have ever struck a whale in the EGTTR. Given the required vessel strike avoidance measures, the infrequency of vessel strikes more broadly, and the comparatively low numbers of vessels used in EGTTR activities, the potential for strike by a USAF vessel of any marine mammal is considered so low as to be discountable, and this is especially true for the Rice's whale, given their low density. NMFS does not anticipate, and has not authorized, vessel strike of Rice's whales or any other marine mammal.
After being deposited on the seafloor, debris items may become partially or entirely buried in sediments over time, depending on the item's size, shape, and density, and environmental factors such as sediment characteristics, water depth, and the occurrence of strong storms that may move sediments. Munitions that become buried deep in sediments may experience less corrosion because of low oxygen levels and may remain intact for longer periods of time. Inert munitions and UXO that settle on the seafloor would displace the habitat provided by the affected sediments to benthic epifauna and infauna but, like other sunken artificial structures, would also provide substrate that could be used as habitat by marine organisms. The
The MMPA requires that NMFS include marine mammal monitoring and reporting measures that will result in increased knowledge of the species and of the level of taking or impacts on populations of marine mammals that are expected to be present while conducting the activities. Monitoring for EGTTR activities is described in the Monitoring section and requires PSOs to provide description of observed behaviors (in both the presence and absence of test activities), which will help us better understand the impacts of EGTTR activities on marine mammals. There are no MMPA requirements regarding wide-spread environmental or ecological monitoring beyond what has just been described. Long-term environmental monitoring and additional cleanup initiatives are beyond the scope of this action.
The designation of critical habitat for an ESA-listed species, in this case the Rice's whale, is a separate action and not a prerequisite to fulfilling our statutory mandate under section 101(a)(5)(A) of the MMPA.
This final rule includes no substantive changes from the proposed rule. Minor typographical errors were included in several tables in the proposed rule (
The preamble text in the Pre-Mission Surveys section and § 218.64(a)(1)(iii) in the proposed rule stated that “For all live missions except gunnery missions, USAF PSOs must monitor the mitigation zones as defined in Table 2 for the given mission-day category for a minimum of 30 minutes or until the entirety of the mitigation zone has been surveyed, whichever comes first.” This has been revised in the final rule to read “. . . for a minimum of 30 minutes or until the entirety of the mitigation zone has been surveyed, whichever takes longer.” NMFS and the USAF believe that this revision ensures that the entirety of all of the mitigation zones will be monitored. NMFS revised the language in the preamble pertaining to behavioral harassment thresholds for single detonations as explained in the response to Comment 1. Finally, NMFS will require the USAF to conduct two passive acoustic monitoring (PAM) studies, pending approval of funding. These studies are described in the response to comment 4 and have been included in the regulatory text in a new paragraph (f) on acoustic monitoring within § 218.65, entitled “Requirements for monitoring and reporting”.
Marine mammal species and their associated stocks that have the potential to occur in the project are presented in Table 18. The USAF anticipates the take of individuals of three marine mammal species by Level B harassment and two of those species by Level A harassment. The USAF does not request authorization for any serious injuries or mortalities of marine mammals, and NMFS agrees that serious injury and mortality is unlikely to occur from the USAF's activities.
The proposed rule included additional information about the species in this rule, all of which remains valid and applicable but has not been reprinted in this final rule, including a subsection entitled
Information on the status, distribution, abundance, population trends, habitat, and ecology of marine mammals in the EGTTR may be found in Chapter 4 of the USAF's rulemaking/LOA application. NMFS reviewed this information and found it to be accurate and complete. All stocks managed under the MMPA in this region are assessed in NMFS' 2021 U.S. Atlantic and Gulf of Mexico Marine Mammal Stock Assessment (Hayes
Below, we include additional information about the marine mammals in the area of the specified activities that informs our analysis, such as identifying known areas of important habitat or behaviors, or where Unusual Mortality Events (UME) have been designated.
The Gulf of Mexico Bryde's whale was listed as endangered throughout its entire range on April 15, 2019, under the Endangered Species Act (ESA). Based on genetic analyses and new morphological information NOAA Fisheries recently revised the common and scientific names to recognize this new species (
The Rice's whale is the only year-round resident baleen whale species in the Gulf of Mexico. Rosel
Biologically Important Areas (BIAs) include areas of known importance for reproduction, feeding, or migration, or areas where small and resident populations are known to occur (Van Parijs, 2015). Unlike ESA critical habitat, these areas are not formally designated pursuant to any statute or law but are a compilation of the best available science intended to inform impact and mitigation analyses. In 2015, a year round small and resident population BIA for Bryde's whales (later designated as Rice's whales) was identified from the De Soto Canyon along the shelf break to the southeast (LaBrecque
An UME is defined under section 410(6) of the MMPA as a stranding that is unexpected; it involves a significant die-off of any marine mammal population and demands immediate response. There are currently no UMEs with ongoing investigations in the EGTTR. There was a UME for bottlenose dolphins that was active beginning in February 2019 and closing in November of the same year that included the northern Gulf of Mexico. Dolphins developed lesions that were thought to be caused by exposure to low salinity water stemming from extreme freshwater discharge. This UME is closed.
We provided a detailed discussion of the potential effects of the specified activities on marine mammals and their habitat in our
Having considered the new information, along with information
This section indicates the number of takes that NMFS is proposing to authorize, which is based on the maximum amount that is reasonably likely to occur, depending on the type of take and the methods used to estimate it, as described in detail below. NMFS agrees that the methods the USAF has put forth described herein to estimate take (including the model, thresholds, and density estimates), and the resulting numbers estimated for authorization, are appropriate and based on the best available science.
All takes are by harassment. For a military readiness activity, the MMPA defines “harassment” as (i) Any act that injures or has the significant potential to injure a marine mammal or marine mammal stock in the wild (Level A harassment); or (ii) Any act that disturbs or is likely to disturb a marine mammal or marine mammal stock in the wild by causing disruption of natural behavioral patterns, including, but not limited to, migration, surfacing, nursing, breeding, feeding, or sheltering, to a point where such behavioral patterns are abandoned or significantly altered (Level B harassment). No serious injury or mortality of marine mammals is expected to occur.
Authorized takes would primarily be in the form of Level B harassment, as use of the explosive sources may result, either directly or as result of TTS, in the disruption of natural behavioral patterns to a point where they are abandoned or significantly altered (as defined specifically at the beginning of this section, but referred to generally as behavioral disruption). There is also the potential for Level A harassment, in the form of auditory injury to result from exposure to the sound sources utilized in training and testing activities. As described in this Estimated Take of Marine Mammals section, no non-auditory injury is anticipated or authorized, nor is any serious injury or mortality.
Generally speaking, for acoustic impacts NMFS estimates the amount and type of harassment by considering: (1) acoustic thresholds above which NMFS believes the best available science indicates marine mammals will be taken by Level B harassment or incur some degree of temporary or permanent hearing impairment; (2) the area or volume of water that will be ensonified above these levels in a day or event; (3) the density or occurrence of marine mammals within these ensonified areas; and (4) the number of days of activities or events. This analysis of the potential impacts of the planned activities on marine mammals was conducted by using the spatial density models developed by NOAA's Southeast Fisheries Science Center for the species in the Gulf of Mexico (NOAA 2022). The density model integrated visual observations from aerial and shipboard surveys conducted in the Gulf of Mexico from 2003 to 2019.
The munitions planned to be used by each military unit were grouped into mission-day categories so the acoustic impact analysis could be based on the total number of detonations conducted during a given mission to account for the accumulated energy from multiple detonations over a 24-hour period. A total of 19 mission-day categories were developed for the munitions planned to be used. Using the dBSea underwater acoustic model and associated analyses, the threshold distances associated with Level A harassment (PTS) and Level B (TTS and behavioral) harassment zones were estimated for each mission-day category for each marine mammal species. Takes were estimated based on the area of the harassment zones, predicted animal density, and annual number of events for each mission-day category. To assess the potential impacts of inert munitions on marine mammals, the planned inert munitions were categorized into four classes based on their impact energies, and the threshold distances for each class were modeled and calculated as described for the mission-day categories.
Using the best available science, NMFS has established acoustic thresholds that identify the most appropriate received level of underwater sound above which marine mammals exposed to these sound sources could be reasonably expected to directly experience a disruption in behavior patterns to a point where they are abandoned or significantly altered, to incur TTS (equated to Level B harassment), or to incur PTS of some degree (equated to Level A harassment). Thresholds have also been developed to identify the pressure levels above which animals may incur non-auditory injury from exposure to pressure waves from explosive detonation. Refer to the Criteria and Thresholds for U.S. Navy Acoustic and Explosive Effects Analysis (Phase III) report (U.S. Department of the Navy 2017c) for detailed information on how the criteria and thresholds were derived.
NMFS' Acoustic Technical Guidance (NMFS 2018) identifies dual criteria to assess auditory injury (Level A harassment) to five different marine mammal groups (based on hearing sensitivity) as a result of exposure to noise from two different types of sources (impulsive or non-impulsive). The Acoustic Technical Guidance also identifies criteria to predict TTS, which is not considered injury and falls into the Level B harassment category. The USAF's planned activity only includes the use of impulsive (explosives) sources. These thresholds (Table 19) were developed by compiling and synthesizing the best available science and soliciting input multiple times from both the public and peer reviewers. The references, analysis, and methodology used in the development of the thresholds are described in Acoustic Technical Guidance, which may be accessed at:
Additionally, based on the best available science, NMFS uses the acoustic and pressure thresholds indicated in Table 19 to predict the onset of TTS, PTS, tissue damage, and mortality for explosives (impulsive) and other impulsive sound sources.
Refer to the Criteria and Thresholds for U.S. Navy Acoustic and Explosive Effects Analysis (Phase III) report (U.S. Department of the Navy, 2017c) for detailed information on how the criteria and thresholds were derived. Non-auditory injury (
Though significantly driven by received level, the onset of Level B harassment by direct behavioral disturbance from anthropogenic noise exposure is also informed to varying degrees by other factors related to the source (
The USAF's Acoustic Effects Model calculates sound energy propagation from explosives during USAF activities in the EGTTR. The net explosive weight (NEW) of a munition at impact can be directly correlated with the energy in the impulsive pressure wave generated by the warhead detonation. The NEWs of munitions addressed as part of this final rule range from 0.1 lb (0.04 kg) for small projectiles to 945 lb (428.5kg) for the largest bombs. The explosive materials used in these munitions also vary considerably with different formulations used to produce different intended effects. The primary detonation metrics directly considered and used for modeling analysis are the peak impulse pressure and duration of the impulse. An integration of the pressure of an impulse over the duration (time) of an impulse provides a measure of the energy in an impulse. Some of the NEWs of certain types of munitions, such as missiles, are associated with the propellant used for the flight of the munition. This propellant NEW is unrelated to the NEW of the warhead, which is the primary source of explosive energy in most munitions. The propellant of a missile fuels the flight phase and is mostly consumed prior to impact. Missile propellant typically has a lower flame speed than warhead explosives and is relatively insensitive to detonation from impacts but burns readily. A warhead detonation provides a high-pressure, high-velocity flame front that may cause burning propellant to detonate; therefore, this analysis assumes that the unconsumed residual propellant that remains at impact contributes to the detonation-induced pressure impulse in the water. The impact analysis assumes that 20 percent of the propellant remains unconsumed in missiles at impact; this assumption is based on input from user groups and is considered a reasonable estimate for the purpose of analysis. The NEW associated with this unconsumed propellant is added to the NEW of the warhead to derive the total energy released by the detonation. Absent a warhead detonation, it is assumed that continued burning or deflagration of unconsumed residual propellant does not contribute to the pressure impulse
In addition to the energy associated with the detonation, energy is also released by the physical impact of the munition with the water. This kinetic energy has been calculated and incorporated into the estimations of munitions energy for both live and inert munitions in this final rule. The kinetic energy of the munition at impact is calculated as one half of the munition mass times the square of the munition velocity. The initial impact event contributing to the pressure impulse in water is assumed to be 1 millisecond in duration. To calculate the velocity (and kinetic energy) immediately after impact, the deceleration contributing to the pressure impulse in the water is assumed for all munitions to be 1,500 g-forces, or 48,300 feet per square second over 1 millisecond. A substantial portion of the change in kinetic energy at impact is dissipated as a pressure impulse in the water, with the remainder being dissipated through structural deformation of the munition, heat, displacement of water, and other smaller energy categories. Even with 1,500 g-forces of deceleration, the change in velocity over this short time period is small and is proportional to the impact velocity and munition mass. The impact energy is the portion of the kinetic energy at impact that is transmitted as an underwater pressure impulse, expressed in units of trinitrotoluene-equivalent (TNTeq). The impact energies of the planned live munitions were calculated and included in their total energy estimations. The impact energies of the inert munitions planned to be used were also calculated. To assess the potential impacts of inert munitions on marine animals, the inert munitions were categorized based on their impact energies into the following four classes of 2 lb (0.9 kg), 1 lb (0.45 kg), 0.5 lb (0.22 kg), and 0.15 lb (0.07 kg) TNTeq; these values correspond closely to the actual or average impact energy values of the munitions and are rounded for the purpose of analysis. The 2 lb class represents the largest inert bomb, whereas the 1 lb class represents the largest inert missile. The inert missile has greater mass but lower impact energy than the bomb; this is because the bomb's lower velocity at impact and associated change in velocity over the deceleration period, which contributes to the pressure impulse. The 0.5 lb and 0.15 lb impact energy classes each represent the approximate average impact energy of multiple munitions, with the 0.5 lb class representing munitions with mid-level energies, and the 0.15 lb class representing munitions with the lowest energies (Table 21).
The NEW associated with the physical impact of each munition and the unconsumed propellant in certain munitions is added to the NEW of the warhead to derive the NEW at impact (NEWi) for each live munition. The NEWi of each munition was then used to calculate the peak pressure and pressure decay for each munition. This results in a more accurate estimate of the actual energy released by each detonation. Extensive research since the 1940s has shown that each explosive formulation produces unique correlations to explosive performance metrics. The peak pressure and pressure decay constant depend on the NEW, explosive formulation, and distance from the detonation. The peak pressure and duration of the impulse for each munition can be calculated empirically using similitude equations, with constants used in these equations determined from experimental data (Naval Surface Warfare Center (NSWC) 2017). The explosive-specific similitude constants and munition-specific NEWi were used for calculating the peak pressure and pressure decay for each munition analyzed. It should be noted that this analysis assumes that all detonations occur in the water and none of the detonations occur above the water surface when a munition impacts a target. This exceptionally conservative assumption implies that all munition energy is imparted to the water rather than the intended targets. See Appendix A in the LOA application for detailed explanations of similitude equations.
The following standard metrics are used to assess underwater pressure and impulsive noise impacts on marine animals:
• SPL: The SPL for a given munition can be explicitly calculated at a radial distance using the similitude equations.
•
•
The munition-specific peak pressure and pressure decay at various radii were used to determine the species-specific distance to effect threshold for mortality, non-auditory injury, peak pressure-induced permanent threshold shift (PTS) in hearing and peak pressure-induced temporary threshold shift (TTS) in hearing for each species. The munition-specific peak pressures and decays for all munitions in each mission-day category were used as a time-series input in the dBSea underwater acoustic model to determine the distance to effect for cumulative SEL-based (24-hour) PTS, TTS, and behavioral effects for each species for each mission day.
The dBSea model was conducted using a constant sound speed profile (SSP) of 1500 m/s to be both representative of local conditions and to prevent thermocline induced refractions from distorting the analysis results. Salinity was assumed to be 35 parts per thousand (ppt) and pH was 8. The water surface was treated as smooth (no waves) to conservatively eliminate diffraction induced attenuation of sound. Currents and tidal flow were treated as zero. Energy expended on the target and/or on ejecting water or transfer into air was ignored and all
The harassment zone is the area or volume of ocean in which marine animals could be exposed to various pressure and impulsive noise levels generated by a surface or subsurface detonation that would result in mortality; non-auditory injury and PTS (Level A harassment impacts); and TTS and behavioral impacts (Level B harassment impacts). The harassment zones for the planned detonations were estimated using Version 2.3 of the dBSea model for cumulative SEL and using explicit similitude equations for SPL and positive impulse. The characteristics of the impulse noise at the source were calculated based on munition-specific data including munition mass at impact, munition velocity at impact, NEW of warheads, explosive-specific similitude data, and propellant data for missiles. Table 22 presents the source-level SPLs (at r = 1 meter) calculated for the planned munitions.
For SEL analysis, the dBSea model was used with the ray-tracing option for calculating the underwater transmission of impulsive noise sources represented in a time series (1,000,000 samples per second) as calculated using similitude equations (r = 1 meter) for each munition for each mission day. All surface detonations are assumed to occur at a depth of 1 m, and all subsurface detonations, which would include largest bombs and subsurface mines, are assumed to occur at a depth of 3 m. The model used bathymetry for LIA with detonations occurring at the center of the LIA with a water depth of 70 m. The seafloor of the LIA is generally sandy, so sandy bottom characteristics for reflectivity and attenuation were used in the dBSea model, as previously described. The model was used to calculate impulsive acoustic noise transmission on one-third octaves from 31.5 hertz to 32 kilohertz. Maximum SELs from all depths projected to the surface were used for the analyses.
The cumulative SEL is based on multiple parameters including the acoustic characteristics of the detonation and sound propagation loss in the marine environment, which is influenced by a number of environmental factors including water depth and seafloor properties. Based on integration of these parameters, the dBSea model predicts the distances at which each marine animal species is estimated to experience SELs associated with the onset of PTS, TTS, and behavioral disturbance. As noted previously, thresholds for the onset of TTS and PTS used in the model and pressure calculations are based on those presented in Criteria and Thresholds for U.S. Navy Acoustic and Explosive Effects Analysis (Phase III) (Department of the Navy (DoN) 2017) for cetaceans with mid- to high-frequency hearing (dolphins) and low-frequency hearing (Rice's whale). Behavioral thresholds are set 5 dB below the SEL-based TTS threshold. Table 23 shows calculated SPLs and SELs for the designated mission-day categories.
The munitions planned to be used by each military unit were grouped into mission-day categories so the acoustic impact analysis could be based on the total number of detonations conducted during a given mission instead of each individual detonation. This analysis was done to account for the accumulated energy from multiple detonations over a 24-hour period.
The estimated number of mission days assigned to each category was based on historical numbers and projections provided by certain user groups. Although the mission-day categories may not represent the exact manner in which munitions would be used, they provide a conservative range of mission scenarios to account for accumulated energy from multiple detonations. It is important to note that only acoustic energy metrics (SEL) are affected by the accumulation of energy over a 24-hour period. Pressure metrics (
Note that the types of munitions that would be used for SINKEX testing are controlled information and, therefore, not identified in this LOA Request. For the purpose of analysis, SINKEX exercises are assigned to mission-day category J, which represents a single subsurface detonation of 945 lb NEW. SINKEX exercises would not exceed this NEW. The 2 annual SINKEX exercises are added to the other 8 annual missions involving subsurface detonations of these bombs, resulting in 10 total annual missions under mission-day category J.
As indicated in Table 24, a total of 19 mission-day categories (A through S) were developed as a part of this LOA application. The table also contains information on the number of munitions per day, number of mission days per year, annual quantity of munitions and the NEWi per mission day.
Densities of the common bottlenose dolphin, Atlantic spotted dolphin, and Rice's whale in the study area are based on habitat-based density models and spatial density models developed by the NOAA Southeast Fisheries Science Center for the species in the Gulf of Mexico (NOAA 2022). The density models, herein referred to as the NOAA model, integrated visual observations from aerial and shipboard surveys conducted in the Gulf of Mexico from 2003 to 2019.
The NOAA model was used to predict the average density of the common bottlenose dolphin and Atlantic spotted dolphin in the existing LIA and planned East LIA. The model generates densities for hexagon-shaped raster grids that are 40 square kilometers (km
The NOAA model was used to determine Rice's whale density in the exposure analysis conducted for the Rice's whale in this LOA Request. Areas of Rice's whale exposure to pressure and impulsive noise from munitions use, predicted by underwater acoustic modeling and quantified by GIS analysis, were coupled with the associated modeled grid densities from the NOAA model to estimate abundance of affected animals.
The distances from the live ammunition detonation point that correspond to the various effect thresholds described previously are referred to as threshold distances. The threshold distances were calculated using dBSea for each mission-day category for each marine mammal species. The model was run assuming that the detonation point is at the center
The threshold distances were used to calculate the harassment zones for each effect threshold for each species. The thresholds resemble concentric circles, with the most severe (mortality) being closest to the center (detonation point) and the least severe (behavioral disturbance) being farthest from the center. The areas encompassed by the concentric thresholds are the impact areas associated with the applicable criteria. To prevent double counting of animals, areas associated with higher-impact criteria were subtracted from areas associated with lower-impact criteria. To estimate the number of animals potentially exposed to the various thresholds within the harassment zone, the adjusted impact area was multiplied by the predicted animal density and the annual number of events for each mission-day category. The results were rounded at the annual mission-day level and then summed for each criterion to estimate the total annual take numbers for each species. For impulse and SPL metrics, a take is considered to occur if the received level is equal to or above the associated threshold. For SEL metrics, a take is considered to occur if the received level is equal to or above the associated threshold within the appropriate frequency band of the sound received, adjusted for the appropriate weighting function value of that frequency band. For impact categories with multiple criteria (
As discussed previously and shown in Table 21, a portion of the kinetic energy released by an inert munition at impact is transmitted as underwater acoustic energy in a pressure impulse. The planned inert munitions were categorized into four classes based on their impact energies to assess the potential impacts of inert munitions on marine mammals. The threshold distances for each class were modeled and calculated as described for the mission-day categories. Table 29 presents the impact energy classes developed for the inert munitions. The four impact energy classes represent the entire suite of inert munitions planned to be used in the EGTTR during the next mission period. The impact energy is the portion of the kinetic energy at impact that is transmitted as an underwater pressure impulse, expressed in units of TNT-equivalent (TNTeq). Tables 29 and 30 present the threshold distances estimated for the dolphins and Rice's whale, respectively, for inert munitions in the existing LIA.
Estimated takes for dolphins are based on the area of the Level A and Level B harassment zones, predicted dolphin density, and annual number of events for each mission-day category. As previously discussed, take estimates for dolphins are based on the average yearly density of each dolphin species in each LIA. To estimate the takes of each dolphin species in both LIAs collectively, the take estimates for each LIA were weighted based on the expected usage of each LIA over the 7-year mission period. This information was provided by the user groups. Ninety percent of the total missions are expected to be conducted in the existing LIA and 10 percent are expected to be conducted in the East LIA. Therefore, total estimated takes are the sum of 90 percent of the takes in the existing LIA and 10 percent of the takes in the East LIA. Should the usage ratio change substantially in the future, USAF would re-evaluate the exposure estimates and reinitiate consultation with NMFS to determine whether the take estimations need to be adjusted.
The annual exposures of dolphins requested by the USAF and authorized by NMFS are presented in Table 31. As indicated, a total of 9 Level A harassment takes and 1,136 Level B harassment takes of the common bottlenose dolphin, and 1 Level A harassment takes and 139 Level B harassment takes of the Atlantic spotted dolphin are requested annually for EGTTR operations during the next 7-year mission period. The presented takes are overestimates of actual exposure based on the conservative assumption that all planned detonations would occur at or just below the water surface instead of a portion occurring upon impact with targets.
Based on the best available science, the USAF (in coordination with NMFS) used the acoustic and pressure thresholds indicated in Tables 25-29 to predict the onset of tissue damage and mortality for explosives (impulsive) and other impulsive sound sources for inert and live munitions in both the existing LIA and East LIA. The mortality takes calculated for the bottlenose dolphin (0.75) and Atlantic spotted dolphin (0.14) are both less than one animal. Mortality for Rice's whale is zero. Therefore, and in consideration of the required mitigation measures, no mortality takes are requested for either dolphin species or Rice's whale. The non-auditory injury takes are calculated to be 2.18 and 0.40 for the bottlenose dolphin and Atlantic spotted dolphin, respectively. However, these (and the take estimates for the other effect thresholds) are the sum of the respective takes for all 19 mission-day categories. Each individual mission-day category results in a fraction of a non-auditory injury take. Given the required mitigation, adding up all the fractional takes in this manner would likely result in an over-estimate of take. Calculated non-auditory injury for the Rice's whale is zero.
The mitigation measures associated with explosives are expected to be effective in preventing mortality and non-auditory tissue damage to any potentially affected species. All of the calculated distances to mortality or non-auditory injury thresholds are less than 400 m. The USAF would be required to employ trained PSOs to monitor the mitigation zones based on the mission-day activities. The mitigation zone is defined as double the threshold distance at which Level A harassment exposures in the form of PTS could occur (also referred to below as “double the Level A PTS threshold distance”). During pre-monitoring PSOs would be required to postpone or cancel operations if animals are found in these zones. Protected species monitoring would be vessel-based, aerial-based or remote video-based depending on the mission-day activities. The USAF would also be required to conduct testing and training exercises beyond setback distances shown in Table 32. These setback distances would start from the 100-m isobath, which is approximately the shallowest depth where the Rice's whale has been observed. The setback distances are based on the PTS threshold calculated for the Rice's whale depending on the mission-day activity. Also, all gunnery missions must take place 500 m landward of the 100-m isopleth to avoid impacts to the Rice's whale. When these mitigation measures are considered in combination with the modeled exposure results, no species are anticipated to incur mortality or non-auditory tissue damage during the period of this rule.
Based on the conservative assumptions applied to the impact analysis and the pre-mission surveys conducted for dolphins, which extend out to, at a minimum, twice the PTS threshold distance that applies to both dolphin species (185 dB SEL), NMFS has determined that no mortality or non-auditory injury takes are expected and none are authorized for EGTTR operations.
Figure 6-2 in the LOA application shows the estimated Rice's whale threshold distances and associated harassment zones for mission-day category A, J, and P and use of a 2 lb class inert munition at the location where the GRATV is typically anchored in the existing LIA. As indicated on Figure 6-2, portions of the behavioral harassment zone of mission-day categories A and J extend into Rice's whale habitat, whereas the monitoring zones for mission-day category P and the largest inert munition are entirely outside Rice's whale habitat. The monitoring zone is defined as the area between double the Level A harassment mitigation zone and the human safety zone perimeter. As previously discussed, the spatial density model developed by NOAA (2022) for the Rice's whale was used to predict Rice's whale density for the purpose of estimating takes. The NOAA model generates densities for hexagon-shaped raster grids that are 40 km
Figure 6-3 in the LOA application shows the harassment zones of mission-day category A at the current GRATV anchoring site. As shown, portions of the mitigation zones (TTS and behavioral disturbance) are within grids of modeled density greater than zero individuals per 40 km
Certain missions could have a PTS impact if they were to be conducted farther to the southwest within the LIAs closer to Rice's whale habitat, as defined by the 100-m isobath. The modeled threshold distances were used to determine the locations in the existing LIA and East LIA where each mission-day category would cause the onset of PTS, measured as a setback from the 100-m isobath. At this setback location, the mission would avoid PTS and result only in non-injury Level B harassment, if one or more Rice's whales were in the affected habitat. The setback distances are based on the longest distance predicted by the dBSea model for a cumulative SEL of 168 dB within the mitigation zone; the predicted average cumulative SEL is used as the basis of effect for estimating takes. The setback distances determined for the mission-day categories are presented in Table 32 and are shown for the existing LIA and East LIA on Figures 6-5 and 6-6, respectively.
Locating a given mission in the LIA at its respective setback distance would represent the maximum Level B harassment scenario for the mission. If all the missions were conducted at their respective setbacks, the resulting takes would represent the maximum Level B harassment takes that would result for all mission-day categories except for gunnery missions. This is not a realistic scenario; however, it is analyzed to provide a worst-case estimate of takes. The takes under this scenario were calculated using the NOAA model (2022) model as described for the GRATV Location scenario. Figure 6-7 shows mission-day category A conducted at its maximum Level B harassment setback location (7.23 km). Under this scenario, the TTS and behavioral disturbance mitigation zones extend farther into Rice's whale habitat. However, the modeled densities within affected areas are still relatively small. PTS impacts are avoided entirely. The PTS mitigation zone is slightly offset from the 100-m isobath because the setback is based on the longest distance predicted by the dBSea model, whereas the mitigation zones shown are based on the average distance predicted by the model. The take calculations for the maximum Level B harassment scenario resulted in a total of 0.49 annual TTS takes and 1.19 annual behavioral disturbance takes as shown in Table 33. These are the maximum number of takes estimated to potentially result from detonations in the existing LIA. These takes are overestimates because a considerable portion of all missions in the LIA are expected to continue to be conducted at or near the currently used GRATV anchoring site. These takes would not be exceeded because all missions will be conducted behind their identified setbacks as a new mitigation measure to prevent injury to the Rice's whale. Take calculations for the maximum Level B harassment scenario in the East LIA resulted in 0.63 annual TTS takes and 2.33 annual behavioral disturbance takes (Table 33). However, if we assume that 90 percent of the mission would occur in existing LIA and 10 percent would occur in the East LIA as was done for dolphins, the estimated result is 0.55 annual TTS (0.49 + 0.06) and 1.42 annual behavioral (1.19 + 0.23) takes.
The take calculations were performed using the NOAA (2022) density model for both day and night gunnery missions. As indicated on Figures 6-8 and 6-9 in the application, the modeled Rice's whale densities in the TTS and behavioral disturbance zones are small, and reflect a higher occurrence probability for the Rice's whale farther to the southwest. The take calculations estimated 0.003 TTS takes and 0.012 behavioral disturbance takes per daytime gunnery mission and 0.0006 TTS takes and 0.002 behavioral disturbance takes per nighttime gunnery mission. The resulting annual takes for all planned 25 daytime gunnery missions are 0.08 TTS take and 0.30 behavioral disturbance take, and the resulting annual takes for all 45 planned nighttime gunnery missions are 0.03 TTS take and 0.09 behavioral disturbance take (Table 33). This is a conservative estimation of Level B harassment takes because all gunnery missions would not be conducted precisely 500 m landward of the 100-m isobath as assumed under this worst-case take scenario. This represents a mitigation measure described later in the Mitigation Measures section. Based on a review of gunnery mission locations, most gunnery missions during
The annual maximum Level B harassment takes estimated for daytime gunnery missions (mission-day G) and nighttime gunnery missions (mission-day category H) are combined with the annual maximum Level B harassment takes estimated for the other mission-day categories to determine the total takes of the Rice's whale from all EGTTR operations during the next mission period. The annual takes of the Rice's whale requested under the USAF's planned activities are 0.61 TTS takes conservatively and 1.69 behavioral takes as presented in Table 33. However, the average group size for Bryde's whales found in the northeast Gulf of Mexico is two animals (Maze-Foley and Mullin 2006). NMFS will assume that each exposure would result in take of two animals. Therefore, NMFS is authorizing Level B harassment in the form of two takes by TTS and four takes by behavioral disturbance annually for EGTTR operations during the next 7-year mission period.
Note that the authorized takes are likely overestimates because they represent the maximum Level B harassment scenario for all missions. These takes are also likely overestimates of actual exposure based on the conservative assumption that all planned detonations would occur at or just below the water surface instead of a portion occurring upon impact with targets.
For the USAF's planned activities in the EGTTR, Table 34 summarizes the take NMFS plans to authorize, including the maximum annual, 7-year total amount, and type of Level A harassment and Level B harassment that NMFS anticipates is reasonably likely to occur by species and stock. Note that take by Level B harassment includes both behavioral disturbance and TTS. No mortality or non-auditory injury is anticipated or authorized, as described previously.
Under section 101(a)(5)(A) of the MMPA, NMFS must set forth the permissible methods of taking pursuant to the activity, and other means of effecting the least practicable adverse impact on the species or stocks and their habitat, paying particular attention to rookeries, mating grounds, and areas of similar significance, and on the availability of the species or stocks for subsistence uses (latter not applicable for this action). NMFS regulations require applicants for incidental take authorizations to include information about the availability and feasibility (economic and technological) of equipment, methods, and manner of conducting the activity or other means of effecting the least practicable adverse impact upon the affected species or stocks, and their habitat (50 CFR 216.104(a)(11)). The NDAA for fiscal year (FY) 2004 amended the MMPA as it relates to military readiness activities and the incidental take authorization process such that “least practicable impact” shall include consideration of personnel safety, practicality of implementation, and impact on the effectiveness of the military readiness activity.
In evaluating how mitigation may or may not be appropriate to ensure the least practicable adverse impact on species or stocks and their habitat, as well as subsistence uses where applicable, NMFS considers two primary factors:
(1) The manner in which, and the degree to which, the successful implementation of the measure(s) is expected to reduce impacts to marine mammals, marine mammal species or stocks, and their habitat. This considers the nature of the potential adverse impact being mitigated (likelihood, scope, range). It further considers the likelihood that the measure will be effective if implemented (probability of accomplishing the mitigating result if implemented as planned), the likelihood of effective implementation (probability implemented as planned), and
(2) The practicability of the measures for applicant implementation, which may consider such things as cost, impact on operations, and, in the case of a military readiness activity, personnel safety, practicality of implementation, and impact on the effectiveness of the military readiness activity.
Section 216.104(a)(11) of NMFS' implementing regulations requires an applicant for incidental take authorization to include in its request, among other things, “the availability and feasibility (economic and technological) of equipment, methods, and manner of conducting such activity or other means of effecting the least practicable adverse impact upon the affected species or stocks, their habitat, and [where applicable] on their availability for subsistence uses, paying particular attention to rookeries, mating grounds, and areas of similar significance.” Thus, NMFS' analysis of the sufficiency and appropriateness of an applicant's measures under the least practicable adverse impact standard will always begin with evaluation of the mitigation measures presented in the application.
NMFS has fully reviewed the specified activities and the mitigation measures included in the USAF's rulemaking/LOA application and the EGTTR 2022 REA to determine if the mitigation measures would result in the least practicable adverse impact on marine mammals and their habitat. The USAF would be required to implement the mitigation measures identified in this rule for the full 7 years to avoid or reduce potential impacts from planned training and testing activities.
Monitoring and mitigation measures for protected species are implemented for all EGTTR missions that involve the use of live or inert munitions (
Pre-mission surveys for protected species are conducted prior to every mission (
The monitoring zone for non-gunnery missions is the area between the mitigation zone and the human safety zone and is not standardized, since the size of the human safety zone is not standardized. The human safety zone will be determined per each mission by the Eglin AFB Test Wing Safety Office based on the munition and parameters of its release (to include altitude, pitch, heading, and airspeed). Additionally, based on the operational altitudes of gunnery firing, and the fact that the only monitoring during the mission will be coming from onboard the aircraft conducting the live firing, the monitoring zone for gunnery missions
For non-gunnery inert missions, the mitigation zone is based on double the Level A harassment (PTS) threshold distance as shown in Table 36. The monitoring zone is the area between the mitigation zone and the human safety zone which is not standardized. The safety zone is determined per each mission by the Test Wing Safety Office based on the munition and parameters of its release including altitude, pitch, heading, and airspeed.
Mission postponement, relocation, or cancellation—Mission postponement, relocation, or cancellation would be required when marine mammals are observed within the mitigation or monitoring zone depending on the mission type to minimize the potential for marine mammals to be exposed to injurious levels of pressure and noise energy from live detonations. If one or more marine mammal species other than the two dolphin species for which take is authorized are detected in either the mitigation zone or the monitoring zone, then mission activities will be cancelled for the remainder of the day. The mission must be postponed, relocated or canceled if either of the two dolphin species are visually detected in the mitigation zone during the pre-mission survey. If members of the two dolphin species for which authorized take has been authorized are observed in the monitoring zone while vessels are exiting the human safety zone and the PSO has determined the animals are heading towards the mitigation zone, then missions will be postponed, relocated, or canceled, based on mission-specific test and environmental parameters. Postponement would continue until the animals are confirmed to be outside of the mitigation zone on a heading away from the targets or are not seen again for 30 minutes and are presumed to be outside the mitigation zone. If large schools of fish or large flocks of birds are observed
Vessel strike avoidance measures—Vessel strike avoidance measures as previously advised by NMFS Southeast Regional Office must be employed by the USAF to minimize the potential for ship strikes. These measures include staying at least 150 ft (46 m) away from protected species and 300 ft (92 m) away from whales. Additional action area measures will require vessels to stay 500 m away from the Rice's whale. If a baleen whale cannot be positively identified to species level then it must be assumed to be a Rice's whale and 500 m separation distance must be maintained. Vessels must avoid transit in the Core Distribution Area (CDA) and within the 100-400 m isobath zone outside the CDA. If transit in these areas is unavoidable, vessels must not exceed 10 knots and transit at night is prohibited. An exception to the speed restriction is for instances required for human safety, such as when members of the public need to be intercepted to secure the human safety zone, or when the safety of a vessel operations crew could be compromised.
New mitigation measures that were not required as part of the existing LOA have been developed to reduce impacts to the Rice's whale. These measures would require that given mission-day activities could only occur in areas that are exterior to and set back some specified distance from Rice's whale habitat boundaries as well as areas where mission activities are prohibited. These are described below.
As a mitigation measure to prevent impacts to cetacean species known to occur in deeper portions of the Gulf of Mexico, such as the federally endangered sperm whale, all gunnery missions have been located landward of the 200-m isobath, which is generally considered to be the shelf break in the Gulf of Mexico. Most missions conducted over the last 5 years under the existing LOA have occurred in waters less than 100 m in depth. While implementing this measure would prevent impacts to most marine mammal species in the Gulf, it may not provide full protection to the Rice's whale, which has been documented to occur in waters as shallow as 117 m, although the majority of sightings have occurred in waters deeper than 200 m.
To prevent any PTS impacts to the Rice's whale from gunnery operations, NMFS has mandated that all gunnery missions must be conducted at least 500 m landward of the 100-m isobath instead of landward of the 200-m isobath as was originally proposed by the USAF. This setback distance from the 100-m isobath is based on the modeled PTS threshold distance for daytime gunnery missions (mission-day G) of 494 m (Table 28). At this setback distance, potential PTS effects from daytime gunnery missions would not extend into Rice's whale habitat, as defined by the 100-m isobath. The PTS Level A harassment isopleth of a nighttime gunnery mission, which is 401 m in radius, is contained farther landward of the habitat boundary.
Another mitigation measure to prevent any PTS (or more severe) impacts to the Rice's whale will restrict the use of all live munitions in the western part of the existing LIA and East LIA based on the setbacks from the 100-m isobaths. The setback distances determined for the mission-day categories are presented in Table 32 and are shown for the existing LIA and East LIA on Figures 6-5 and 6-6, respectively. For example, the subsurface detonation of a GBU-10, GBU-24, or GBU-31, each of which have a NEW of 945 lb (428.5 kg), would represent the most powerful single detonation that would be conducted under the USAF's planned activities. Such a detonation would correspond to mission-day category J. To prevent any PTS impacts to the Rice's whale, a mission that would involve such a single subsurface detonation would be conducted in a portion of the LIA that is behind the setback identified for mission-day category J.
Likewise, a mission that would involve multiple detonations that have a total cumulative NEWi comparable to that of mission-day category A would be conducted behind the setback identified for mission-day category A. Each user group will use the mission-day categories and corresponding setback distances to determine the setback distance that is appropriate for their actual mission. The user group will estimate the NEWi of the actual mission to identify which mission-day category and associated setback to use. The energy of the actual mission must be less than the energy of the mission-day category in terms of total NEWi and largest single-munition NEWi to ensure that the energy and effects of the actual mission will not exceed the energy and effects estimated for the corresponding mission-day category.
This section identifies areas where firing of live or inert munitions is prohibited to limit impacts to Rice's whales. The USAF will prohibit the use of live or inert munitions in Rice's whale habitat during the effective period for the issued LOA. Under this new mitigation measure, all munitions use will be prohibited between the 100-m and 400-m isobaths which represents the area where most Rice's whale detections have occurred. Live munitions under mission-day category K would be permitted to be fired into the existing LIA or East LIA but must have a setback of 1.338 km from the 100-m isobath while inert munitions under mission-day category K could be fired into portions of the EGTTR outside the LIAs. However, they would need to be outside the area between the 100-m and 400-m isobaths.
Overall, the USAF has agreed to procedural mitigation measures that would reduce the probability and/or severity of impacts expected to result from acute exposure to live explosives and inert munitions and impacts to marine mammal habitat.
Additional mitigation measures are applicable only to gunnery missions. The USAF must use 105 mm Training Rounds (TR; NEW of 0.35 lb (0.16 kg)) for nighttime missions. These rounds contain less explosive material content than the 105 mm Full Up (FU; NEW of 4.7 lb (2.16 kg)) rounds that are used during the day. Therefore, the harassment zones associated with the 105 mm TR are smaller and can be more effectively monitored compared to the daytime zones. Ramp-up procedures will also be required for day and night gunnery missions which must begin firing with the smallest round and proceed to increasingly larger rounds. The purpose of this measure is to expose the marine environment to steadily increasing noise levels with the intent that marine animals will move away from the area before noise levels increase. During each gunnery training mission, gun firing can last up to 90 minutes but typically lasts approximately 30 minutes. Live firing is continuous, with pauses usually lasting well under 1 minute and rarely up to 5 minutes. Aircrews must reinitiate protected species surveys if gunnery firing pauses last longer than 10 minutes.
Protected species monitoring procedures for CV-22 gunnery training are similar to those described for AC-130 gunnery training, except that CV-22
All gunnery missions must monitor a set distance depending on the aircraft type as shown in Table 37. Pre-mission aerial surveys conducted by gunnery aircrews in AC-130s extend out 5 nmi (9,260 m) while CV-22 aircraft would have a monitoring range of 3 nmi (5,556 m). The modeled distances for behavioral disturbance for gunnery daytime and nighttime missions are 12.9 km and 7.1 km, respectively. The behavioral disturbance zone is smaller at night due to the required use of less impactful training rounds (105-mm TR). Therefore, the aircrews are able to survey all of the behavioral disturbance for a nighttime gunnery mission but not for a daytime gunnery mission. The size of the monitoring areas are based on the monitoring and operational altitudes of each aircraft as well as previously established aircraft safety profiles.
Other than gunnery training, mission-day category K tests are the only other EGTTR missions currently planned to be conducted at nighttime during the 2023-2030 period. Mission-day category K tests and any other missions that are actually conducted at nighttime during the mission period will be required to be supported by AC-130 aircraft with night-vision instrumentation or other platforms with comparable nighttime monitoring capabilities. For mission-day category K missions, the pre-mission survey area will extend out to, at a minimum, double the Level A harassment (PTS) threshold distance that applies to both dolphin species for mission-day category K test. A mission-day category K test would correspond to mission-day category K, which is estimated to have a PTS threshold distance of 0.445 km. Therefore, the pre-mission survey for a mission-day category K test would extend out to 0.89 km, at a minimum.
NMFS has carefully evaluated the USAF's planned mitigation measures, as well as other potential mitigation measures suggested during the public comment period, which are discussed in our responses to public comments. Our evaluation of potential measures included consideration of the following factors in relation to one another: the manner in which, and the degree to which, the successful implementation of the mitigation measures is expected to reduce the likelihood and/or magnitude of adverse impacts to marine mammal species and their habitat; the proven or likely efficacy of the measures; and the practicability of the measures for applicant implementation, including consideration of personnel safety, practicality of implementation, and impact on the effectiveness of the military readiness activity.
Based on our evaluation, NMFS has determined that USAF's planned measures, including pre-mission surveys; mission postponements or cancellations if animals are observed in the mitigation or monitoring zones; Rice's whale setbacks; Rice's whale habitat prohibitions; gunnery-specific measures; and environmental measures, are the appropriate means of effecting the least practicable adverse impact on
In order to issue an incidental harassment authorization (IHA) for an activity, section 101(a)(5)(A) of the MMPA states that NMFS must set forth requirements pertaining to the monitoring and reporting of such taking. The MMPA implementing regulations at 50 CFR 216.104(a)(13) indicate that requests for authorizations must include the suggested means of accomplishing the necessary monitoring and reporting that will result in increased knowledge of the species and of the level of taking or impacts on populations of marine mammals that are expected to be present while conducting the activities. Effective reporting is critical both to compliance as well as to ensuring that the most value is obtained from the required monitoring.
Monitoring and reporting requirements prescribed by NMFS should contribute to improved understanding of one or more of the following:
• Occurrence of marine mammal species or stocks in the area in which take is anticipated (
• Nature, scope, or context of likely marine mammal exposure to potential stressors/impacts (individual or cumulative, acute or chronic), through better understanding of: (1) action or environment (
• Individual marine mammal responses (behavioral or physiological) to acoustic stressors (acute, chronic, or cumulative), other stressors, or cumulative impacts from multiple stressors;
• How anticipated responses to stressors impact either: (1) long-term fitness and survival of individual marine mammals; or (2) populations, species, or stocks;
• Effects on marine mammal habitat (
• Mitigation and monitoring effectiveness.
The USAF will require training for all PSOs who will utilize vessel-based, aerial-based, video-based platforms or some combination of these approaches depending on the requirements of the mission type as shown in Table 39. Specific PSO training requirements are described below.
All personnel who conduct protected species monitoring are required to complete Eglin AFB's Marine Species Observer Training Course, which was developed in consultation with NMFS. The required PSO training covers applicable environmental laws and regulations, consequences of non-compliance, PSO roles and responsibilities, photographs and descriptions of protected species and indicators, survey methods, monitoring requirements, and reporting procedures. Any person who will serve as a PSO for a particular mission must have completed the training within a year prior to the mission. For missions that require multiple survey platforms to cover a large area, a Lead Biologist is designated to lead the monitoring and coordinate sighting information with the Eglin AFB Test Director (Test Director) or the Eglin AFB Safety Officer (Safety Officer).
Note that all three monitoring platforms described in Table 39 are not needed for all missions. The use of the platforms for a given mission are evaluated based on mission logistics, public safety, and the effectiveness of the platform to monitor for protected species. Vessel and video monitoring are almost always used but aerial monitoring may not be used for some missions because it is not needed in addition to the vessel-based surveys that are conducted. Aerial monitoring is considered to be supplemental to vessel-based monitoring and is used only when needed, for example if not enough vessels are available or to provide coverage in areas farther offshore where using vessels may be more logistically difficult. Note that at least one of the monitoring platforms described in Table 39 must be used for every mission. In most instances, two or three of the monitoring platforms will be employed.
Pre-mission surveys conducted from vessels will typically begin at sunrise. Vessel-based monitoring is required for all mission-day categories except for gunnery missions. Trained marine species PSOs will use dedicated vessels to monitor for protected marine species and potential indicators during the pre-mission surveys. For missions that require multiple vessels to cover a large survey area, a Lead Biologist will be designated to coordinate all survey efforts, compile sighting information from the other vessels, serve as the point of contact between the survey vessels and Tower Control, and provide final recommendations to the Safety Officer/Test Director on the suitability of the mission site based on environmental conditions and survey results.
Survey vessels will run predetermined line transects, or survey routes, that will provide sufficient coverage of the survey area. Monitoring will be conducted from the highest point feasible on the vessels. There will be at least two PSOs on each vessel, and they will each use professional-grade binoculars.
All sighting information from pre-mission surveys will be communicated to the Lead Biologist on a predetermined radio channel to reduce overall radio chatter and potential confusion. After compiling all the sighting information from the other survey vessels, the Lead Biologist will inform Tower Control if the survey area is clear or not clear of protected species. If the area is not clear, the Lead Biologist will provide recommendations on whether the mission should be postponed or canceled. For example, a mission postponement would be recommended if a protected species is in the mitigation zone but appears to be heading away from the mission area. The postponement would continue until the Lead Biologist has confirmed that the animals are no longer in the mitigation zone and are swimming away from the range. A mission cancellation could be recommended if one or more protected species are sighted in the mitigation zones and there is no indication that they would leave the area within a reasonable time frame. Tower Control will relay the Lead Biologist's recommendation to the Safety Officer. The Safety Officer and Test Director will collaborate regarding range conditions based on the information provided. Ultimately, the Safety Officer will have final authority on decisions regarding postponements and cancellations of missions.
Established range clearance procedures are followed during all EGTTR missions for public safety. Prior to each mission, a human safety zone appropriate for the mission is established around the target area. The size of the human safety zone varies depending on the munition type and delivery method. A composite safety zone is often developed for missions that involve multiple munition types and delivery methods. A typical composite safety zone is octagon-shaped to make it easier to monitor by range clearing boats and easier to interpret by the public when it is overlaid on maps with latitude and longitude coordinates. The perimeter of a composite safety zone may extend out to approximately 15 miles (13 nmi) from the center of the zone and may be monitored by up to 25 range-clearing boats to ensure it is free of any non-participating vessels before and during the mission.
USAF support vessels will be operated by a combination of USAF and civil service/civilian personnel responsible for mission site/target setup and range-clearing activities. For each mission, USAF personnel will be within the mission area (on boats and the GRATV) well in advance of initial munitions use, typically around sunrise. While in the mission area, they will perform a variety of tasks, such as target preparation and equipment checks, and will also observe for marine mammals and indicators when possible. Any sightings would be relayed to the Lead Biologist.
The Safety Officer, in cooperation with the CCF (Central Control Facility) and Tower Control, will coordinate and manage all range-clearing efforts and will be in direct communication with the survey vessel team, typically through the Lead Biologist. All support vessels will be in radio contact with each other and with Tower Control. The Safety Officer will monitor all radio communications, and Tower Control will relay messages between the vessels and the Safety Officer. The Safety Officer and Tower Control will also be in constant contact with the Test Director throughout the mission to convey information on range clearance and marine species surveys. Final decisions regarding mission execution, including possible mission postponement or cancellation based on marine species sightings or civilian boat traffic, will be the responsibility of the Safety Officer, with concurrence from the Test Director.
Aircraft provide an excellent viewing platform for detecting marine mammals at or near the sea surface. Depending on the mission, the aerial survey team will consist of Eglin AFB Natural Resources Office personnel or their designees aboard a non-mission aircraft or the mission aircrew who have completed the PSO training. The Eglin AFB Natural Resources Office has overall responsibility for implementing the natural resources management program and is the lead organization for monitoring compliance with applicable Federal, State, and local regulations. It reports to the installation command, the 96th Test Wing, via the Environmental Management Branch of the 96th Civil Engineer Group. All mission-day categories require aerial-based monitoring, assuming assets are available and when such monitoring does not interfere with testing and training parameters required by mission proponents. Note that gunnery mission aircraft must also serve as aerial-based monitoring platforms.
For non-mission aircraft, the pilot will be instructed on marine species survey techniques and will be familiar with the protected species expected to occur in the area. One PSO in the aircraft will record data and relay information on species sightings, including the species (if possible), location, direction of movement, and number of animals, to the Lead Biologist. The aerial team will
Some mission aircraft have the capability to conduct aerial surveys for marine species immediately prior to releasing munitions. Mission aircraft used to conduct aerial surveys will be operated at reasonable and safe altitudes appropriate for visually scanning the sea surface and/or using onboard instrumentation to detect protected species. The primary mission aircraft that conduct aerial surveys for marine species are the AC-130 gunship and CV-22 Osprey used for gunnery operations.
AC-130 gunnery training involves the use of 30 mm and 105 mm FU rounds during daytime and 30 mm and 105 mm TRs during nighttime. The TR variant (0.35 lb (0.15 kg) NEW) of the 105 mm HE round has less explosive material than the FU round (4.7 lb (2.13 kg) NEW). AC-130s are equipped with and required to use low-light electro-optical and infrared sensor systems that provide excellent night vision. Gunnery missions use the 105 mm TRs during nighttime missions as an additional mitigation measure for protected marine species. If a towed target is used, mission personnel will maintain the target in the center portion of the survey area to ensure gunnery impacts do not extend past the predetermined mitigation and monitoring zones. During the low-altitude orbits and climb, the aircrew will visually scan the sea surface for the presence of protected marine species. The visual survey will be conducted by the flight crew in the cockpit and personnel stationed in the tail observer bubble and starboard viewing window.
After arriving at the mission site and before initiating gun firing, the aircraft would be required to fly at least two complete orbits around the target area out to the applicable monitoring zone at a minimum safe airspeed and appropriate monitoring altitude. If no protected species or indicators are detected, the aircraft will then ascend to an operational altitude while continuing to orbit the target area as it climbs. The initial orbits typically last approximately 10 to 15 minutes. Monitoring for marine species and non-participating vessels continues throughout the mission. When aerial monitoring is conducted by aircraft, a minimum ceiling of 305 m (1,000 feet) and visibility of 5.6 km (3 nmi) are required for effective monitoring efforts and flight safety.
Infrared systems are equally effective during day or night. Nighttime missions would be conducted by AC-130s that have been upgraded recently with MX-25D sensor systems, which provide superior night-vision capabilities relative to earlier sensor systems. CV-22 training involves the use of only .50 caliber rounds, which do not contain explosive material and, therefore, do not detonate. Aircrews will conduct visual and instrumentation-based scans during the post-mission survey as described for the pre-mission survey.
Video-based monitoring is conducted via transmission of live, high-definition video feeds from the GRATV at the mission site to the CCF and is required on all mission-day categories except for gunnery missions. These video feeds can be used to remotely view the mission site to evaluate environmental conditions and monitor for marine species up to the time munitions are used. There are multiple sources of video that can be streamed to multiple monitors within the CCF. A PSO from Eglin Natural Resources will monitor the live video feeds transmitted to the CCF when practicable and will report any protected marine species sightings to the Safety Officer, who will also be at the CCF. Video monitoring can mitigate the lapse in time between the end of the pre-mission survey and the beginning of the mission.
Four video cameras are typically operated on the GRATV for real-time monitoring and data collection during the mission. All cameras have a zoom capability of up to at least a 300 mm equivalent. The cameras allow video PSOs to detect an item as small as 1 square foot (0.09 square m) up to 4,000 m away.
Supplemental video monitoring must be used when practicable via additional aerial assets. Aerial assets with video monitoring capabilities include Eglin AFB's aerostat balloon and unmanned aerial vehicles (UAVs). These aerial assets support certain missions, for example by providing video of munition detonations and impacts; these assets are not used during all missions. The video feeds from these aerial assets can be used to monitor protected species; however, they would always be a supplemental form of monitoring that would be used only when available and practicable. Eglin AFB's aerostat balloon provides aerial imagery of weapon impacts and instrumentation relay. When used, it is tethered to a boat anchored near the GRATV. The balloon can be deployed to an altitude of up to 2,000 ft (607 m). It is equipped with a high-definition camera system that is remotely controlled to pivot and focus on a specific target or location within the mission site. The video feed from the camera system is transmitted to the CCF. Eglin AFB may also employ other assets such as intelligence, surveillance, and reconnaissance aircraft to provide real-time imagery or relay targeting pod videos from mission aircraft. UAVs may also be employed to provide aerial video surveillance. While each of these platforms may not be available for all missions, they typically can be used in combination with each other and with the GRATV cameras to supplement overall monitoring efforts. Even with a variety of platforms potentially available to supply video feeds to the CCF, the entirety of the mitigation and monitoring zones may not be visible for the entire duration of the mission. The targets and immediate surrounding areas will typically be in the field of view of the GRATV cameras, which will allow the PSO to detect any protected species that may enter the target area before weapon releases. The cameras also allow the PSO to readily inspect the target area for any signs that animals were injured. If a protected marine species is detected on the live video, the weapon release can be stopped almost immediately because the video camera PSO is in direct contact with Test Director and Safety Officer at the CCF.
The video camera PSO will have open lines of communication with the PSOs on vessels to facilitate real-time reporting of marine species sightings and other relevant information, such as the presence of non-participating vessels near the human safety zone. Direct radio communication will be maintained between vessels, GRATV personnel, and Tower Control throughout the mission. The Safety Officer will monitor all radio communications from the CCF, and information between the Safety Officer and support vessels will be relayed via Tower Control.
During post-mission monitoring, PSOs would survey the mission site for any dead or injured marine mammals. Vessels will move into the survey area from outside the safety zone and monitor for at least 30 minutes,
All vessels will report any dead or injured marine mammals to the Lead Biologist. All marine mammal sightings during post-mission surveys are documented on report forms that are submitted to the Eglin Natural Resources Office after the mission. The post-mission survey area will be the area covered in 30 minutes of observation in a direction down-current from impact site or the actual pre-mission survey area, whichever is reached first.
For gunnery missions, aircrews must conduct post-mission surveys beginning at the operational altitude and continuing through an orbiting descent to the designated monitoring altitude. The descent will typically last approximately 3 to 5 minutes. The post-mission survey area will be the area covered in 30 minutes of observation in a direction down-current from impact site or the actual pre-mission survey area, whichever is reached first. Aircrews will conduct visual and instrumentation-based scans during the post-mission survey as described for the pre-mission survey.
As agreed upon between the USAF and NMFS, the required mitigation monitoring measures presented in the Mitigation requirements section focus on the protection and management of potentially affected marine mammals. A well-designed monitoring program can provide important feedback for validating assumptions made in analyses and allow for adaptive management of marine resources.
The USAF will conduct two NMFS-approved PAM studies, pending the availability of funding, as previously described in the response to comment 4. As a condition of the 2018-2023 regulations and associated LOA, NMFS required the USAF to: (1) conduct a PAM study as an initial step toward understanding acoustic impacts of underwater detonations, if funding was approved, and (2) conduct a follow-up PAM study to investigate marine mammal vocalizations before, during and after live missions in the EGTTR. The USAF did conduct the PAM study on underwater detonations which was the first of the two-part condition of the 2018-2023 LOA (Leidos 2020). The study determined that inert underwater detonations were generally louder than expected. As a result of these findings, the USAF included analyses of impacts of inert munitions in the LOA application and NMFS is requiring appropriate mitigation measures for inert munitions. Funding was not obtained to commence the second part of the study.
The Marine Mammal Commission recommended as part of this final rule and LOA that NMFS require the USAF to prioritize (1) completing the follow-up study to the original PAM study which is described above and (2) further investigate ways to supplement its mitigation measures with the use of real-time PAM devices (
NMFS may modify (including augment) the existing mitigation, monitoring, or reporting measures (after consulting with Eglin AFB regarding the practicability of the modifications) if doing so creates a reasonable likelihood of more effectively accomplishing the goals of the mitigation and monitoring measures for these regulations.
Possible sources of data that could contribute to the decision to modify the mitigation, monitoring, or reporting measures in an LOA include: (1) Results from Eglin AFB's acoustic monitoring study; (2) results from monitoring during previous year(s); (3) results from other marine mammal and/or sound research or studies; and (4) any information that reveals marine mammals may have been taken in a manner, extent or number not authorized by these regulations or subsequent LOAs.
If, through adaptive management, the modifications to the mitigation, monitoring, or reporting measures are substantial, NMFS will publish a notice of proposed LOA in the
Section 101(a)(5)(A) of the MMPA states that, in order to issue incidental take authorization for an activity, NMFS must set forth requirements pertaining to the monitoring and reporting of such taking. Effective reporting is critical both to compliance as well as to ensuring that the most value is obtained from the required monitoring.
A summary annual report of marine mammal observations and mission activities must be submitted to the NMFS Southeast Regional Office and the NMFS Office of Protected Resources 90 days after completion of mission activities each year. A final report shall be prepared and submitted within 30 days following resolution of comments on the draft report from NMFS. This annual report must include the following information:
• Date, time and location of each mission including mission-day category, general munition type, and specific munitions used;
• Complete description of the pre-mission and post-mission monitoring activities including type and location of monitoring platforms utilized (
• Summary of mitigation measures employed including postponements, relocations, or cancellations of mission activity;
• Number, species, and any other relevant information regarding marine mammals observed and estimated exposed/taken during activities;
• Description of the observed behaviors (in both presence and absence of test activities);
• Environmental conditions when observations were made, including visibility, air temperature, clouds, wind speed, and swell height and direction;
• Assessment of the implementation and effectiveness of mitigation and monitoring measures; and
• PSO observation results as provided through the use of PSO report forms.
A Final Comprehensive Report summarizing monitoring and mitigation activities over the 7-year LOA effective period must be submitted 90 days after the completion of mission activities at the end of year 7.
If a dead or seriously injured marine mammal is found during post-mission monitoring, the incident must be reported to the NMFS Office of Protected Resources, NMFS Southeast Region Marine Mammal Stranding Network, and the Florida Marine Mammal Stranding Network. In the unanticipated event that any cases of
1. Time and date of the incident;
2. Description of the incident;
3. Environmental conditions (
4. Species identification or description of the animal(s) involved;
5. Fate of the animal(s); and
6. Photographs or video footage of the animal(s).
Mission activities must not resume in the EGTTR until NMFS is able to review the circumstances of the prohibited take. If it is determined that the unauthorized take was caused by mission activities, NMFS will work with the USAF to determine what measures are necessary to minimize the likelihood of further prohibited take and ensure MMPA compliance. The USAF may not resume their activities until notified by NMFS.
Eglin AFB has submitted to NMFS annual reports that summarize the results of protected species surveys conducted for EGTTR missions. From 2010 to 2021, Eglin AFB conducted 67 gunnery missions in the EGTTR. To date, there has been no evidence that marine mammals have been impacted from gunnery operations conducted in the EGTTR. The use of instrumentation on the AC-130 and CV-22 in pre-mission surveys has proven effective to ensure the mission site is clear of protected species prior to gun firing. Monitoring altitudes during pre-mission surveys for both the AC-130 and CV-22 are much lower than 15,000 ft (4,572 m); therefore, the instrumentation on these aircraft would be even more effective at detecting marine species than indicated by photographs. From 2013 to 2020, Eglin AFB conducted 25 live missions collectively under 53 WEG programs in the EGTTR. From 2016-2021, Eglin AFB conducted 16 live bomb missions in the EGTTR. Protected species monitoring for these past missions was conducted using a combination of vessel-based surveys and live video monitoring from the CCF, as described. Pre-mission survey areas for 53 WEG missions were based on mission-day categories developed per NMFS's request to account for the accumulated energy from multiple detonations. Note that surveys conducted for the earlier Maritime Strike missions were based on thresholds determined for single detonations; however, these 53 WEG missions involved detonations of larger munitions. There has been no evidence of mortality, injury, or any other detectable adverse impact to any marine mammal from the 53 WEG missions conducted to date. Dolphins were sighted within the mitigation zone prior to ordnance delivery during some of these past missions. In these cases, the mission was postponed until the animals were confirmed to be outside the mitigation zone. Although monitoring during and following munitions use is limited to observable impacts within and in the vicinity of the mission area, the lack of any past evidence of any associated impacts on marine mammals is an indication that the monitoring and mitigation measures implemented for EGTTR operations are effective.
Eglin AFB submitted annual reports required under the existing LOA from 2018-2021. Although marine mammals were sighted on a number of mission days, usually during pre-and post-mission surveys, Eglin AFB concluded that no marine mammal takes occurred as a result of any mission activities from 2018-2021. The annual monitoring reports are available at:
NMFS has defined negligible impact as an impact resulting from the specified activity that cannot be reasonably expected to, and is not reasonably likely to, adversely affect the species or stock through effects on annual rates of recruitment or survival (
In the Estimated Take of Marine Mammals section of this final rule, we identified the subset of potential effects that are reasonably expected to occur and rise to the level of takes based on the methods described. The impact that any given take will have on an individual, and ultimately the species or stock, is dependent on many case-specific factors that need to be considered in the negligible impact analysis (
As explained in the Estimated Take of Marine Mammals section, no take by serious injury or mortality is anticipated or authorized. Further, any Level A harassment would be expected to be in the form of PTS; no non-auditory injury is anticipated or authorized.
The Specified Activities reflect maximum levels of training and testing activities. The Description of the Specified Activity section describes annual activities. There may be some flexibility in the exact number of missions that may vary from year to year, but take totals will not exceed the maximum annual numbers or the 7-year totals indicated in Table 34. We base our analysis and negligible impact determination on the maximum number of takes that are reasonably expected to occur and that are authorized, although, as stated before, the number of takes are only a part of the analysis, which includes qualitative consideration of other contextual factors that influence the degree of impact of the takes on the affected individuals. To avoid repetition, in this Analysis and Negligible Impact Determination section we provide some general analysis that applies to all the species and stocks listed in Table 34, given that some of the anticipated effects of the USAF's training and testing activities on marine mammals are expected to be relatively similar in nature. Next, we break up our
The USAF's take request, which, as described above, is for harassment only, is based on its acoustic effects model. The model calculates sound energy propagation from explosive and inert munitions during training and testing activities in the EGTTR. The munitions planned to be used by each military unit were grouped into mission-day categories so the acoustic impact analysis could be based on the total number of detonations conducted during a given mission to account for the accumulated energy from multiple detonations over a 24-hour period. A total of 19 mission-day categories were developed for the munitions planned to be used. Using the dBSea underwater acoustic model and associated analyses, the threshold distances and harassment zones were estimated for each mission-day category for each marine mammal species. Takes were estimated based on the area of the harassment zones, predicted animal density, and annual number of events for each mission-day category. To assess the potential impacts of inert munitions on marine mammals, the planned inert munitions were categorized into four classes based on their impact energies, and the threshold distances for each class were modeled and calculated as described for the mission-day categories. Assumptions in the USAF model intentionally err on the side of overestimation. For example, the model conservatively assumes that (1) the water surface is flat (no waves) to allow for maximum energy reflectivity; (2) munitions striking targets confer all weapon energy into underwater acoustic energy; and (3) above or at surface explosions assume no energy losses from surface effects (
Generally speaking, the USAF and NMFS anticipate more severe effects from takes resulting from exposure to higher received levels (though this is in no way a strictly linear relationship for behavioral effects throughout species, individuals, or circumstances) and less severe effects from takes resulting from exposure to lower received levels. However, there is also growing evidence of the importance of distance in predicting marine mammal behavioral response to sound—
Explosive events may be a single event involving one explosion (single exposure) or a series of intermittent explosives (multiple explosives) occurring over the course of a day. Gunnery events, in some cases, may have longer durations of exposure to intermittent sound. In general, gunnery events can last intermittently up to 90 minutes total, but typically lasts approximately 30 minutes. Live firing is continuous, with pauses usually lasting well under 1 minute and rarely up to 5 minutes. Takes may represent either brief exposures (seconds) or, slightly longer exposures, or, in some cases, multiple brief exposures, within a day. Most explosives detonating at or near the surface have brief exposures lasting only a few milliseconds to minutes for the entire event.
Behavioral reactions from explosive sounds are likely to be similar to reactions studied for other impulsive sounds such as those produced by air guns. Impulsive signals, particularly at close range, have a rapid rise time and higher instantaneous peak pressure than other signal types, making them more likely to cause startle responses or avoidance responses. Most data has come from seismic surveys that occur over long durations (
Take estimates alone do not provide information regarding the potential fitness or other biological consequences of the reactions on the affected individuals. NMFS therefore considers the available activity-specific, environmental, and species-specific information to determine the likely nature of the behavioral disturbances and the potential fitness consequences for affected individuals.
In the range of potential behavioral effects that might be expected to be part of a response that qualifies as an instance of Level B harassment by behavioral disturbance (which by nature of the way it is modeled/counted, occurs within one day), the less severe end might include exposure to comparatively lower levels of a sound, at a detectably greater distance from the animal, for a few or several minutes. A less severe exposure of this nature could result in a behavioral response such as avoiding an area that an animal would otherwise have chosen to move through or feed in for some amount of time or breaking off one or a few feeding bouts. More severe effects could occur when the animal gets close enough to the source to receive a comparatively higher level, or is exposed intermittently to different sources throughout a day. Such effects might result in an animal having a more severe flight response and leaving a larger area for a day or more or potentially losing feeding opportunities for a day. However, such severe behavioral effects are expected to occur infrequently since monitoring and mitigation requirements would limit exposures to marine mammals. Additionally, previous marine mammal monitoring efforts in the EGTTR over a number of years have not demonstrated any impacts on marine mammals.
The majority of Level B harassment takes are expected to be in the form of milder responses (
Many animals perform vital functions, such as feeding, resting, traveling, and socializing, on a diel cycle (24-hour cycle). Behavioral reactions to noise exposure (such as disruption of critical life functions, displacement, or avoidance of important habitat) are more likely to be significant for fitness if they last more than one diel cycle or recur on subsequent days (Southall
Many mission days feature only a single or limited number of explosive munitions. Explosive detonations on such days would likely last only a few seconds. There are likely to be days or weeks that pass without mission activities. Because of their short activity duration and the fact that they are in the open ocean and animals can easily move away, it is similarly unlikely that animals would be exposed for long, continuous amounts of time, or repeatedly, or demonstrate sustained behavioral responses. All of these factors make it unlikely that individuals would be exposed to the exercise for extended periods or on consecutive days.
NMFS and the USAF have estimated that some species and stocks of marine mammals may sustain some level of TTS from explosive detonations. In general, TTS can last from a few minutes to days, be of varying degree, and occur across various frequency bandwidths, all of which determine the severity of the impacts on the affected individual, which can range from minor to more severe. Explosives are generally referenced as broadband because of the various frequencies. Table 31 indicates the number of takes by TTS that may be incurred by different species from exposure to explosives. The TTS sustained by an animal is primarily classified by three characteristics:
1. Frequency—Available data (of mid-frequency hearing specialists exposed to mid- or high-frequency sounds; Southall
2. Degree of the shift (
3. Duration of TTS (recovery time)—In the TTS laboratory studies (as discussed in the Potential Effects of Specified Activities on Marine Mammals and their Habitat section of the proposed rule), some using exposures of almost an hour in duration or up to 217 SEL, almost all individuals recovered within 1 day (or less, often in minutes), although in one study (Finneran
The TTS takes would be the result of exposure to explosive detonations (broad-band). As described above, we expect the majority of these takes to be in the form of mild (single-digit), short-term (minutes to hours) TTS. This means that for one time a year, for several minutes, a taken individual will have slightly diminished hearing sensitivity (slightly more than natural variation, but nowhere near total deafness). The expected results of any one of these small number of mild TTS occurrences could be that (1) it does not overlap signals that are pertinent to that animal in the given time period, (2) it overlaps parts of signals that are important to the animal, but not in a manner that impairs interpretation, or (3) it reduces detectability of an important signal to a small degree for a short amount of time—in which case the animal may be aware and be able to compensate (but there may be slight energetic cost), or the animal may have some reduced opportunities (
The ultimate potential impacts of masking on an individual (if it were to occur) are similar to those discussed for TTS, but an important difference is that masking only occurs during the time of the signal, versus TTS, which continues beyond the duration of the signal. Fundamentally, masking is referred to as a chronic effect because one of the key potential harmful components of masking is its duration—the fact that an animal would have reduced ability to hear or interpret critical cues becomes much more likely to cause a problem the longer it is occurring. Also inherent in the concept of masking is the fact that the potential for the effect is only present during the times that the animal and the source are in close enough proximity for the effect to occur (and further, this time period would need to coincide with a time that the animal was utilizing sounds at the masked frequency). As our analysis has indicated, because of the sound sources primarily involved in this rule, we do not expect the exposures with the potential for masking to be of a long duration. Masking is fundamentally more of a concern at lower frequencies, because low frequency signals propagate significantly further than higher frequencies and because they are more likely to overlap both the narrower low-frequency calls of mysticetes, as well as many non-communication cues, such as sounds from fish and invertebrate prey and geologic sounds that inform navigation. Masking is also more of a concern from continuous (versus intermittent) sources when there is no quiet time between a sound source within which auditory signals can be detected and interpreted. Explosions introduce low-frequency, broadband sounds into the environment, which could momentarily mask hearing thresholds in animals that are nearby, although sounds from missile and bomb explosions last for only a few seconds. Sound from gunnery ammunition, however, can last up to 90 minutes, although a 30-minute duration is more typical. Masking due to these relatively short duration detonations would not be significant. Effects of masking are only present when the sound from the explosion is present, and the effect is over the moment the sound is no longer detectable. Therefore, short-term exposure to the predominantly intermittent or single explosions are not expected to result in a meaningful amount of masking. For the reasons described here, any limited masking that could potentially occur from explosives would be minor, short-term and intermittent. Long-term consequences from physiological stress due to the sound of explosives would not be expected. In conclusion, masking is more likely to occur in the presence of broadband, relatively continuous noise sources, such as from vessels; however, the duration of temporal and spatial overlap with any individual animal would not be expected to result in more than short-term, low impact masking that would not affect reproduction or survival of individuals.
Table 42 indicates the number of individuals of each species for which Level A harassment in the form of PTS resulting from exposure to or explosives is estimated to occur. The number of individuals to potentially incur PTS annually from explosives for each species ranges from 0 (Rice's whale) to 9 (bottlenose dolphin). As described previously, no species are expected to incur non-auditory injury from explosives.
As discussed previously, the USAF utilizes aerial, vessel and video monitoring to detect marine mammals for mitigation implementation, which is not taken into account when estimating take by PTS. Therefore, NMFS expects that Level A harassment is unlikely to occur at the authorized numbers. However, since it is difficult to quantify the degree to which the mitigation and avoidance will reduce the number of animals that might incur Level A harassment, NMFS plans to authorize take by Level A harassment at the numbers derived from the exposure model. These estimated Level A harassment take numbers represent the maximum number of instances in which marine mammals would be reasonably expected to incur PTS, and we have analyzed them accordingly. In relation to TTS, the likely consequences to the health of an individual that incurs PTS can range from mild to more serious depending upon the degree of PTS and the frequency band. Any PTS accrued as a result of exposure to USAF activities would be expected to be of a small amount (
Some of the lower level physiological stress responses (
The estimated takes by Level B harassment shown in Table 40 represent instances of take, not the number of individuals taken (the much lower and less frequent takes by Level A harassment are far more likely to be associated with separate individuals). As described previously, USAF modeling uses the best available science to predict the instances of exposure above certain acoustic thresholds, which are quantified as harassment takes. However, these numbers from the model do not identify whether and when the enumerated instances occur to the same individual marine mammal on different days, or how any such repeated takes may impact those individuals. One method that NMFS can use to help better understand the overall scope of the impacts is to compare the total instances of take against the abundance of that species (or stock if applicable). For example, if there are 100 estimated harassment takes in a population of 100, one can assume either that every individual will be exposed above acoustic thresholds in no more than 1 day, or that some smaller number will be exposed in one day but
To assist in understanding what this analysis means, we clarify a few issues related to estimated takes and the analysis here. An individual that incurs PTS or TTS may sometimes, for example, also be subject to direct behavioral disturbance at the same time. As described above in this section, the degree of PTS, and the degree and duration of TTS, expected to be incurred from the USAF's activities are not expected to impact marine mammals such that their reproduction or survival could be affected. Similarly, data do not suggest that a single instance in which an animal incurs PTS or TTS and also has an additional direct behavioral response would result in impacts to reproduction or survival. Accordingly, in analyzing the numbers of takes and the likelihood of repeated and sequential takes, we consider all the types of take, so that individuals potentially experiencing both threshold shift and direct behavioral responses are appropriately considered. The number of Level A harassment takes by PTS are so low for dolphin species (and zero for Rice's whale) compared to abundance numbers that it is considered highly unlikely that any individual would be taken at those levels more than once.
Occasional, milder behavioral reactions are unlikely to cause long-term consequences for individual animals or populations, and even if some smaller subset of the takes are in the form of longer (several hours or a day) and more severe responses, if they are not expected to be repeated over sequential days, impacts to individual fitness are not anticipated. Nearly all studies and experts agree that infrequent exposures of a single day or less are unlikely to impact an individual's overall energy budget (Farmer
Any impacts to marine mammal habitat are expected to be relatively minor. Noise and pressure waves resulting from live weapon detonations are not likely to result in long-term physical alterations of the water column or ocean floor. These effects are not expected to substantially affect prey availability, are of limited duration, and are intermittent. Impacts to marine fish were analyzed in our Potential Effects of Specified Activities on Marine Mammals and their Habitat section as well as in the 2022 REA (USAF 2022). NMFS acknowledges that explosive detonations can impact both fish and invertebrate prey sources in manners ranging from behavioral disturbance to mortality for animals that are very close to the source. However, as described in the analysis, these impacts are expected to be short term and localized and would be inconsequential to the fish and invertebrate populations and to the marine mammals that use them as prey. In the REA, it was determined that fish populations were unlikely to be affected and prey availability for marine mammals would not be impaired. Other factors related to EGTTR activities that could potentially affect marine mammal habitat include the introduction of metals, explosives and explosion by-products, other chemical materials, and debris into the water column and substrate due to the use of munitions and target vessels. However, the effects of each were analyzed in the REA and were determined to be not significant.
This section builds on the broader discussion above and brings together the discussion of the different types and amounts of take that different species are likely to incur, the applicable mitigation, and the status of the species to support the negligible impact determinations for each species. We have described (above in the Analysis and Negligible Impact Determination section) the unlikelihood of any masking having effects that would impact the reproduction or survival of any of the individual marine mammals affected by the USAF's activities. We also described in the Potential Effects of Specified Activities on Marine Mammals and their Habitat section of this final rule the unlikelihood of any habitat impacts having effects that would impact the reproduction or survival of any of the individual marine mammals affected by the USAF's activities. There is no predicted non-auditory tissue damage from explosives for any species, and limited takes of dolphin species by PTS are predicted. Much of the discussion below focuses on the Level B harassment (behavioral disturbance and TTS) and the mitigation measures that reduce the probability or severity of effects. Because there are species-specific considerations, these are discussed below where necessary.
The Gulf of Mexico Bryde's whale was listed as an endangered subspecies under the ESA in 2019. NMFS revised the common and scientific name of the
NMFS is proposing to allow for the authorization of two annual takes of Rice's whale by Level B harassment in the form of TTS and four annual takes by Level B harassment in the form of behavioral disturbance. The implementation of the required mitigation is expected to minimize the severity of any behavioral disturbance and TTS of Rice's whales. Monitoring reports under the LOA effective from 2018 through 2021 have not recorded take of any marine mammals. Only bottlenose dolphins have been observed, and there have not been sightings of whales of any species.
Rice's whale will benefit from the required mitigation measures to limit impacts to the species. As a mitigation measure to prevent any PTS and limit TTS and behavioral impacts to the Rice's whale, the USAF will restrict the use of live munitions in the western part of each LIA based on the setbacks from the 100-m isobath presented earlier. The USAF will also prohibit the use of inert munitions in Rice's whale habitat (100-400 m depth) throughout the EGTTR. The less impactful 105 mm Training Round must be used by the USAF for nighttime missions and all gunnery missions must be conducted 500 m landward of the 100-m isobath. Furthermore, depending on the mission category, vessel-based, aerial, or video feed monitoring would be required. Noise from explosions is broadband with most energy below a few hundred Hz; therefore, any reduction in hearing sensitivity from exposure to explosive sounds is likely to be broadband with effects predominantly at lower frequencies. The limited number of Rice's whales, estimated to be two animals, that do experience TTS from exposure to explosives may have reduced ability to detect biologically important sounds (
Research and observations show that if mysticetes are exposed to impulsive sounds such as those from explosives, they may react in a variety of ways, which may include alerting, startling, breaking off feeding dives and surfacing, diving or swimming away, changing vocalization, or showing no response at all (Department of Defense (DOD) 2017; Nowacek 2007; Richardson 1995; Southall
As described, extensive operational and time/area mitigation measures for Rice's whales are expected to minimize the impacts of military testing and training activities to Rice's whales. The anticipated and authorized take of Rice's whale is of a low magnitude and severity that is not expected to impact the reproduction or survival of any individuals, much less population rates of recruitment or survival. Accordingly, we have found that the take authorized under the rule will have a negligible impact on Rice's whales.
Neither the common bottlenose dolphin (Northern Gulf of Mexico continental shelf stock) or Atlantic spotted dolphin (Gulf of Mexico stock) are listed as strategic or depleted under the MMPA, and no active unusual mortality events (UME) have been declared. No mortality or non-auditory injury is predicted or authorized for either of these species. There are no areas of known biological significance for dolphins in the EGTTR. Repeated takes of the same individual animals would be unlikely. The number of PTS takes from the planned activities are low (one for Atlantic spotted dolphin; nine for common bottlenose dolphin). Because of the low degree of PTS discussed previously (
As described, the authorized take of dolphins is of a low magnitude and severity such that it is not expected to impact the reproduction or survival of any individuals, much less population rates of recruitment or survival. Accordingly, we have found that the take authorized under the final rule will have a negligible impact on common bottlenose dolphins and Atlantic spotted dolphins.
Based on the analysis contained herein of the likely effects of the specified activity on marine mammals and their habitat, NMFS finds that the total marine mammal take from the specified activities will have a negligible impact on all affected marine mammal species. In addition, as described previously, the USAF's implementation of monitoring and mitigation measures would further reduce impacts to marine mammals.
There are no relevant subsistence uses of the affected marine mammal stocks or species implicated by this action. Therefore, NMFS has determined that the total taking of affected species or stocks would not have an unmitigable adverse impact on the availability of the species or stocks for taking for subsistence purposes.
To comply with the National Environmental Policy Act of 1969 (42 U.S.C. 4321
There is one marine mammal species under NMFS jurisdiction that is listed as endangered under the ESA (16 U.S.C. 1531
There are no National Marine Sanctuaries in the EGTTR that would be affected by the USAF's planned activities.
The Office of Management and Budget has determined that this final rule is not significant for purposes of Executive Order 12866.
Pursuant to the Regulatory Flexibility Act (RFA), the Chief Counsel for Regulation of the Department of Commerce has certified to the Chief Counsel for Advocacy of the Small Business Administration that this final rule would not have a significant economic impact on a substantial number of small entities. The RFA requires Federal agencies to prepare an analysis of a rule's impact on small entities whenever the agency is required to publish a notice of proposed rulemaking. However, a Federal agency may certify, pursuant to 5 U.S.C. 605(b), that the action will not have a significant economic impact on a substantial number of small entities. The USAF is the sole entity that would be affected by this rulemaking, and the USAF is not a small governmental jurisdiction, small organization, or small business, as defined by the RFA. Any requirements imposed by an LOA issued pursuant to these regulations, and any monitoring or reporting requirements imposed by these regulations, would be applicable only to the USAF. NMFS does not expect the issuance of these regulations or the associated LOA to result in any impacts to small entities pursuant to the RFA. Because this action, if adopted, would directly affect the USAF and not a small entity, NMFS concludes that the action would not result in a significant economic impact on a substantial number of small entities. As a result, a final regulatory flexibility analysis is not required, and none has been prepared.
The Assistant Administrator for Fisheries has determined that there is good cause under the Administrative Procedure Act (5 U.S.C. 553(d)(3)) to waive the 30-day delay in the effective date of the final rule. The USAF is the only entity subject to the regulations and has informed NMFS that it requests that this final rule take effect by April 13, 2023, in order to prevent serious disruption of USAF testing and training activities that would result from any further delay in issuance of the LOA. Any postponement of enacting the final rule would (1) undermine 96th Operations Group support to Urgent Operational Need (UON/JUON) weapons tests and delay delivery of weapons capabilities to the warfighter (this would result in the deferment of four known near-term test events), and (2) increase costs for multiple programs and test events at Eglin AFB, Tyndall AFB, and Hurlburt Field affected by the range suspension. The USAF is ready to implement the rule immediately. For all of these reasons, the Assistant Administrator finds good cause to waive the 30-day delay in the effective date.
Exports, Fish, Imports, Incidental take, Indians, Labeling, Marine mammals, Penalties, Reporting and recordkeeping requirements, Seafood, Sonar, Transportation, USAF.
For the reasons set out in the preamble, NMFS amends 50 CFR part 218 as follows:
16 U.S.C. 1361
(a) Regulations in this subpart apply only to the U.S. Air Force (USAF) for the taking of marine mammals that occurs in the area described in paragraph (b) of this section and that occurs incidental to the activities listed in paragraph (c) of this section.
(b) The taking of marine mammals by the USAF under this subpart may be authorized in a Letter of Authorization (LOA) only if it occurs within the Eglin Gulf Test and Training Range (EGTTR). The EGTTR is located adjacent to Santa Rosa, Okaloosa, and Walton Counties and includes property on Santa Rosa Island and Cape San Blas. The EGTTR is the airspace controlled by Eglin Air Force Base (AFB) over the Gulf of Mexico, beginning 3 nautical miles (nmi) from shore, and the underlying Gulf of Mexico waters. The EGTTR extends southward and westward off the coast of Florida and encompasses approximately 102,000 square nautical miles (nmi
(c) The taking of marine mammals by the USAF is only authorized if it occurs incidental to the USAF conducting training and testing activities, including air warfare and surface warfare training and testing activities.
Regulations in this subpart are effective from April 13, 2023, through April 13, 2030.
(a) Under an LOA issued pursuant to § 216.106 of this subchapter and § 218.66, the Holder of the LOA (hereinafter “USAF”) may incidentally, but not intentionally, take marine mammals within the area described in § 218.60(b) by Level A and Level B harassment (defined in section 3(18)(B) of the Marine Mammal Protection Act) associated training and testing activities described in § 218.60(c) provided the activity is in compliance with all terms, conditions, and requirements of the regulations in this subpart and the applicable LOA.
(b) The incidental take of marine mammals by the activities listed in § 218.60(c) is limited to the species and stocks listed in table 1 to this paragraph (b). Only Level B Harassment of Rice's whales is authorized. Level A Harassment and level B Harassment of the two dolphin stocks are authorized.
(a) Except for permissible incidental take described in § 218.62(a) and authorized by an LOA issued under § 216.106 of this subchapter and § 218.66, no person in connection with the activities listed in § 218.66 may do any of the following in connection with activities listed in § 218.60(c):
(1) Violate, or fail to comply with, the terms, conditions, or requirements of this subpart or an LOA issued under § 216.106 of this subchapter and § 218.66;
(2) Take any marine mammal not specified in § 218.62(b);
(3) Take any marine mammal specified in § 218.62(b) in any manner other than as specified in the LOA issued under § 216.106 of this subchapter and § 218.66;
(4) Take a marine mammal specified in § 218.62(b) after the National Marine Fisheries Service (NMFS) determines such taking results in more than a negligible impact on the species or stock of such marine mammal.
(b) [Reserved]
(a) When conducting the activities identified in § 218.60(c), the mitigation measures contained in this subpart and any LOA issued under § 216.106 of this subchapter and § 218.66 must be implemented. These mitigation measures include, but are not limited to:
(1)
(i)
(B) USAF range-clearing vessels and marine mammal survey vessels must be onsite 90 minutes before mission to clear prescribed human safety zone and survey the mitigation zone for the given mission-day category.
(C) For all live missions except gunnery missions, USAF Protected Species Observers (PSOs) must monitor the mitigation zones as defined in table 1 to paragraph (a)(1)(i)(C)(
(
(
(
(
(
(D) Missions involving air-to-surface gunnery operations must conduct aerial monitoring of the mitigation zones, as described in the table 3 to this paragraph (a)(1)(i)(D).
(ii)
(B) The mission must be postponed, relocated, or cancelled if either of the two authorized dolphin species are visually detected in the mitigation zone during the pre-mission survey. Postponement must continue until the animals are confirmed to be outside of the mitigation zone and observed by a PSO to be heading away from the mitigation zone or until the animals are not seen again for 30 minutes.
(C) The mission must be postponed if marine mammal indicators (
(D) If either of the two authorized dolphin species are observed in the monitoring zone by PSOs when observation vessels are exiting the human safety zone, and if PSOs determine the marine mammals are heading toward the mitigation zone, then missions must either be postponed, relocated, or cancelled based on mission-specific test and environmental parameters. Postponement must continue until the animals are confirmed by a PSO to be heading away from the mitigation zone or until the animals are not seen again for 30 minutes.
(E) Aerial-based PSOs must look for potential indicators of marine mammal species presence, such as large schools of fish and large, active groups of birds.
(F) If marine mammal or potential indicators are detected in the mitigation area during pre-mission surveys or during the mission by aerial-based or video-based PSOs, operations must be immediately halted until the mitigation zone is clear of all marine mammals, or the mission must be relocated to another target area.
(iii)
(A) When any marine mammal is sighted, vessels must attempt to maintain a distance of at least 150 ft (46 m) away from marine mammals and 300 ft (92 m) away from whales. Vessels must reduce speed and avoid abrupt changes in direction until the animal(s) has left the area.
(B) If a whale is sighted in a vessel's path or within 300 feet (92 m) from the vessel, the vessel speed must be reduced and the vessel's engine must be shifted to neutral. The engines must not be engaged until the animals are clear of the area.
(C) If a whale is sighted farther than 300 feet (92 m) from the vessel, the vessel must maintain a distance of 300 feet greater between the whale and the vessel's speed must be reduced to 10 knots or less.
(D) Vessels are required to stay 500 m away from the Rice's whale. If a baleen whale cannot be positively identified to species level then it must be assumed to be a Rice's whale and the 500 m separation distance must be maintained.
(E) Vessels must avoid transit in the core distribution area (CDA), as specified in the LOA issued under § 216.106 of this subchapter and § 218.66, and within the 100—400 m isobath zone outside the CDA. If transit in these areas is unavoidable, vessels must not exceed 10 knots and transit at night is prohibited.
(F) An exception to any vessel strike avoidance measure is for instances required for human safety, such as when members of the public need to be intercepted to secure the human safety zone, or when the safety of a vessel operations crew could be compromised.
(iv)
(B) Within a mission, firing must start with use of the lowest caliber munition and proceed to increasingly larger rounds.
(C) Any pause in live fire activities greater than 10 minutes must be followed by the re-initiation of pre-mission surveys.
(2)
(ii)
(iii)
(iv)
(v)
(B) Mission-day category K munitions must have a setback of 1.338 km from the 100-m isobath.
(C) Mission-day category K munitions may be fired into portions of the EGTTR outside the LIAs but must be outside the area between the 100-m and 400-m isobaths.
(3)
(ii)
(b) [Reserved]
(a)
(1) Any person who will serve as a PSO for a particular mission must have completed the training within a year prior to the mission.
(2) For missions that require multiple survey platforms to cover a large area, a Lead Biologist must be designated to lead the monitoring and coordinate sighting information with the Test Director or Safety Officer.
(b)
(2) Monitoring must be conducted from the highest point feasible on the vessels.
(3) There must be at least two PSOs on each survey vessel.
(4) For missions that require multiple vessels to cover a large survey area, a Lead Biologist must be designated.
(i) The Lead Biologist must coordinate all survey efforts.
(ii) The Lead Biologist must compile sightings information from other vessels.
(iii) The Lead Biologist must inform Tower Control if the mitigation and monitoring zones are clear or not clear of marine mammal species.
(iv) If the area is not clear, the Lead Biologist must provide recommendations on whether the mission should be postponed or canceled.
(v) Tower Control must relay the Lead Biologist's recommendation to the Safety Officer. The Safety Officer and Test Director must collaborate regarding range conditions based on the information provided.
(vi) The Safety Officer must have the final authority on decisions regarding postponements and cancellations of missions.
(c)
(2) Gunnery mission aircraft must also serve as aerial-based monitoring platforms.
(3) Aerial survey teams must consist of Eglin Natural Resources Office personnel or their designees aboard a non-mission aircraft or the mission aircrew.
(4) All aircraft personnel on non-mission and mission aircraft who are acting in the role of a PSO must have completed Eglin AFB's Marine Species Observer Training Course.
(5) One trained PSO in the aircraft must record data and relay information on species sightings, including the species (if possible), location, direction of movement, and number of animals, to the Lead Biologist.
(6) For gunnery missions, after arriving at the mission site and before initiating gun firing, the aircraft must fly at least two complete orbits around the target area out to the applicable monitoring zone at a minimum safe airspeed and appropriate monitoring altitude as shown in table 3 to § 218.64(a)(1)(i)(D).
(7) Aerial monitoring by aircraft must maintain a minimum ceiling of 305 m (1,000 feet) and visibility of 5.6 km (3 nmi) for effective monitoring efforts and flight safety as shown in table 3 to § 218.64(a)(1)(i)(D).
(8) Pre-mission aerial surveys conducted by gunnery aircrews in AC-130s must extend out 5 nmi (9,260 m) from the target location while aerial surveys in CV-22 aircraft must extend out from the target location to a range of 3 nmi (5,556 m) as shown in table 3 to § 218.64(a)(1)(i)(D).
(9) If the mission is relocated, the pre-mission survey procedures must be repeated in the new area.
(10) If multiple gunnery missions are conducted during the same flight, marine species monitoring must be conducted separately for each mission.
(11) During nighttime missions, night-vision goggles must be used.
(12) During nighttime missions, low-light electro-optical and infrared sensor systems on board the aircraft must be used for marine mammal species monitoring.
(13) Mission-day category K tests and any other missions that are conducted at nighttime must be supported by AC-130 aircraft with night-vision instrumentation or other platforms with comparable nighttime monitoring capabilities.
(14) For Mission-day category K missions, the pre-mission survey area must extend out to, at a minimum, double the Level A harassment (PTS) threshold distance for delphinids (0.89 km). Mission-day category K is estimated to have a PTS threshold distance of 0.445 km as shown in table 1 to this paragraph (c)(14).
(d)
(2) A trained PSO (the video camera PSO) must monitor the live video feeds from the Gulf Range Armament Test Vessel (GRATV) transmitted to the Central Control Facility (CCF).
(3) The video camera PSO must report any marine mammal species sightings to the Safety Officer, who will also be at the CCF.
(4) The video camera PSO must have open lines of communication with the PSOs on vessels to facilitate real-time reporting of marine species sightings.
(5) Direct radio communication must be maintained between vessels, GRATV personnel, and Tower Control throughout the mission.
(6) If a marine mammal species is detected on the live video by a PSO prior to weapon release, the mission must be stopped immediately by the Safety Officer.
(7) Supplemental video monitoring by additional aerial assets must be used when practicable (
(e)
(2) For gunnery missions, following each mission, aircrews must conduct a post-mission survey beginning at the operational altitude and continuing through an orbiting descent to the designated monitoring altitude. The post-mission survey area will be the area covered in 30 minutes of observation in a direction down-current from the impact site or the actual pre-mission survey area, whichever is reached first.
(3) During post-mission monitoring, PSOs must survey the mission site for any dead or injured marine mammals. The post-mission survey area will be the area covered in 30 minutes of observation in a direction down-current from the impact site or the actual pre-mission survey area, whichever is reached first.
(f)
(2) The USAF must further investigate ways to supplement its mitigation measures with the use of real-time PAM devices (
(3) These studies are contingent upon the availability of funding.
(4) Both studies must be approved by NMFS.
(g)
(1) Dates and times (begin and end) of each EGTTR mission;
(2) Complete description of mission activities;
(3) Complete description of pre-and post-monitoring activities occurring during each mission;
(4) Environmental conditions during monitoring periods including Beaufort sea state and any other relevant weather conditions such as cloud cover, fog, sun glare, and overall visibility to the horizon, and estimated observable distance; and
(5) Upon observation of a marine mammal, the following information should be collected:
(i) Observer who sighted the animal and observer location and activity at time of sighting;
(ii) Time of sighting;
(iii) Identification of the animal (
(iv) Distances and bearings of each marine mammal observed in relation to the target site;
(v) Estimated number of animals including the minimum number, maximum number, and best estimate);
(vi) Estimated number of animals by cohort (
(vii) Estimated time that the animal(s) spent within each of the mitigation and monitoring zones;
(viii) Description of any marine mammal observed marine mammal behaviors (such as feeding or traveling) or changes in behavioral patterns (
(ix) Detailed information about implementation of any mitigation (
(x) All PSO datasheets and/or raw sightings data.
(6) The final comprehensive report must include a summary of data collected as part of the annual reports.
(h)
(2) The USAF will not resume their activities until notified by NMFS. The report must include the following information:
(i) Time, date, and location (latitude/longitude) of the first discovery (and updated location information if known and applicable);
(ii) Species identification (if known) or description of the animal(s) involved;
(iii) Condition of the animal(s) (including carcass condition if the animal is dead);
(iv) Observed behaviors of the animal(s), if alive;
(v) If available, photographs or video footage of the animal(s); and
(vi) General circumstances under which the animal was discovered.
(a) To incidentally take marine mammals pursuant to the regulations in this subpart, the USAF must apply for and obtain an LOA in accordance with § 216.106 of this subchapter.
(b) An LOA, unless suspended or revoked, may be effective seven years from the date of issuance.
(c) Except for changes made pursuant to the adaptive management provision of § 218.67(b)(1), in the event of projected changes to the activity or to mitigation, monitoring, or reporting required by an LOA issued under this subpart, the USAF must apply for and obtain a modification of the LOA as described in § 218.67.
(d) Each LOA will set forth:
(1) Permissible methods of incidental taking;
(2) Geographic areas for incidental taking;
(3) Means of effecting the least practicable adverse impact (
(4) Requirements for monitoring and reporting.
(e) Issuance of the LOA(s) must be based on a determination that the level of taking is consistent with the findings made for the total taking allowable under the regulations in this subpart.
(f) Notice of issuance or denial of the LOA(s) will be published in the
(a) An LOA issued under § 216.106 of this subchapter and § 218.66 for the activity identified in § 218.60(c) may be modified upon request by the applicant, consistent with paragraph (b) of this section, provided that any requested changes to the activity or to the mitigation, monitoring, or reporting measures (excluding changes made pursuant to the adaptive management provision in paragraph (b)(1) of this section) do not change the underlying findings made for the regulations in this subpart and do not result in more than a minor change in the total estimated number of takes (or distribution by species or years).
(b) An LOA issued under § 216.106 of this subchapter and § 218.66 may be modified by NMFS under the following circumstances:
(1)
(i) Possible sources of data that could contribute to the decision to modify the mitigation, monitoring, or reporting measures in an LOA include:
(A) Results from USAF's annual monitoring report and annual exercise report from the previous year(s);
(B) Results from other marine mammal and/or sound research or studies;
(C) Results from specific stranding investigations; or
(D) Any information that reveals marine mammals may have been taken in a manner, extent, or number not authorized by the regulations in this subpart or subsequent LOAs.
(ii) If, through adaptive management, the modifications to the mitigation, monitoring, or reporting measures are substantial, NMFS will publish a notice of a new proposed LOA in the
(2)